SEOMonster

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond annotations: it explains the render-blindness check, evidence-backed signals, and mentions that schema.org/FAQ are informational and not scored. This complements the annotations (readOnlyHint, openWorldHint) without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient and front-loaded with the core purpose. It is concise but could benefit from clearer sentence breaks or bullet points for readability. Currently, it reads as a single dense paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter and no output schema, the description adequately explains what the tool does and its limitations (no guarantee of citation). However, it does not describe the return format or score range, which might be needed for an agent to interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with a clear description for 'url'. The tool description does not add additional meaning or usage tips for the parameter, so it meets the baseline for full schema coverage without extra detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: scoring a page's readiness for LLM citation. It lists specific checks (render-blindness, statistics, etc.) and distinguishes itself from siblings like 'ai_citation_track' by focusing on readiness assessment rather than tracking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implicit usage context by explaining the methodology (leads with render-blindness check) and notes that it does not guarantee citation. However, it does not explicitly list scenarios when not to use or compare with alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnly, openWorld, non-idempotent, non-destructive. Description adds 'Paid + non-deterministic', 'results are directional and dated', and warns about API-UX discrepancies, providing behavioral context beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single cohesive paragraph that front-loads the core function. It's dense with useful information but could be slightly improved with structured formatting. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers input (managed prompt set, brand, engines, samples, competitors, brand domains), process (sampling, confidence interval, share-of-voice, volatility), and limitations (directionality, datedness, API differences). With no output schema, it adequately explains expected results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and description adds valuable context for parameters: 'freeze it across cycles' for prompts, 'default 7 (>=7 recommended)' for samples, and 'Your domain(s) to detect in citations' for brand_domains, enhancing schema descriptions meaningfully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool tracks brand mention and citation share-of-voice across AI answer engines for a managed prompt set. It specifies the action (track), resource (brand mentions/citations), and scope (compared to competitors), distinguishing it from all sibling tools which focus on different domains like GSC, GA4, or Cloudflare.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description provides explicit context on when to use ('NOT an AI rank', 'single runs are statistically meaningless') and limitations (developer-API vs consumer UI, AIO has no API). It doesn't explicitly state when not to use or list alternatives, but the tool's uniqueness among siblings makes these implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: the undercount disclaimer (~70% land as Direct) and the fact that AI-Overview clicks are excluded. This goes beyond what annotations provide but does not cover all potential edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact at two sentences with a semicolon, covering all necessary points without fluff. It is front-loaded with the main purpose and ends with an important caveat. Minor improvement: could use structured bullets for the two components, but current structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, prerequisites, and limitations well, but lacks any mention of return values or output format. Since the tool has no output schema, the description should at least hint at what the agent can expect (e.g., a JSON object with referral stats and crawl status). Parameters and annotations are well-covered, but output is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, but the tool description adds default behaviors (days defaults to 28, site_url defaults from GSC default site, property_id defaults to configured property) and functional grouping (days for GA4 referral, site_url for crawl coverage). This significantly enhances meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a 'First-party view of AI traffic' with two specific components: AI referral sessions via GA4 and AI-crawler coverage via robots.txt. It names specific AI apps and bots, making the resource scope explicit. This verb+resource+scope structure distinguishes it from sibling tools like robots_ai_posture or ga4_organic_search_overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear prerequisites (GA4 property for referral, site_url for crawl coverage) and defaults for parameters. It includes an explicit honest bound about undercounting and AI-Overview clicks counting as Organic. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses all-or-nothing validation, async addition, and dry_run support beyond what annotations provide. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no wasted words. Purpose upfront, followed by gating and behavior, then async note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, gating, validation, dry_run, async. Lacks description of return value or response structure, but overall adequate for a complex bulk operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description adds little beyond schema. It reinforces the confirm and list_name relationship but no new parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates or appends many redirects via a bulk redirect list for site migrations. It distinguishes from siblings like cf_create_redirect (single) and cf_delete_redirect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit gating conditions (destructive env variable and confirm value) and mentions dry_run. Does not explicitly list alternatives, but the context implies when to use single vs bulk tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true; description adds valuable context about preflight target validation, loop/duplicate checks, and dry_run capability. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no redundancy. Front-loaded with core purpose, then safety features. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, the description explains key behaviors (validation, loop/duplicate prevention, dry_run) and gating. Could mention return value structure, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond schema, primarily mentioning dry_run's purpose. Does not significantly enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a single dynamic redirect at the Cloudflare edge, with an example (301 for renamed/migrated URL). It distinguishes from siblings like cf_bulk_redirect_upsert (bulk) and cf_list_redirects (list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit gating condition (requires SEO_MCP_ALLOW_DESTRUCTIVE=true) and mentions validation, loop/duplicate refusal, and dry_run support. However, no explicit when-not-to-use or comparison with alternative tools like cf_bulk_redirect_upsert.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, so description does not need to reiterate. However, description adds important behavioral context: the gating by an environment variable (SEO_MCP_ALLOW_DESTRUCTIVE), which is not in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that deliver all critical information without unnecessary words. Front-loads the purpose and includes key usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple deletion tool with well-defined parameters and annotations, the description covers purpose, input source, and access control. No output schema is needed, and sibling tools provide relevant context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already covers both parameters with good descriptions (100% coverage). The description adds value by clarifying that rule_id comes from the cf_list_redirects tool, aiding the agent in understanding the data flow.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete one single (dynamic) redirect rule'), the resource ('redirect rule'), and the identifier ('by its id'). It also distinguishes itself from cf_create_redirect as the rollback path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to use this tool (as the rollback path for cf_create_redirect) and where to obtain the required input ('Get the rule id from cf_list_redirects'). Also mentions the gating condition requiring SEO_MCP_ALLOW_DESTRUCTIVE=true.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds behavioral context by specifying SEO migration use cases, which goes beyond the annotations and helps the agent understand the tool's role.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff: first sentence defines the operation, second lists practical use cases. Every word earns its place; it is as concise as possible without sacrificing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should compensate with details about the return format (e.g., fields like name, type, TTL, content). It omits this and does not mention pagination or limits, making it somewhat incomplete for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes both parameters ('type', 'zone') adequately. The description does not add any additional meaning or examples beyond what is in the schema, meeting only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'List DNS records for a zone (read-only)' – a specific verb and resource. It further clarifies use cases like verifying canonical host, CNAME flattening, and TXT records during SEO migrations, distinguishing it from sibling tools that manage zones or analytics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for verification tasks but does not explicitly state when to use this tool vs alternatives like cf_list_zones or cf_zone_info. No when-not-to-use or alternative naming is provided, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint. The description adds context about safe usage before mutation tools and mentions the output fields. However, it does not elaborate on pagination or behavior for large accounts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: purpose, usage guidance, and pairing. No wasted words. Information is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with no output schema, the description adequately describes what is returned (specific fields of redirect rules and Bulk Redirect lists). It also mentions the default zone behavior, making it complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the description does not add information beyond the schema's parameter docs. The tool description does not elaborate on the zone parameter beyond what is in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists a zone's single redirect rules and the account's Bulk Redirect lists, specifying the fields returned (source, target, status code, rule id). This verb+resource combination is distinct and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to call this before cf_create_redirect, cf_delete_redirect, and cf_bulk_redirect_upsert to prevent clobbering, and mentions pairing with redirect_chain_audit and migration_check prompt. This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe. The description adds that it returns specific fields (status, plan, id) but doesn't disclose potential rate limits or pagination. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the verb 'List'. No extraneous information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a parameterless read-only tool. It states the action, resource, and output fields. However, it lacks guidance on potential large result sets or limits, which could be relevant. Overall, it is mostly complete given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description adds value by specifying the output fields (status, plan, id) that go beyond the empty schema. This context helps the agent understand the return format without an output schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists Cloudflare zones with specific fields (status, plan, id). It uses a specific verb and resource, distinguishing it from sibling tools like cf_zone_info (which targets a single zone) and cf_list_dns (DNS records).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. The description implies it is for listing zones accessible by the API token, but lacks comparison to alternatives like cf_zone_info for detailed info. However, given the tool's simplicity, the omission is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behavioral traits: the mutual exclusivity of managed robots.txt and Content-Signals policy, the local rejection of invalid combinations, the gating of writes via confirm, support for dry_run, and that the return always includes a caveat. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with the description; the description adds significant context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured, starting with the overall purpose, then detailing actions, then constraints, and ending with return information. Every sentence contributes essential information. Minor redundancy could be trimmed, but it remains efficient for its complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 actions, 9 params, mutual exclusion, gates, no output schema), the description covers all necessary behavioral aspects: actions, parameter roles, constraints, gating, dry_run, and return caveat. Annotations complement but do not reduce the burden; the description is fully adequate for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all 9 parameters. The description adds value by explaining the purpose of parameters in context (e.g., what 'configure only' means, the valid combinations, and the role of each protection lever). However, much of the parameter meaning is already clear from the schema, so the description provides incremental but meaningful depth.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages Cloudflare's managed robots.txt and Content-Signals policy, enumerating three distinct actions (get, configure, disable) with specific behaviors for each. It distinguishes the tool's scope from siblings, which are mostly unrelated (GSC, PSI, etc.), and provides a specific verb+resource combination.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each action (get for reading, configure for enabling/setting, disable for turning off), mentions that writes require confirm and support dry_run, and notes the mutual exclusivity constraint. It does not explicitly list when not to use the tool, but the actions are self-explanatory and no direct sibling alternatives exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds the crucial gating requirement (SEO_MCP_ALLOW_DESTRUCTIVE) which is important behavioral context. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences: the first states the purpose and the second notes the gating requirement. No extraneous text; every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the annotations and lack of output schema, the description covers the core purpose and access control. It does not detail success/error responses or rate limits, but for a simple cache purge tool, the completeness is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptive parameter descriptions. The tool description does not add any additional semantic information about the parameters beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Purge' with the resource 'Cloudflare cache' and explains the purpose ('so crawlers refetch updated content'). It clearly distinguishes from the sibling tool 'cf_purge_cache_all' which purges all cache, making the scope explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool ('gated: requires SEO_MCP_ALLOW_DESTRUCTIVE=true') and implies it is for specific URL purging after content updates. However, it does not explicitly state when not to use it or compare with 'cf_purge_cache_all', though the sibling name provides context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructive and non-readonly nature. Description adds context: gating via environment variable and string confirmation, plus global impact. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first states purpose and effect, second explains gating. No superfluous words. Front-loaded with key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, scope, and gating. Does not detail post-purge behavior (e.g., cache rebuild), but for a destructive tool with annotations, this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover both parameters (zone with default, confirm must equal hostname). The description reinforces the confirm requirement in the usage context, adding value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states specific verb ('Purge') and resource ('entire Cloudflare cache for a zone'), with scope ('affects all visitors'). Clearly distinguishes from sibling cf_purge_cache (likely partial purge).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes gating conditions (env var + confirm value) needed to invoke the tool. Does not mention alternatives or when not to use, but the safety mechanism is well communicated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, etc. The description adds value by explaining read-only nature, why checks are 'verify' not 'fail', and that it grades only edge layer. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long but well-organized with front-loaded purpose. It includes bullet-like list and specific details. Could be slightly more concise, but no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, description is complete. It hints at return format (severity-graded findings with reason and benign exception) and answers the core question. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter `zone` with schema coverage 100%. Description adds context about defaulting to configured CF_ZONE, which is extra beyond schema. Baseline 3, so 4 for added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it audits Cloudflare zone settings for SEO and crawl/index safety, listing specific settings checked. It distinguishes itself from sibling tools like cf_settings_update and cf_zone_info by focusing on audit and safety grading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use: to check edge settings for SEO safety. It provides context about HSTS danger and 'verify' phrasing, but does not explicitly state when not to use or compare directly to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations show destructiveHint=true and readOnlyHint=false, matching description's 'Write' and 'Gated: requires...DESTRUCTIVE'. Description adds local validation, dry_run preview, and specific confirmation requirements for ssl_mode/HSTS, going well beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single, dense paragraph of four sentences. Every sentence adds value: purpose, gating, special confirmations, validation, and dry_run. No unnecessary words. Front-loaded with main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity (5 params, nested objects, interdependencies) and no output schema, description covers workflow, gating, and parameter constraints well. However, it lacks explicit mention of the response format for actual updates (only mentions dry_run preview). Minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions. Description adds critical context: 'Only the provided keys are changed' for settings object, explains confirm and acknowledge_hsts_risk conditions, and dry_run behavior. This meaningfully supplements schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool writes Cloudflare zone settings that cf_settings_audit grades, closing the audit-to-remediate loop. It uses a specific verb 'Write' and distinguishes from sibling tool cf_settings_audit which is read-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (remediate audit findings) and provides multiple usage conditions: requires SEO_MCP_ALLOW_DESTRUCTIVE=true, confirm parameter for sensitive changes, acknowledge_hsts_risk for HSTS, and supports dry_run. No sibling confusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the edge-measured traffic nature and how it complements GA4, providing behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise—three short sentences that are well-structured. The first sentence states the tool's purpose, the second explains the two usage modes, and the third provides additional context and limitation. No superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description could be more explicit about return data structure (e.g., 'returns site details including metrics'). However, the tool is simple and the domain is well-known, making it adequate for an experienced agent. The openWorldHint annotation also helps set expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter host_or_tag is fully described in the schema. The description adds parsing logic (hostname vs. site_tag) that goes beyond the schema description, giving clear semantic meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for Cloudflare Web Analytics (edge RUM), specifies two modes of operation (listing all sites or retrieving a site's detail), and distinguishes it from GA4 by mentioning edge measurement. The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use the tool without arguments (list all sites) and with the host_or_tag parameter (get one site's detail). It also notes that create/delete operations are intentionally not exposed, guiding the agent away from writing operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds value by listing specific output fields (status, plan, paused, name servers, created/modified).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 12 words, front-loaded with purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no output schema, description covers core functionality and output fields. Could mention output format (e.g., JSON), but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage for the single optional parameter 'zone', including example and default. Description adds no additional parameter details beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb+resource: 'Zone overview' for a hostname. Describes specific fields (status, plan, etc.), distinguishing it from sibling cf_list_zones which lists all zones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when needing overview of a specific zone, but does not explicitly state when to use vs alternatives or provide preconditions. No exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations confirm read-only, idempotent, non-destructive. The description adds that the tool fetches the URL, analyzes the canonical tag, and follows one 'canonical hop' to confirm 2xx, providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence covering all key actions and outputs without redundant words. It is front-loaded with the main action. However, it could be slightly more structured (e.g., listed items) for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single required parameter, no output schema, and comprehensive annotations, the description adequately explains the tool's functionality and expected output (reporting on canonical issues). It mentions following one hop, which is a key detail. Missing is explicit mention of return format or error handling, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'url' is fully described in the schema as 'Absolute http(s) URL to inspect.' The tool description adds that it fetches and analyzes, but no additional parameter meaning is needed. Schema coverage is 100%, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool fetches a URL and analyzes its canonical link tag, listing specific issues (self-referential, cross-host, protocol-mismatched, trailing-slash drift, missing canonical) and mentions following one hop. This uniquely identifies its function among many SEO analysis siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its purpose for canonical analysis but does not explicitly state when to use it versus alternatives like inspect_meta or mixed_content_check. No when-not-to-use or alternative names given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Read-only; no ranking guarantee' and explains the fallback behavior (refresh-vs-new, not full SERP), providing context beyond the annotations. There is no contradiction between description and annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and outputs, then covers parameters and fallback behavior. It is dense but not overly long; every sentence adds value. Slightly verbose due to parenthetical clarifications, but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately explains the return value (heading union, median word count, schema types, entity coverage, GEO directives). It also covers the two operational modes and parameter nuances. For a tool with 5 parameters, it is reasonably complete, though it could briefly mention the format of the return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds context for how parameters interact (e.g., 'competitor_urls' vs fallback, 'days' as GSC window) but does not provide additional semantic meaning beyond the schema descriptions for individual parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Gather the hard evidence for a content brief' and lists specific outputs (heading union, median word count, schema types, entity coverage, directives). It uses specific verbs ('fetch', 'return') and distinguishes itself by focusing on content brief evidence, which differentiates it from sibling tools like gsc_search_analytics or content_opportunities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use each mode: 'Pass competitor_urls for a true brief; with none it falls back to your own ranking pages via GSC (refresh-vs-new, NOT the full SERP).' It also provides context about integration with other components ('The host writes the brief prose from this; SEOMonster supplies rules + evidence'). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds behavioral context: it is read-only, fuses multiple signals into a transparent opportunity score, flags cannibalization, and reports click upside and score components. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence states the core purpose and output, the second clarifies limitations. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes the return value ('click upside plus the score's components'). It covers input parameters implicitly and explains the tool's scope and limitations, making it complete for an agent to decide usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The tool description provides no additional parameter-specific details beyond summarizing the overall purpose. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Rank') and resource ('data-grounded content/blog topics from your own Search Console data'), and clearly distinguishes itself by stating it 'does not do cold-start keyword research' and focuses on existing demand, differentiating from sibling tools like keyword_universe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'prioritize demand you already have'. Also clearly states what it does not do: cold-start keyword research, writing content, or guaranteeing ranking. While it doesn't name specific alternatives, the context signals list many sibling tools, and the description implies when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns data at p75 for specific metrics and a fixed number of periods (25), but does not elaborate on potential rate limits or data freshness. The value added beyond annotations is moderate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the core purpose and scope, the second connects it to a companion tool. Every word earns its place, with no redundancy. Highly efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description omits the return format (e.g., JSON structure) or pagination details. However, given the input schema is comprehensive and the tool has only 4 optional parameters, the description covers the primary usage scenario adequately. A small gap in output transparency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description's extra guidance on the mutual exclusivity of url and origin ('Use this OR origin.') adds practical value. It also clarifies that metrics are snake_case CrUX names, which is not fully explicit in the schema. This improves usability beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns the last 25 weekly collection periods of Core Web Vitals at p75 for a URL or origin via the Chrome UX Report History API. It distinguishes itself from psi_analyze by adding the trend axis, making its purpose specific and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a direct usage context by stating it complements psi_analyze with a trend axis. It also implies when to use (historical trend) vs. snapshot tools. However, it could explicitly mention not to use it for single-point data or when other siblings like crux_snapshot are more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: it returns a specific 28-day snapshot, uses p75 percentiles, and outputs per-metric categories plus an overall verdict. It also clarifies that no_data is a legitimate response for small sites, which is helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. Front-loads the core action and key details (metrics, time range, API). Every sentence adds value and the structure is highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return value (metrics, categories, overall verdict) and the possibility of no_data. It also mentions the underlying API. For a simple read tool with 3 well-described params, this is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions on each parameter. The description adds that url and origin are mutually exclusive alternatives, which is already implied in the schema descriptions. It does not significantly enhance parameter understanding beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns the current 28-day p75 Core Web Vitals snapshot for a URL or origin, listing exact metrics (LCP, INP, CLS, FCP, TTFB) and their categories. It distinguishes itself from the sibling tool crux_history by noting the difference between snapshot and trend.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs to use crux_history for 25-week trends and explains that small pages/origins may return no_data, setting appropriate expectations. This provides clear guidance on when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false; the description adds behavioral details (sort order, default filter) beyond those annotations, with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste: first sentence delivers core function and key details, second adds wrapper context. Every part is essential.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the tool's output (landing pages with conversions, breakdown, sort) adequately for a simple read-only tool with 100% schema-covered params. No output schema exists, but the description covers the basics; minor gap in explicit column listing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description repeats default values that are also in schema, adding no new meaning beyond what the schema provides—baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists landing pages with conversions/key events, broken down by channel group, sorted descending, and defaults to organic search. It calls itself a 'convenience wrapper over ga4_run_report,' which distinguishes it from siblings like ga4_top_landing_pages or ga4_run_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for SEO analysis by stating 'the SEO view' and default organic filtering. It provides context but does not explicitly state when not to use or compare to alternatives, though siblings hint at differences.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, etc. The description adds that it returns window totals and day-by-day trends, but doesn't disclose data freshness, rate limits, or auth requirements beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with clear information: first sentence defines output, second adds context about underlying reports. No fluff, but could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple two-parameter, read-only tool with no output schema, the description covers the key aspects: metrics returned, aggregation type, and trend. Edge cases like empty results are not mentioned, but acceptable for this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The tool description reiterates the lookback window but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides organic-search health metrics for a window plus daily trends, and specifies the metrics (sessions, engaged sessions, etc.). It distinguishes from sibling GA4 tools like ga4_traffic_by_channel by focusing on organic search overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., ga4_run_report, ga4_traffic_by_channel). Does not mention prerequisites or exclusions. The note 'Two GA4 reports under the hood' is vague.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, open-world, and idempotent. The description adds value by specifying date format support (ISO and GA4 relatives) and default values (dimensions, metrics, start_date), enhancing beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. Efficient but could be slightly expanded to include more usage hints without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, no output schema, and annotations present, the description covers key behavioral aspects and parameter defaults. Lack of return value explanation is a minor gap, but overall fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant meaning: explains 'days' as convenience alias, 'limit' alias for row_limit, details on date formats, and structure for dimension_filter and order_by objects. This greatly assists parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it runs a GA4 report with arbitrary dimensions, metrics, date range, filter, and ordering. It is labeled as 'the workhorse GA4 tool', distinguishing it from specialized siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies general-purpose use but does not specify when to use alternatives or when not to use this tool. No explicit guidance on filtering to other GA4 tools like ga4_top_landing_pages.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying that findings are severity-graded with reasons and benign exceptions, and explicitly states it is read-only. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and read-only nature, then concisely enumerates checks. It is somewhat verbose but every sentence provides useful detail. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (multiple checks, severity output) and simple schema, the description adequately covers what the tool does and the nature of its output. It does not detail the exact return format but that is partially covered by mentioning severity-graded findings, which is sufficient for an audit tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the parameter description already stating format and default behavior. The tool description does not add additional semantics beyond the schema, so no extra benefit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool audits a GA4 property's configuration for SEO-measurement readiness. It lists specific checks (web data stream, key events, data retention, custom dimensions, enhanced measurement, Google Signals) and clearly answers a specific question ('can this property actually measure my organic outcomes?'). This distinguishes it from sibling tools like ga4_run_report or gsc_coverage_audit, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for assessing GA4 property readiness for organic measurement, and clarifies it checks hygiene, not business events. It does not explicitly state when not to use it or provide alternatives, but the context of answering a specific question gives reasonable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by disclosing that the tool honestly reports absence of site-search data rather than implying zero demand, a behavioral trait beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences front-load the core purpose, add context (content-gap signal), and note edge-case behavior. No wasted words; every sentence is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 3 optional parameters and no output schema, the description adequately covers return fields (event count, sessions) and error handling (no data). Could mention pagination or result ordering, but limit parameter mitigates this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are fully described in the schema (100% coverage). The description adds minimal additional meaning beyond 'last N days', providing no new details about parameters. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves internal site-search terms, specifying the metric (searchTerm), dimensions (event count and sessions), and positions it as a content-gap signal. It also distinguishes itself from ga4_run_report as a convenience wrapper, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for site search data and mentions honest reporting when no data exists, but lacks explicit guidance on when to use this tool versus other GA4 tools (e.g., ga4_top_landing_pages). However, its specificity to site search and wrapper nature provide sufficient context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, not destructive. The description adds that it's a convenience wrapper but no additional behavioral traits (e.g., rate limits, pagination). With annotations covering safety, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. First sentence covers purpose and metrics; second adds the key filter and wrapper context. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool with 100% schema coverage and annotations, the description is fairly complete. It mentions returned metrics. Without an output schema, more detail on results would be helpful but not critical for this straightforward tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter documented. Description reinforces the organic_only default and the wrapper nature. Baseline 3 is correct when schema does the heavy lifting, and description adds limited extra meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns top landing pages with sessions, engagement rate, and conversions over N days, defaulting to organic search. It distinguishes itself from ga4_run_report by being a convenience wrapper, and from other GA4 tools by its specific focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use (SEO view, organic default) and that it's a wrapper over ga4_run_report, implying ga4_run_report for more flexibility. However, it doesn't explicitly exclude other siblings like ga4_organic_search_overview, which could overlap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds minimal behavioral context beyond being a convenience wrapper, such as potential limitations compared to ga4_run_report. With strong annotations, the description adds some but not substantial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loading the key metrics and purpose. Every sentence is essential, with no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (3 optional parameters, strong annotations, no output schema), the description covers the core purpose and relationship to a sibling. It could include more on output format or default channel groups, but overall it provides sufficient context for a quick analytics tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter (days, limit, property_id) having descriptions. The description mentions 'last N days' which aligns with the days parameter but adds no new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves sessions, engaged sessions, and conversions broken down by default channel group over a specified period. It also notes it separates organic from paid/referral/direct and positions itself as a convenience wrapper over ga4_run_report, distinguishing it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for quick channel breakdowns and mentions it's a convenience wrapper over ga4_run_report, but does not explicitly state when to use this tool vs alternatives like ga4_organic_search_overview or ga4_top_landing_pages. Lacks explicit when-not or alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, idempotent), description adds specifics: cap of 25 URLs, per-URL results and failure lists, and graceful error handling. Does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-loading key info (cap, results, error handling) with no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers return structure (results per URL, list of failures) for an agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. Description does not add extra parameter-level meaning beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it inspects multiple URLs in one call with a cap of 25, distinguishing it from the single-URL sibling gsc_inspect_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for batch inspection; mentions per-URL error handling which guides appropriate use, but lacks explicit when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, not destructive. The description adds valuable behavioral details: returns per-key deltas, includes keys in only one window, and explains the anomalies_only output (sigma_used). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but well-structured: front-loads the core purpose then details. Every sentence provides value, though slightly dense. Could be broken into two sentences for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description explains return values (per-key deltas, keys in only one window, filters_applied.sigma_used). It covers the main behavioral aspects adequately, though it could mention the response structure more explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, baseline 3. The description adds context beyond the schema, such as the note about sort_dir for delta_position reversal and the z-score cutoff explanation for anomalies_only. This enhances parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: compare two equal-length time windows and return per-key deltas. It distinguishes itself from siblings by noting that it covers multiple comparison types (biggest gainers, losers, movers, outliers) without needing separate tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (comparing periods, finding gainers/losers/outliers) and describes optional filters and the anomalies_only feature. It does not explicitly state when not to use it, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnly, openWorld, idempotent, non-destructive) are consistent with description. Description adds behavioral details: chunking in batches of 25 (due to GSC limits), cap of 200 URLs, and heuristic nature. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is three concise sentences with no redundancy. Front-loaded with 'heuristic coverage audit', explains the gap, and ends with output utility. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, description adequately explains output (verdicts: PASS/PARTIAL/FAIL plus coverage_state frequencies) and how it can be used for further inspection. Covers input limits and purpose fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage; both parameters (urls, site_url) are described in schema. Description does not add new semantic information beyond schema, but the schema coverage is high, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool performs a heuristic coverage audit of URLs, acting as a substitute for the GSC Index Coverage report which is not available via API. It specifies the input is a user-supplied URL list and output is a rollup of verdicts. Differentiates from sibling tools like gsc_inspect_url by focusing on bulk audit and rollup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context that the tool fills a gap (missing Coverage API) and mentions how the AI host can use the rollup to decide on deep-inspection. Does not explicitly state when not to use or compare with alternatives, but the context is sufficiently clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, non-destructive, etc. Description adds that it returns declining pages, providing behavioral context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first defines output, second gives use case and sibling equivalence. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters with full schema coverage and no output schema, the description is complete enough. It could mention return fields but sibling tools provide context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage, so baseline is 3. Description does not add extra meaning beyond what the schema already provides for each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns pages whose impressions fell over two periods, and explicitly equates it to a sibling tool with specific parameters, distinguishing it from similar tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the use case: 'lifecycle triage (find pages to invest in or rescue)'. Also notes equivalence to gsc_compare_periods, helping the agent choose between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by elaborating on the specific data returned (index verdict, coverage state, crawl info, canonicals, mobile/rich-results). No contradictory information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the purpose ('Inspect a single URL') and efficiently lists the returned data types. No waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description compensates by listing key return fields. However, it uses terms like 'index verdict' without explanation and omits prerequisites (e.g., valid property) or error conditions. Still fairly complete for a read tool with rich annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add any meaning beyond what the schema provides for the parameters themselves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inspects a single URL via the URL Inspection API and lists the specific information it returns (index verdict, coverage state, crawl info, canonicals, mobile/rich-results). It distinguishes from the sibling tool gsc_batch_inspect_urls which operates on multiple URLs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for detailed inspection of a single URL, but does not explicitly state when to use this tool versus alternatives like gsc_search_analytics or gsc_batch_inspect_urls. No exclusion criteria or context are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint and idempotentHint. The description adds critical behavioral context: explains the 'footprint verdict' and confidence band, and crucially discloses that GSC hides ~75% of impressions, making results hypothetical. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise at 7 sentences, front-loaded with purpose, each sentence adds necessary detail without redundancy. Well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, the description adequately explains the return (footprint verdict and confidence band) and addresses the hypothetical nature of results. Covers all key aspects of use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, but the description adds value by explaining how to obtain candidates ('brainstorm from winning queries') and for 'days' adds 'wider = more footprint visible'. This enriches understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Ground... candidates to find net-new terms') and clearly distinguishes from sibling tools like gsc_top_queries by recommending it as a prerequisite. It leaves no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs the user to brainstorm candidates from gsc_top_queries first, providing clear context. However, it does not explicitly mention when to avoid this tool in favor of other siblings like gsc_query_gaps, though the workflow is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by noting that permission levels are returned, offering behavioral context beyond what annotations convey. There is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is composed of two short, precise sentences that convey the purpose and a usage hint. There is no redundant or unnecessary information, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (zero parameters, no output schema), the description is fully adequate: it states what the tool does, what it returns (permission levels), and why to use it (discover site_url values). No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters (schema is empty), so schema description coverage is 100%. The description does not need to elaborate on parameters; a baseline of 4 is appropriate for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') with a clear resource ('every Search Console property') and adds context ('with each property's permission level'). It distinguishes this tool from siblings by its unique role of enumerating properties for discovery of valid site_url values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to 'Use this to discover valid site_url values', which provides clear context for when to invoke the tool. However, it does not mention when not to use it or provide alternatives, which slightly limits the guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is clear. Description adds value by specifying the output includes submission and indexing status. Does not mention pagination or limits, but for a simple list tool this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 15 words front-loads the action. Every word earns its place; no redundancy. Highly concise and structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no required parameters, no output schema), the description covers the key purpose and output. Annotations provide safety context. Could mention whether multiple site_url calls are needed for different properties, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (site_url described as optional with default). Description adds no additional information beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb (list), resource (sitemaps), scope (for a property), and includes what is reported (submission and indexing status). It distinguishes from sibling tools like gsc_submit_sitemap and sitemap_validate by focusing on listing known sitemaps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description does not explicitly state when to use this tool versus alternatives (e.g., sitemap_validate, sitemap_health). It implies use for retrieving Google's view of sitemaps, but lacks explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent behavior. The description adds the key behavior of comparing two windows and filtering for zero prior impressions, which is beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence followed by a use-case statement, with no redundancy or filler. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description omits what the output contains (e.g., query strings, metrics like impressions/clicks). Since there is no output schema, the description should provide this context to help the agent use the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so the schema itself explains most parameters. The description does not add additional meaning beyond what's in the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns queries with impressions in the current window but none in the prior window, which is a specific verb+resource. It distinguishes from sibling tools like gsc_top_queries by focusing on new queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions utility for spotting emerging topics, which implies when to use. However, it lacks explicit exclusions or comparison to alternatives like gsc_compare_periods or gsc_query_opportunities.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate it's read-only and idempotent. The description adds value by detailing the output fields and mentioning the data state and alias convention, going beyond annotation hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each purposeful. The first front-loads the core purpose, the second specifies output and use case, the third adds technical details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and rich annotations, the description fully covers purpose, return format, filtering options, and behavioral details. No gaps for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description adds the alias convention for the 'days' parameter, providing extra context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists every property and returns a one-row summary per property with specific metrics. It distinguishes itself from siblings like gsc_list_properties and gsc_search_analytics by positioning as a portfolio-level view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states it's the fastest answer for portfolio performance across multi-property setups, providing clear context. However, it does not explicitly mention when not to use it or list alternative tools for deeper analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds sorting behavior (by impressions descending) and selection criteria beyond the readOnlyHint and other annotations. It does not contradict annotations and provides useful context without major gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted text. Directly states purpose, selection criteria, and sorting. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and many sibling tools, the description is fairly complete. It explains what is returned and the sorting, though it could mention typical use cases for output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80% (4 of 5 parameters described). The description does not add significant extra meaning for parameters beyond what the schema provides, and it does not clarify the undocumented site_url parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool returns queries with high impressions but low clicks, identifying content opportunity signals. It uses a specific verb-resource combination and implicitly distinguishes from sibling tools like gsc_top_queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies when to use: to find content opportunities where impressions exist but clicks are lacking. However, it does not explicitly state when not to use or mention alternatives, though the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly and idempotent. The description adds behavioral details: sorting by impressions descending and rationale for CTR lift, which is valuable beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no waste, front-loaded with purpose. Every word contributes value, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains return format (rows sorted by impressions) and rationale. It covers filtering criteria (position, CTR, impressions min) but omits mention of limit parameter or pagination. Overall fairly complete for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. Tool description does not add new meaning beyond the schema, only references 'top N positions' and 'below-target CTR' which align with existing parameter descriptions. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool identifies queries ranking in top positions with below-target CTR for optimization, using specific verbs and resource. It distinguishes itself from siblings like gsc_query_gaps (queries not ranking) and gsc_top_queries (all top queries, no CTR filter).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for title/meta-description optimization candidates, providing clear context. However, it does not explicitly state when not to use or compare to alternatives, leaving some implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate write, idempotent, non-destructive. Description adds specific behavioral details: batch error handling, notify_time null being normal, scope error remediation. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no wasted words. Front-loaded with purpose then usage and edge cases. Each sentence adds necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description covers error behavior and expected null value. Could mention success response structure, but for a simple write tool it is adequate. Context of scope and availability is given.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value beyond schema: clarifies that url or urls is required (schema lists no required), explains site_url as informational/project-scoped, and reinforces max 100. This is helpful for proper invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States clear action: 'Ask Google to (re)crawl one or more URLs via the Indexing API (URL_UPDATED)'. Verb+resource+method is specific and distinct from siblings like indexnow_submit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions required scope ('Requires the indexing scope') and availability ('Available by default'). Describes error handling for scope/per-URL errors. Lacks explicit mention of alternatives like indexnow_submit, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal behavioral context beyond what is in the schema (e.g., mentioning data_state). It does not add new details about rate limits or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two clear, front-loaded sentences with no wasted words. The first sentence conveys the core action and output; the second adds a useful label. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters and no output schema, the description is brief but covers the essential purpose. It does not explain return format or pagination, but these are implied by the parameters. Adequate for a general query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no additional parameter meaning beyond restating the dimensions, date range, and filters already documented in the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it queries Search Console search analytics (clicks, impressions, CTR, position) for a property, with specific parameters. It brands itself as 'the workhorse GSC tool', distinguishing it from sibling tools that focus on specific subsets like top queries or pages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest sibling tools for specific needs, leaving the agent to infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the auth requirement and availability, but does not explain behavior like error handling or confirmation of submission. With rich annotations, the description provides adequate but not exceptional additional context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the core purpose and essential requirements. Every sentence adds crucial information without redundancy. It is efficiently structured and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description could mention what the user can expect after submission (e.g., success confirmation or asynchronous processing). It covers auth, availability, and parameter choice, but misses result transparency. This is a moderate gap for a write operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description's contribution is additive. It explains the relationship between sitemap_url and feedpath, recommending sitemap_url as the friendly name. This adds value beyond the schema descriptions, which already include the alias information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Submit a sitemap') and the target system ('Search Console'). The verb-submit is unique among sibling tools, and the description distinguishes it from read-only tools like gsc_list_sitemaps by implying a write operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides useful guidance: required scope ('writable webmasters'), availability ('routine SEO task; not gated'), and preferred parameter ('sitemap_url' vs. 'feedpath'). It does not explicitly contrast this tool with siblings, but the unique action makes context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: default data_state of 'all' and that 'final' lags 2-3 days behind the dashboard. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero wasted words, front-loaded with purpose and key equivalence. Efficiently conveys all essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple wrapper tool with no output schema, the description covers purpose, equivalent tool, data lag, and parameter defaults. It is fully adequate for an agent to understand invocation and behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. The description adds context that results are sorted 'by clicks' and mentions default values for days and limit, which are also in schema but reinforces usage. Adds meaning beyond schema by noting equivalence and data_state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'convenience wrapper' that returns top pages for a property by clicks over N days, and explicitly equates it to gsc_search_analytics with dimensions=['page']. This distinguishes it from siblings like gsc_search_analytics and gsc_top_queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for quick top-pages retrieval by calling it a 'convenience wrapper' and noting data_state behavior. It does not explicitly state when to use this vs. gsc_search_analytics or other tools, but the equivalence provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds behavioral context: filtering by exact query match and returning rows by page dimension. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first provides clear purpose, second adds contextual relevance. No unnecessary words. Very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given rich annotations (readOnlyHint, idempotentHint) and complete schema, the description provides sufficient context. The real-world cannibalization audit example adds completeness. No output schema, but standard rows are implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for all parameters. The description adds minimal value beyond emphasizing 'exact query match', but schema already covers parameter semantics adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns pages ranking for a specific query with a specific use case (cannibalization audit). It uses a specific verb-resource combination and distinguishes itself from sibling tools like gsc_top_queries and gsc_top_pages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly frames the tool as input for a decannibalization audit and explains the action to take if multiple pages rank for the same query. While it does not state when not to use it, the context is clear enough for appropriate selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, etc. Description adds value by explaining data_state behavior and the equivalence to gsc_search_analytics, which provides deeper behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, immediately states purpose. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple wrapper tool, description covers purpose, alternative, data_state nuance, and parameter defaults. Without output schema, it provides sufficient context for usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. Description adds default values (days=28, limit=50, site_url defaults to configured) and explains the meaning of the equivalent query dimensions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly specifies it is a convenience wrapper for top queries by clicks over last N days, equivalent to gsc_search_analytics with dimension 'query'. It differentiates from siblings like gsc_search_analytics and gsc_top_pages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context as a 'convenience wrapper', implying simpler alternative to gsc_search_analytics. Notes data_state behavior and default settings. Could be more explicit about when not to use, but sibling names guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds that the tool compares two time windows and sorts by delta impressions descending, providing behavioral context beyond annotations but not extensive details on rate limits or data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states the function concisely, second provides a use case. No extraneous words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 3 parameters, clear annotations, and an explicit equivalence hint, the description covers the purpose and usage well. It lacks explicit mention of return format, but the equivalence partially compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, only implicitly relating 'days' to the window length. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns pages with the most impression growth over two windows, explicitly distinguishing itself by referencing equivalence to gsc_compare_periods with specific parameters. It differentiates from siblings like gsc_decaying_pages and gsc_top_pages by focusing on growth over time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use this for lifecycle triage (find pages to invest in or rescue).' It also hints at an alternative (gsc_compare_periods) for more flexibility, though it does not list explicit when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral details: the specific checks performed (missing reciprocity, broken URLs, etc.) and the return format (per-URL and global findings). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.