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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description is not required to restate it. However, the description adds nothing behavioral beyond those hints — it doesn't say whether adding an already-registered site is a no-op (which idempotentHint implies), what permissions are needed, or when the addition takes effect. For a mutation tool it is thin.

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?

Front-loaded with the purpose in one sentence, followed by a compact Args block. Slightly formulaic but nothing is wasted, and the format examples earn their 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?

An output schema exists, so return values need not be explained, and the single common case is covered. Still missing are edge behaviors (duplicate site, permission/verification errors) that matter for a mutation tool with no usage guidance.

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 0% and the schema only declares site_url as a bare string, so the description carries the burden — and it does so well by giving concrete format examples ('https://example.com' or 'sc-domain:example.com'). This is exactly the added semantics the schema lacks.

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 a specific verb and resource ('Add a site to your Search Console properties'), which cleanly distinguishes it from siblings like delete_site and list_properties. It stops short of explicitly naming an alternative, but the purpose is unmistakable.

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, no prerequisites (e.g. verification requirements), and no mention of what happens if the site already exists. The agent must infer usage entirely 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety and network profile. The description adds that it actually fetches the page (live network call) and what categories it inspects, which is modest additional context but no detail on rate limits, depth, or failure behavior.

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?

Front-loaded single sentence stating the action and scope, followed by a minimal args block. The 'Args' restatement is slightly redundant against the schema but not wasteful.

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?

An output schema exists, so return values need not be described. For a single-parameter read tool this is nearly sufficient, but the absence of any routing guidance among many similar SEO-fetch siblings leaves a real 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 0% and there is one parameter. The description's 'url: Full page URL' clarifies that a complete, absolute URL is expected rather than a path or domain, partially compensating. It still does not specify accepted schemes, query handling, or redirect behavior.

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 a specific verb (analyze) and resource (page SEO), and enumerates the analysis scope: on-page signals, structured data, and indexability hints. An agent can tell what it does, though it does not differentiate itself from overlapping siblings like inspect_url, crawl_site_seo, or audit_live_site.

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 gives no when-to-use guidance, prerequisites, or named alternatives, despite many adjacent tools (inspect_url, audit_live_site, run_lighthouse_audit, crawl_site_seo). The agent must infer selection from the name alone.

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, openWorldHint, and non-destructive, so the safety profile is supplied structurally. The description adds real behavioral value by disclosing that it fetches the sitemap and issues GET requests to validate a sample of URLs, which hints at side effects and runtime cost, but it says nothing about how many requests, rate limits, or failure handling.

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?

Front-loaded with the core action, then a compact Args block; every line carries information. Slightly duplicative of the schema's property names, but nothing is wasted or padded.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. Still, for an open-world fetch-and-validate tool the description omits meaningful behavior such as sitemap-index recursion, sampling failures, and any indication of what the analysis reports.

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 0%, so the description must carry the burden, and it does: sitemap_url is specified as a 'Full sitemap URL' and sample_urls as the 'Number of sitemap URLs to validate with GET requests'. This adds meaning beyond the bare schema titles, though it omits the default value (5) and any bounds on the integer.

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 a specific verb+resource ('Fetch and analyze an XML sitemap or sitemap index'), which an agent can distinguish from list-style siblings like get_sitemaps or write siblings like submit_sitemap/delete_sitemap. However, it never names those siblings explicitly, so the differentiation is inferred rather than stated.

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 choose this over get_sitemaps, submit_sitemap, or the audit tools. The description says what it does but gives no context, prerequisites, or exclusions, leaving the agent to infer whether this is for diagnosis, validation, or inventory.

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 cover readOnly, idempotent, openWorld, and non-destructive, so the safety bar is low. The description adds real behavioral context: this is a composite operation that performs a crawl and can optionally spawn a local Lighthouse CLI process, which is a heavyweight side effect worth knowing. It stops short of noting runtime, rate limits, or crawl cost.

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?

Front-loaded with the one-sentence purpose, followed by a compact Args block. Every sentence carries information; the only minor inefficiency is the plain-text 'Args:' formatting, which is tolerable but not the most structured presentation.

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?

An output schema exists, so return-value documentation is not required. For a moderate-complexity composite audit tool, the description covers what it does, what inputs mean, and the notable Lighthouse side effect. Remaining gaps are environmental details (runtime, crawl limits) rather than anything blocking correct invocation.

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 0%, so the description must carry the load, and it does reasonably well — 'Full site/page URL' hints at URL format, crawl_pages is explained by its purpose (duplicate/missing-tag issues), and include_lighthouse explicitly notes it runs a local Lighthouse CLI audit. Defaults (5, false) are not restated but the meaning of each parameter is conveyed.

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 a specific verb and resource ('Run a live SEO audit') and immediately names the key differentiator — no Search Console access required — plus the sub-analyses it bundles (page analysis, robots.txt, sitemap, PSI, same-origin crawl). It does not explicitly distinguish itself from close siblings like site_audit, crawl_site_seo, or get_seo_audit_report, which keeps it short of a 5.

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 phrase 'without requiring Search Console access' implies the usage condition (use when GSC is unavailable), but there is no explicit when-to-use statement, no prerequisites, and no routing to alternatives such as run_lighthouse_audit or crawl_site_seo. Usage is only 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 establish readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful operational context beyond that: automatic rate-limit handling, the 2000/day and 600/minute API quotas, and the 50-URL per-call ceiling. It does not describe failure behavior for oversized batches, keeping it short of a 5.

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?

Purpose, rate limits and the 50-URL cap are front-loaded in the first three short sentences, followed by a compact Args block. No sentence is redundant and nothing is buried.

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 an output schema present, return values need not be explained, and the description covers quotas, batching limits and both parameters' formats. What is missing is error/partial-failure behavior for batches that exceed 50 URLs or hit the daily quota, which would matter for a bulk 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 0%, so the description carries the full burden and does so: it explains site_url is an exact GSC property URL and gives the 'sc-domain:example.com' format, and clarifies that the urls string parameter is actually a newline-separated list ('one per line'). That resolves an ambiguity the bare 'type: string' schema leaves open.

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 a specific verb and resource ('Inspect multiple URLs for indexing status') and the batch scope is explicit with the 'up to 50 URLs per call' cap. It distinguishes itself from the single-URL sibling inspect_url only implicitly through the word 'multiple'; it never names inspect_url as the single-URL alternative.

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 50-URL cap and rate-limit handling imply that this is the tool for bulk inspection, but there is no explicit when-to-use or when-not-to-use statement, and no reference to the sibling inspect_url for single-URL cases. Usage is inferable from the batch framing rather than stated.

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 non-read-only, non-idempotent, open-world mutation, and the description adds substantive behavior beyond them: sequential processing, rate limiting, a daily quota, and a 100-URL batch cap. It doesn't say what happens on partial failure or how the quota is consumed across batches, which keeps it short of a 5.

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?

Front-loads the purpose and operational constraints in four tight sentences with no filler. The 'Args:' block is slightly redundant with the schema but cheap and harmless.

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?

An output schema exists so return values need no explanation, and the description covers the key constraints an agent needs (eligibility, quota, batch size, rate limiting). Minor gaps remain around failure/partial-success behavior, but nothing critical 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 0% (the single parameter is just typed string with title 'Urls'), so the description carries the full burden and delivers: format (one URL per line) and a hard limit (max 100 per batch). This is exactly the added meaning the schema lacks.

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 a specific verb and resource ('Request indexing') scoped to multiple URLs, which implicitly distinguishes it from the single-URL sibling request_indexing. It does not name the sibling explicitly, so the differentiation relies on the agent noticing '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?

Gives a concrete eligibility rule ('Only for pages with JobPosting or BroadcastEvent structured data') and quota context (200/day), which tells the agent when this tool is appropriate. It never explicitly routes to request_indexing for single URLs, so the alternative-selection guidance is incomplete.

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, so the safety profile is covered. The description adds the useful scoping detail that only the *latest* notification is returned (no history), but says nothing about where the notification data originates or what states can come back.

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 purpose sentence is front-loaded and wastes nothing; the 'Args:' block adds little but is conventional and brief. Overall appropriately sized for a single-parameter lookup.

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?

An output schema exists, so return values need not be explained, and the read-only annotations cover behavior. Still missing is the source/system context (e.g., Search Console notification) and any hint about acceptable URL format, which leaves the definition only minimally viable.

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 single parameter has 0% schema description coverage, so the description must carry the load, and it does not: 'The URL to check' merely restates the parameter name. It omits whether a full page URL, a domain property, or a URL-prefix property is expected.

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 a specific verb (check) and resource (latest indexing notification status) scoped to a URL, which is clearly distinct from request_indexing and batch_request_indexing. It stops short of naming how it differs from the nearby inspect_url, but an agent can still tell what it does.

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?

There is no when-to-use guidance, no prerequisites (e.g., whether the URL must be a verified property), and no mention of alternatives such as request_indexing or inspect_url. Usage must be inferred entirely from the name and one-line purpose.

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/non-destructive, and the description adds genuine behavioral context: missing pages are not counted as resolved, and mismatched crawl settings invalidate the comparison. That is meaningful beyond the schema, though return value/pagination behavior is left unstated.

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 terse, front-loaded sentences with no filler; the main action leads and constraints follow. Slightly dense and fragmentary, but every sentence 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?

For a read-only tool whose safety profile is covered by annotations, the description handles edge cases well but omits prerequisites (how to obtain baseline/current snapshot ids, presumably via list_project_audits) and says nothing about the comparison 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 description coverage is 0% for all three required parameters, so the description carries the full burden. It never explains the roles of project_id, baseline_id, or current_id, nor that ids must reference retained snapshots — a real gap for a comparison 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?

States a specific verb (compare) and resource (two retained project snapshots), which distinguishes it from compare_seo_audits and compare_search_periods by scope. It does not, however, explicitly name those siblings to reinforce the distinction.

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?

Gives partial constraints on when comparison is valid (differing crawl settings cannot be compared) but offers no explicit when-to-use versus the sibling compare_* tools, or where the required snapshot ids come from. Usage is implied rather than instructed.

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, destructiveHint=false and openWorldHint, covering the safety profile. The description adds no behavioral context beyond that, such as how the comparison is computed, whether missing data is handled, or any rate/latency characteristics. It is not contradictory, just thin.

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 one-line purpose is front-loaded and clean, followed by a structured Args block. The Args list largely mirrors schema titles/defaults, which is slightly redundant, but it is efficient and appropriately sized for a 7-parameter tool.

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?

An output schema exists, so return values need not be explained. However, for a comparison tool the description omits constraints that affect correct invocation, e.g. whether periods should be equal length or how the deltas are framed. Adequate but with a clear 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 description coverage is 0%, so the description must carry the burden, and it does add real meaning: 'Exact GSC property URL', the YYYY-MM-DD date format, and semantics for dimensions ('to group by') and limit ('top N'). It falls short of enumerating allowed dimension values or confirming the date format applies to all four period fields.

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 a specific verb and resource: 'Compare search analytics between two time periods.' That clearly distinguishes it from get_search_analytics and get_advanced_search_analytics, which are single-period analysis. It stops short of naming those siblings or explicit scope boundaries, so it scores a solid 4 rather than 5.

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?

Only the implied context 'between two time periods' signals when to use it. There is no statement of when-not to use it or which sibling (compare_seo_audits, compare_project_audits, get_search_analytics) an agent should pick instead, and no prerequisites such as whether both periods must be equal length.

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, idempotent, non-destructive, closed-world behavior, so the description is not carrying the safety burden. It still adds real value beyond annotations: it enumerates the classification outcomes and discloses two behavioral traits (no URL fetching, no file writes) plus the important caveat that missing/failed pages never prove resolution.

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 tight sentences with zero padding. The core purpose and input source lead, followed by classification behavior and the key caveat, all front-loaded and each earning 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?

With an output schema present, return-value explanation is not required. The description covers input provenance, the no-fetch/no-write constraint, and the resolution caveat, leaving nothing an agent needs to call 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 description coverage is 0%, so the description must compensate. It explains that both inputs are JSON outputs of get_seo_audit_report, which maps the two parameters to their expected content, but it does not explicitly clarify the baseline-vs-current ordering or format expectations beyond that.

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 a specific verb (Compare) and precise resources (two JSON outputs of get_seo_audit_report), and explicitly names the sibling tool that produces the inputs. An agent can distinguish it from related tools like compare_project_audits or get_seo_audit_report without opening a schema.

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?

Ties use to a concrete source (outputs of get_seo_audit_report) and states the prerequisite that crawl settings must match. There is no explicit when-not or alternative routing, but the input provenance and precondition give clear context for when the tool applies.

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 establish readOnly, idempotent, non-destructive, openWorld, so safety is covered. The description adds real operational context not in annotations: robots.txt is respected by default, max_pages counts failed and non-HTML fetch attempts, and disabling robots is only sanctioned for owned sites.

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?

Four short sentences, front-loaded with purpose, then the sibling route, the parameter caveat, and the safety caveat. No filler and nothing repeated from schema or annotations.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the robots default, the fetch-attempt accounting, and the sibling alternative; only start_url's expected form (absolute vs relative, protocol handling) is untouched, which is a small omission.

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 0%, so the description must carry parameter meaning, and it does for two of three: max_pages is defined as a bound on fetch attempts including errors/non-HTML, and respect_robots is framed by its default and the condition for turning it off. start_url is left to its self-evident name, which is a minor gap.

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 a specific verb and resource with scope ('Crawl same-origin raw HTML and summarize issues') and explicitly separates itself from the sibling get_seo_audit_report. An agent can pick between crawl-based summarization and structured reports without opening either schema.

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?

Names the alternative (get_seo_audit_report) and the condition that selects it ('structured evidence and remediation'), and adds a when-not guard ('Disable robots only for a site you control'). Routing and exclusions are both explicit.

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 the annotations (which already flag it as a non-read-only, non-destructive write), the description discloses where files are stored (SEO_AUDIT_DATA_DIR or platform user-data dir), an environment prerequisite (optional browser dependency plus installed Chromium for rendered modes), and server-side caps. It does not state what happens when a project_id already exists, which matters given idempotentHint=false.

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?

Five short sentences with no filler, and the purpose statement is front-loaded before the constraint details. The constraints are listed as a somewhat flat sequence rather than grouped by parameter, which slightly hurts scanning.

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 six-parameter mutation tool with 0% schema coverage and no output schema, this is close to complete: limits, storage location, ID format and browser prerequisites are all covered. The gaps are the two undocumented parameters (start_url, include_sitemaps) and duplicate-ID 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 description coverage is 0%, so the description must carry the burden, and it documents four of six parameters: project_id format rules, retention range and default, max_pages range with the server-config cap, and render_mode's dependency. It leaves the required start_url and include_sitemaps completely unexplained, which keeps it out of the top band.

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 first sentence names a specific verb and resource (create a local project) and adds scope qualifiers (robots-aware settings, scheduling disabled) that separate it from run_project_audit, list_audit_projects and set_audit_schedule. It never names a sibling explicitly, so it stops short of a 5.

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?

Usage context is only implied: 'scheduling disabled' hints that scheduling is a separate concern handled by set_audit_schedule, and 'create a project' implies this is the prerequisite step before run_project_audit. There is no explicit statement of when to call this versus the other project tools, and no prerequisites 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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond those hints: it does not say whether removal is permanent or reversible, whether verification/ownership is required, or what happens to associated data, which are the questions a destructive tool actually raises.

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 short lines with the purpose front-loaded and zero filler; the Args block is a compact, conventional way to document the parameter. It earns its length, though it is arguably under-specified rather than optimally 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?

An output schema exists, so return values need no explanation, but for a destructive, open-world mutation the description omits auth/verification requirements and irreversibility, which an agent needs before invoking it. The definition is not complete enough for the operation's risk profile.

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 0% — site_url has only a title and type, with no format expectations. The description's 'The URL of the site to remove' only rephrases the parameter name and leaves open whether a full URL with protocol, a domain, or a scoped property string is expected.

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 names a specific verb and resource ('Remove a site from your Search Console properties'), which is enough for an agent to distinguish it from add_site and delete_sitemap without opening either schema. It stops short of explicitly naming those siblings, so it falls short of a 5.

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?

There is no when-to-use guidance, no prerequisites (e.g. the site must already be verified in the account), and no exclusions relative to the sibling tools. The agent must infer the usage context entirely.

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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The parenthetical '(unsubmit)' adds real value by clarifying the sitemap file is not deleted, only its GSC submission removed, but nothing about permissions or immediate effect is disclosed.

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?

One-line purpose followed by a compact two-item Args block; front-loaded and free of filler. The Args list duplicates schema property names, but given 0% schema coverage that repetition is justified.

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 an output schema present, return values need no explanation, and both parameters are documented. The only gap is behavioral context such as required write permission on the GSC property, which the description omits.

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 0%, so the description must carry the burden, and it does: it defines site_url as the 'Exact GSC property URL' and sitemap_url as the 'Full URL of the sitemap to delete'. This meaningfully compensates for the bare schema, though no URL format examples are given.

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 a specific verb and resource ('Delete (unsubmit) a sitemap from Google Search Console') that an agent can distinguish from submit_sitemap and get_sitemaps. It never names those siblings explicitly, so differentiation rests on the verb alone.

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?

There is no statement of when to use this versus get_sitemaps (inspect) or submit_sitemap (add), nor any prerequisites or warnings about the destructive effect. The 'unsubmit' parenthetical hints at intent but provides no routing 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered externally. The description adds useful semantic context about what counts as a candidate and warns against over-interpreting overlap, but says nothing about latency, scope limits, or how results are windowed beyond the days parameter.

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 core purpose and its caveat are front-loaded in two tight sentences, followed by a scannable Args block. Nothing is redundant, though the Args section slightly duplicates parameter names already visible in the schema.

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?

An output schema exists, so return values need not be explained, and all three input parameters are documented despite 0% schema coverage. The only modest gap is the absence of guidance on how to act on flagged pairs or how this tool relates to the broader analytics siblings.

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 0%, so the description carries the full burden, and it documents all three parameters: site_url as the 'Exact GSC property URL', days as look-back with a default of 28, and min_impressions as the per-query-page-pair threshold with a default of 5. This meaningfully compensates for the empty schema, though it does not clarify format (e.g., trailing slash on the property URL).

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 a specific verb and resource: identifies queries that appear for multiple pages, framed as cannibalization candidates. The concept is distinct from any sibling (e.g., get_search_by_page_query, find_striking_distance_keywords), but the description never names or differentiates against them, which keeps it short of a 5.

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 second sentence adds interpretive guidance ('overlap alone does not prove harmful competition'), which helps an agent frame results, but it never says when to invoke this tool versus related analytics tools like get_search_by_page_query or get_search_analytics. Usage is implied by the purpose rather than explicitly scoped.

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 safety is covered. The description adds real value beyond that by disclosing the interpretation caveat that ranking position alone does not determine improvement effort — behavioral context the annotations cannot express.

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?

Front-loaded with the definition of the target keywords, followed by a useful caveat, then a compact Args block. The Args list duplicates schema names but is justified given 0% schema coverage, and every sentence carries 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?

With an output schema present, return values need not be described, and the description covers purpose, interpretation caveat, and all four parameters with defaults. It is close to complete for this tool's 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 description coverage is 0%, so the description must carry parameter meaning, and it does: it documents all four args with their roles and defaults (days=28 lookback, min_impressions=10, row_limit=50, exact GSC property URL). Minor gaps remain (units, URL format specifics), but it largely compensates for the empty 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?

States a specific verb and resource and concretely defines the domain term 'striking distance' as queries ranking at positions 5-20 with decent impressions. It doesn't explicitly differentiate from siblings like get_search_analytics or detect_cannibalization, but the scoping detail is strong enough that an agent can identify it.

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 caveat 'These are review candidates; positions alone do not establish the effort needed to improve rankings' implies the tool produces candidates for review rather than final decisions, but it gives no explicit when-to-use vs alternatives guidance or prerequisites beyond the required site_url.

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 this as a read-only, idempotent, non-destructive, open-world operation, covering the safety profile. The description adds meaningful behavioral context beyond annotations: the data_state 'final' option has a 2-3 day lag, sort_by operates locally on the returned API page, and filters combine with AND logic. It does not mention rate limits or authentication needs, but the added detail is substantial.

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 first sentence front-loads the tool's purpose, then the remaining content is a clean, structured args list. Given 14 parameters, the length is appropriate and no sentence is wasted, though it could be slightly tighter by separating usage notes from pure parameter definitions.

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 14 parameters and many sibling analytics tools, the description covers parameters completely but omits any routing guidance or prerequisites (e.g., that site_url must be a verified GSC property). The output schema exists, so return values need not be explained, but the lack of when-to-use context leaves a significant 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 description coverage is 0%, so the description must carry the full semantic burden for 14 parameters. It does so thoroughly: date formats and defaults, dimension values, search type enums, row/pagination limits, sort metrics and direction, filter operators including regex, filter JSON structure, and data_state meaning. This is exactly the compensation required for a zero-coverage 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 states a specific verb (Get) and resource (advanced search analytics), and lists concrete capabilities: sorting, filtering including regex, and pagination. It does not differentiate this tool from the sibling get_search_analytics, so an agent cannot tell when this advanced variant is preferred over the basic one.

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 no guidance on when to use this tool versus alternatives such as get_search_analytics, get_performance_overview, or compare_search_periods. It only documents parameters, leaving the agent to infer usage from the tool name.

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 annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely useful operational context beyond that: it is a free API, needs no OAuth, and requires a CRUX_API_KEY environment variable. It does not mention data-availability limits or rate behavior, which keeps it from a 5.

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?

Front-loaded with the core purpose in the first sentence, followed by a useful auth note and a compact Args block. Slightly rigid with the Args formatting, but every line carries information with no filler.

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?

An output schema exists, so return values need not be explained, and the description covers purpose, auth prerequisites, and both parameters. The one meaningful omission is that CrUX can return no data for low-traffic URLs/origins, which an agent calling this cold should know.

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 0%, so the description must carry the parameter burden, and it largely does: it explains url_or_origin accepts a full URL or an origin and gives a concrete origin example, and it enumerates the form_factor values PHONE, DESKTOP, TABLET plus the default. It omits how origin-level versus URL-level results differ in granularity, but the semantics are clear.

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 a specific verb and resource (get Core Web Vitals), names the underlying data source (Chrome UX Report / CrUX API), and lists the exact metrics returned (LCP, INP, CLS). This is enough to distinguish it from lab-based siblings like run_lighthouse_audit or get_pagespeed_insights, which do not fetch CrUX field data.

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 when-to-use guidance. It never tells the agent to prefer this for real-user field data over the lab-based Lighthouse/PageSpeed siblings, nor when this tool is inappropriate (e.g. origins without enough CrUX traffic). The reader must infer the choice from the data-source name alone.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns Lighthouse lab data plus CrUX field data, but omits rate limits/quotas (the PageSpeed API is quota-limited), API key or auth requirements, and latency expectations for an open-world call.

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?

Short and front-loaded, with the core action stated first and the return data immediately after. The Args block is compact and earns its place, though it partially restates schema fields.

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?

An output schema exists, so return-value explanation is not required, and annotations cover safety. The description covers purpose and all three parameters adequately; the only meaningful omission is guidance on when to prefer this tool over the overlapping lighthouse/CrUX siblings.

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 0%, so the description must carry the parameter burden, and it largely does: it identifies url as a full page URL, strategy as mobile or desktop, and categories as comma-separated Lighthouse categories. It does not enumerate valid category values or state defaults, leaving some detail to 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?

States a specific verb and resource ('Run Google's PageSpeed Insights API for a URL') and clarifies the data returned (Lighthouse lab data plus Chrome UX Report field data). However, it does not differentiate itself from closely related siblings such as run_lighthouse_audit, audit_live_site, or get_core_web_vitals, which overlap in 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?

The description gives no when-to-use guidance, no prerequisites, and never names an alternative tool. With siblings like run_lighthouse_audit and get_core_web_vitals offering overlapping capability, the absence of routing guidance is a real gap.

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, so the safety profile is covered. The description adds the output shape ('totals and daily trend'), which is mild behavioral context, but says nothing about auth requirements, rate limits, or data freshness beyond what annotations provide.

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 purpose is front-loaded in one sentence, and the argument list is terse and wastes no words. The 'Args:' block is slightly boilerplate but not 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?

An output schema exists, so return values need not be explained. What is missing given the crowded sibling set is any differentiation or usage context, which leaves the agent to guess among several analytics tools.

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 0%, so the description must carry the parameter burden and largely does: it clarifies site_url is the 'Exact GSC property URL' and that days is a lookback window defaulting to 28. It stops short of giving the site_url format (e.g. sc-domain: prefix) that would fully disambiguate input.

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 a specific verb and resource ('Get a performance overview') and reveals the payload shape ('totals and daily trend'). However, it does nothing to separate itself from siblings like get_search_analytics, get_advanced_search_analytics, or get_search_analytics_snapshot, which an agent could easily confuse it with.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. With four sibling analytics tools in the list, the absence of any routing signal is a real gap.

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, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine semantic context beyond that: the snapshot is 'immutable' and 'retained', telling the agent it is a frozen historical record rather than live data.

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 front-loaded sentence with no filler; the retrieval action and its key are stated immediately.

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 two-parameter read tool whose annotations cover the safety profile, this is mostly complete, but with no output schema the description gives no sense of what an audit snapshot contains or how it is keyed beyond the raw ids.

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 0% for both parameters, so the description must compensate. It clarifies that audit_id is project-scoped, which ties the two params together, but adds no format, sourcing, or meaning for project_id itself.

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?

Names a specific verb (Load), resource (audit snapshot), and lookup key (project-scoped audit_id), so the agent knows exactly what it retrieves. It does not explicitly differentiate itself from nearest siblings like list_project_audits or compare_project_audits, though the by-ID retrieval semantics imply the distinction.

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?

Usage is only implied: you must already hold a project_id and audit_id, which suggests this follows a listing call, but no when-to-use, prerequisites, or alternatives are stated. An agent can infer the context but gets no routing 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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds useful operational detail (default lookback of 28 days, row_limit max of 500, valid search_type values), but says nothing about rate limits, quota consumption, or result ordering/pagination.

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 purpose sentence is front-loaded and the Args block is a tight, scannable list with no filler. The Python-docstring formatting is slightly informal but costs nothing in 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?

An output schema exists, so return values need not be described, and the parameter coverage is thorough. What is missing is differentiation from the many sibling analytics tools and any indication of quotas or result limits beyond row_limit.

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 0%, so the description carries the full burden and does so well: it gives an example site_url format ('sc-domain:example.com'), defaults for days and row_limit, a hard cap of 500 rows, the allowed dimension tokens, and the full enum of search_type values that the schema does not encode as an enum.

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 a specific verb ('Get') and resource ('search analytics data') scoped to 'a specific property', so the agent knows the operation. However, it does nothing to distinguish itself from close siblings like get_advanced_search_analytics, get_search_analytics_snapshot, or get_performance_overview, leaving the agent to guess which analytics tool to pick.

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 no when-to-use guidance, no prerequisites, and no named alternatives despite several overlapping siblings in the same family. The only implicit context is that it requires a GSC property, which is inferable from the required site_url parameter.

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 establish read-only, idempotent, non-destructive behavior, and the description adds substantial operational context beyond them: the 100k-row / 10-page / 180-second bounds, Google's omission of anonymized long-tail rows, partial-result survival on provider errors, and freshness metadata. This is exactly the kind of behavior an agent cannot learn from structured fields.

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?

Four dense sentences with no filler, and the core capability plus limits are front-loaded. Slightly terse and fragmentary ('Partial results survive provider errors.') but every sentence carries 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?

An output schema exists, so return values need not be described, and the description covers the important operational caveats (bounds, partial results, freshness metadata). The notable gap is parameter meaning, which is left entirely undocumented.

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 0% across 6 parameters, so the schema itself explains nothing. The description only loosely touches max_rows (via 'at most 100,000 rows / 10 API pages') and says nothing about days, max_requests, dimensions, search_type, or site_url semantics. It fails to compensate for the coverage gap.

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 a specific verb and resource ('Fetch a ... Search Console snapshot') with scope qualifiers (bounded, paginated, explicit coverage). However, it never distinguishes itself from close siblings like get_search_analytics, get_advanced_search_analytics, or get_performance_overview, so an agent cannot tell from the text alone which one to pick.

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 the tool's limits but gives no when-to-use guidance, no prerequisites, and no routing against the numerous sibling analytics tools. An agent must infer the selection criteria from the name alone.

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, and destructiveHint=false, so the safety profile is covered. The description adds the useful constraint that row_limit maxes at 500 and the default look-back is 28 days, but says nothing about pagination, rate limits, or reporting-lag behavior that would help interpret results.

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 one-line purpose is front-loaded and every parameter line earns its place given the empty schema. The Args block mildly duplicates the property names but is justified by the 0% coverage.

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 an output schema present, return values need not be explained, and annotations cover safety, so the description only needs to carry purpose and parameters, which it does. The remaining gap is routing guidance against the numerous analytics siblings.

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 0%, so the description carries the full burden, and it largely delivers: it explains site_url, page_url, days (default 28), and row_limit (default 20, max 500). The 'max: 500' bound is not present in the schema and is genuinely additive, though format detail for the URL fields remains thin.

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 a specific verb (get) and resource (search queries) scoped to a single page, which is more precise than a generic analytics call. However, it does not explicitly distinguish itself from close siblings like get_search_analytics or get_advanced_search_analytics that might also return query data, leaving the differentiation implicit.

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?

There is no indication of when to use this tool versus the many search-analytics siblings, nor any prerequisites or exclusions. The scope ('a specific page') is implied usage but the agent receives no routing 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 readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds substantive behavior beyond that: no Google credentials required, JS execution in a guarded browser, sitemap discovery of unlinked candidates, crawl time and page-cap limits, query-string preservation, and robots.txt is respected by default.

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?

It is front-loaded with the core deliverable in the first sentence and each subsequent sentence adds a distinct operational fact. It is information-dense but not bloated, though a slightly tighter organization around parameters would improve scanability.

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 six parameters, no schema descriptions and the presence of an output schema, the description covers the behavioral and parameter essentials an agent needs: credentials, crawl bounds, robots policy, JS modes, sitemap behavior and comparison workflow. Return value details are appropriately left to the output schema.

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 0%, so the description must carry parameter meaning. It explains that max_seconds bounds the crawl, max_pages is capped by server configuration, respect_robots defaults on with a warning to disable only for controlled sites, and rendered/compare modes execute JS. render_mode values and several defaults are still not spelled out.

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 a specific verb (return), the resource (structured technical SEO action plan with rule IDs, URLs, evidence, fix guidance, crawl coverage and limits), and distinguishes itself from siblings by naming compare_seo_audits. It is unmistakably the full-site SEO audit tool.

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 gives clear workflow guidance: save the returned JSON for later comparison with compare_seo_audits, and notes that rendered/compare modes execute JS while include_sitemaps discovers nested sitemaps. It lacks explicit when-not-to-use advice versus similar siblings like crawl_site_seo or audit_live_site.

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, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine beyond-schema context: no credential values are exposed, no network calls are made, no jobs are started, and credential presence is not proof of live Google permissions or quota. That last caveat is exactly the kind of interpretive guidance annotations cannot carry.

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 dense sentences with no filler, and the exclusion list (no credential values, no network calls, no jobs) is effectively front-loaded. It could be slightly stronger if the primary purpose preceded the caveats rather than 'Inspect local setup' being the vague opener.

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 an output schema present, the description need not enumerate return values, and annotations carry the safety profile. Given the tool's simplicity (zero params, closed world), the description supplies sufficient behavioral framing, though a stronger statement of what 'setup' comprises would close the remaining 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?

The tool takes zero parameters, so by the rubric baseline is 4. There is nothing for the description to disambiguate at the parameter level.

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 says it 'inspect[s] local setup', which conveys a diagnostic read against the local environment, but it never states what status information is actually returned (credentials present, config paths, version, etc.). It also does not distinguish itself from siblings like reauthenticate or list_properties, so an agent must infer its role.

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?

There is no explicit when-to-use or when-not-to-use guidance. The line 'Credential presence does not prove current Google permissions or quota' hints at a diagnostic use case, but the agent is left to infer that this tool is for pre-flight troubleshooting rather than, say, authentication.

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, covering the safety profile. The description adds nothing beyond that — "detailed info" is vague and no return, pagination, or property-requirement context is provided, so it fails to add value over the structured fields.

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?

Very short and front-loaded, with the purpose stated first and the argument documented after. Nothing is wasted, though the "Args:" block is a thin restatement of the single schema field.

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?

An output schema exists, so return values needn't be explained. However, "detailed info" is left undefined and there is no guidance on when this differs from the sitemap-analysis sibling, leaving the definition only minimally adequate for a one-parameter read 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 description coverage is 0%, so the description must compensate. It does clarify that site_url is the "Exact GSC property URL," which is genuinely useful for callers, but this is the only parameter detail offered and no format example or matching rules are given.

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 a clear verb and resource ("List all sitemaps for a property") plus a scope qualifier ("with detailed info"). It distinguishes from submit_sitemap and delete_sitemap by being a read/list operation, but does not differentiate itself from the sibling analyze_sitemap, leaving one ambiguity unresolved.

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 gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as analyze_sitemap or list_properties. An agent must infer usage from the name alone.

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 openWorldHint, so the safety/behavior profile is well covered structurally. The description adds nothing beyond what annotations convey — no notes on network reachability, redirect handling, or missing-file behavior — so it earns only the annotation-covered baseline.

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 short lines, purpose front-loaded ahead of the argument note. No waste.

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 single-parameter read tool with an output schema present, the description is nearly sufficient — return handling is delegated to the output schema. Only the weak when-to-use signal removes the last point.

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 0%, so the description must carry meaning, and the Args line does add accepted input formats (full URL, origin, sc-domain property). However it does not specify which form is preferred, how sc-domain differs, or accepted schemes, leaving the single required parameter only partially clarified.

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 a specific verb+resource: 'Fetch and summarize the site's robots.txt file.' An agent immediately knows what it does. No sibling tool overlaps (e.g., audit_live_site or analyze_sitemap), but the description doesn't explicitly differentiate from them, keeping it at 4.

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 rather than the many site-analysis siblings like audit_live_site or site_audit, nor any prerequisites. Usage is only implied by the resource name.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the site_url format requirement ('sc-domain:example.com'), which is genuinely useful context, but it omits quotas/rate limits and the constraint that the page must belong to the property.

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 main purpose sentence is front-loaded and the argument documentation is terse. Nothing is wasted, though the Args block is a slightly mechanical restatement of the schema.

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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. However, for an open-world tool with known API quota constraints, the absence of any quota/permission or property-membership note leaves a meaningful 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 description coverage is 0%, so the description must carry the load. It supplies a concrete format example for site_url and identifies page_url as the target URL, which partially compensates, but page_url is essentially restated and no other constraints (must be in property, HTTPS, etc.) are given.

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 a specific verb (inspect) and resource (URL) and enumerates the three things it checks: indexing status, rich results, and mobile usability. It does not explicitly distinguish itself from the sibling batch_inspect_urls, but the singular scope is inferable from the name.

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?

There is no when-to-use guidance, no mention of when this is preferable to batch_inspect_urls, analyze_page_seo, or audit_live_site, and no prerequisites stated. Usage is only implied by the verb.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for the extras it adds: reads are non-marking, only the latest 500 events per project are retained, only verified new/resolved findings produce change events, and no external notification is sent. These are meaningful behavioral traits beyond the structured annotations, though the return shape is still unexplained.

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?

Four short sentences, front-loaded with the core action and no filler; the retention and event-trigger details each add information. Slightly sprawling, but nothing is redundant.

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 3-parameter, no-output-schema tool, the description covers pagination, retention limits, and event-generation conditions, which is a fair amount. It still leaves the return format and the meaning of limit/project_id unstated, and the after_id naming mismatch leaves a real gap in how to call 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 0% and the description only addresses one of the three parameters, calling it 'next_after_id' while the schema declares 'after_id' — a naming mismatch that can mislead an agent about what to pass back. limit and project_id get no explanation at all, so the description fails to compensate for the zero coverage.

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 names a specific verb (read) and resource (local change/failure/recovery inbox), so an agent knows it returns audit events. It does not, however, distinguish itself from sibling audit tools such as list_project_audits, get_project_audit, or list_audit_projects, which an agent must still disambiguate on its own.

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 gives concrete continuation guidance ('Pass next_after_id on the next call') and states that events are only emitted for verified new/resolved findings, which implicitly explains when the inbox is non-empty. It never says when to prefer this tool over the sibling audit-list tools, and it uses a parameter name that does not match the schema.

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, and non-destructive, so the safety profile is covered. The description adds value by disclosing what the listing surfaces (settings, schedule state, latest run status), but says nothing about ordering, pagination, or auth requirements.

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 front-loaded sentence with no filler. The resource comes first and the returned facets follow, so nothing could be trimmed without losing 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?

There is no output schema and no parameters, so the description must carry the return payload, and it does enumerate the key fields. It would be fully complete if it clarified scope versus the other list_* siblings.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level meaning is needed or missing.

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 a specific verb (List) and resource (local projects) and enumerates what is surfaced: settings, schedule state, latest run status. It is clearly distinct from mutation siblings like create_audit_project or run_project_audit, though it never contrasts itself with the similarly named list_project_audits or list_properties.

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 when-to-use guidance and no alternatives named, despite several adjacent listing tools (list_project_audits, list_audit_events, list_properties) that an agent must choose between. The word 'local' hints at scope but is never explained as a selection criterion.

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 the operation is read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral context: result cap, newest-first ordering, and summary content. However, it omits pagination behavior, what 'retained' means, and how the stated 'up to 100' relates to the limit parameter (default 30).

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 front-loaded sentence with no filler. It efficiently conveys scope, ordering, and output content, though it could have used a second clause for parameter guidance without becoming bloated.

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 list tool with rich annotations, the description adequately covers return characteristics. But with 0% schema description coverage and no output schema, the agent gets no explanation of the required project_id or the limit parameter, leaving a meaningful 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 description coverage is 0% for both parameters, so the description must carry parameter semantics. It never mentions project_id (required) or limit. The phrase 'up to 100' vaguely hints at a maximum but does not document the limit parameter or explain what project_id identifies.

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 a specific verb (List) and resource (retained snapshots / project audits), plus scope (up to 100), ordering (newest first), and returned content (coverage and issue summaries). It clearly distinguishes this from a detail-fetching tool like get_project_audit, though it does not explicitly name alternatives.

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 says what the tool returns but offers no guidance on when to use it versus alternatives such as get_project_audit, list_audit_projects, or compare_project_audits. No prerequisites or exclusions are mentioned.

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, so the safety profile is fully covered by structured fields. The description adds only the scope detail ('user's' properties) and says nothing about auth requirements, rate limits, or pagination that would go 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?

A single sentence with no filler, and the resource being returned is front-loaded. Nothing is wasted.

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?

An output schema exists, so return values need no explanation, and with zero parameters the call surface is trivial. The description is essentially sufficient, with only optional discovery/ordering context 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?

The tool takes zero parameters, so per the baseline this dimension scores 4. There are no parameter semantics for the description to clarify or omit.

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 a specific verb and resource ('Retrieves and returns the user's Search Console properties'), so an agent knows exactly what it produces. It is clear but does not differentiate itself from adjacent site-management siblings like add_site or delete_site.

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 when-to-use guidance, no prerequisites, and no named alternatives. For a discovery tool that likely precedes get_search_analytics or audit operations, a hint about that ordering would be valuable and is absent.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: the sort ordering, the fact that unmatched URLs are treated as unknown rather than zero, and the no-double-counting rule — all of which affect how an agent should interpret output.

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?

Four short sentences, front-loaded with the core action before the caveats. Each sentence carries information, though the final caveat sentence is dense and reads as a list of edge-case rules.

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?

An output schema exists, so return-value explanation is unnecessary, and the description covers interpretive caveats well. However, with 0% parameter documentation and no usage context, an agent still lacks enough to invoke this confidently.

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 0% across three parameters (report_json, site_url, days), and the description never mentions them — it neither explains the expected JSON shape nor the meaning or default of days. Only a loose contextual hint about Search Console data and an audit plan is inferable.

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 gives a specific verb and resource: adding observed Search Console traffic to an audit action plan, plus how results are ordered (severity, then clicks/impressions). This clearly separates it from generic audit siblings like site_audit or get_project_audit, though it never names an alternative explicitly.

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?

There is no statement of when to call this versus running an audit or fetching search analytics, and no prerequisites or sequence guidance. The exclusions ('does not estimate revenue or ranking gains') bound the tool's scope but do not tell an agent when to select 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 declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds important behavioral context beyond annotations: the token replacement is atomic, and existing credentials and caches are preserved if login or saving fails. This is valuable operational detail for a destructive operation.

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 short sentences, front-loaded with the core action and followed by the failure-safety guarantee. Every sentence earns its place with 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?

With an output schema available and annotations covering safety, the description supplies the critical missing context about atomicity and failure preservation. It does not mention any prerequisites or interactive requirements, but for a zero-parameter tool this is largely 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 tool has zero parameters, so the baseline is 4 per the rules. The description does not need to add parameter meaning, and it appropriately focuses on behavior rather than inputs.

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 and resource: authenticate an account and atomically replace the saved OAuth token. No sibling tool performs authentication, so no further differentiation is needed. It is immediately clear what the tool does.

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 the scenario (authenticate a new account and replace the token) but does not state when to call this tool versus alternatives or prerequisites. Since no sibling tool handles authentication, the purpose is inferable, but explicit usage guidance is absent.

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 non-read-only, non-idempotent, open-world behavior, and the description adds genuinely useful operational context: the structured-data eligibility restriction and the 200 requests/day quota. Missing auth model (service-account ownership) is a minor gap given annotations cover the mutation profile.

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?

Purpose and critical constraints are front-loaded and the warning is emphasized appropriately. The trailing 'Args:' block largely restates the parameter and is mildly redundant, but overall it is tight.

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 one-parameter mutation tool with an output schema, the description covers the essential nuances: eligibility restriction, quota, and the nature of the operation. Return values need not be explained because an output schema exists.

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 0% for the single parameter, so the description must compensate. It clarifies that the value is the full URL to request indexing for, which adds the important detail that a complete URL (not a path) is required, though format specifics are still left to inference.

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 a specific verb+resource (request crawl/index of a URL) and names the API. It is clearly distinguishable from siblings like batch_request_indexing and request_removal.

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 major eligibility constraint (only JobPosting or BroadcastEvent structured data) and the default quota, which tells the agent when the call will fail. It does not, however, explicitly route to batch_request_indexing when multiple URLs are involved.

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 cover the safety profile (destructive, non-idempotent, open-world), so the bar is lower. The description adds real behavioral value beyond them by disclosing the structured-data eligibility restriction, which determines whether the call will succeed at all. It omits auth/quota context, keeping it from a 5.

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?

Front-loaded with the action, immediately followed by the critical eligibility warning. The Args block mildly duplicates what the single-sentence body already implies, but overall there is little waste.

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 an output schema present, return values need not be described. For a single-parameter mutation whose annotations already declare destructiveness, the description supplies the one missing piece that matters: the structured-data precondition.

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 0% for the single url parameter, so the description must carry the load. It states 'The full URL to request removal for,' which usefully clarifies that an absolute URL is expected rather than a path, but adds little else.

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 a specific verb and resource: requesting Google remove a URL from the index via the Indexing API. It does not explicitly differentiate itself from the related sibling request_indexing (which adds pages rather than removes them), so an agent must infer the inverse relationship.

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 a genuine when-not constraint: only works for pages with JobPosting or BroadcastEvent structured data. This is exactly the kind of eligibility gate an agent needs. It stops short of naming an alternative tool for other page types, so it is not a full 5.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real context beyond them: a required env flag, local runtime dependencies, and the notable disclosure that Lighthouse browser networking is not guarded by the public crawl transport. It does not mention cost/duration or failure behavior of a local browser run.

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 key constraint (local, trusted URL) is front-loaded, and the args block is compact. The three lines of prerequisites are individually short and each carries distinct meaning.

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?

Output schema exists so return values need no explanation, and all three params plus runtime prerequisites are covered. Remaining gap is guidance on how this audit relates to the many other audit/report siblings and what 'trusted URL' implies in practice.

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 0% schema description coverage, the description carries the whole burden and does document all three parameters: full page URL, mobile/desktop form factor, and comma-separated categories. It even supplies the mobile/desktop values the schema lacks as an enum. Format detail is good but not exhaustive (e.g. allowed category tokens).

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 a specific verb and resource (run a Lighthouse CLI audit) with a scoping qualifier ('local', 'explicitly trusted URL') that implicitly separates it from remote siblings like get_pagespeed_insights and audit_live_site. It never names an alternative outright, so the differentiation is inferred rather than 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?

Gives clear preconditions (SEO_AUDIT_ENABLE_LOCAL_LIGHTHOUSE=true, Node.js, Chrome/Chromium) and a trust constraint on the URL, which tells the agent when it *can* run. It stops short of naming when to prefer this over the other audit tools in the sibling list.

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?

Adds rich context beyond the annotations: it discloses that immutable reports are persisted, that old snapshots are pruned to project retention (explaining the destructiveHint), the ten-minute timeout, the single-run-per-project limit, and that alerts remain local with no email/messaging/webhook. This is exactly the behavioral detail the annotations cannot convey.

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?

Front-loaded with the action verb and its outputs, followed by constraints and a clear hand-off pointer. Every sentence carries information; it is dense but not padded.

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 the destructive/non-idempotent profile, persistence, retention pruning, timeout, and return pointer well enough for a non-idempotent mutation tool with no output schema. It stops short of saying what happens on a second run for the same project (error vs queued), a notable gap given non-idempotency.

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 0%, but there is a single required parameter (project_id) whose meaning is self-evident and reinforced by 'One run per project'. The description adds no extra syntax beyond the schema, but little is needed for a single obvious identifier.

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?

Specific verb+resource ('Fetch a project now, save its immutable report, record verified finding changes') that tells the agent exactly what the tool produces. It partially routes away from get_project_audit, though it does not distinguish itself from near-name siblings like site_audit or audit_live_site.

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 operating constraint ('One run per project; ten-minute timeout') and names the follow-up alternative with its condition ('use get_project_audit for the full snapshot'). Lacks explicit when-not-to-use guidance relative to the other audit siblings, but the routing to get_project_audit 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?

Beyond the annotations (which only cover read-only/idempotent/open-world/destructive flags), the description discloses first-run timing, the external worker dependency, failure backoff, and that disabling leaves an active run to finish. This is exactly the operational context an agent cannot get from structured fields.

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?

Front-loaded with the core action, then layers prerequisites and edge-case semantics. Dense but every clause carries information; the opening 'Explicitly' is the only slight filler.

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 and only coarse annotations, the description still covers behavior, prerequisites, timing, and failure handling well. It falls short only on documenting the required project_id and return/feedback behavior for a mutation 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 0%, so the description must carry parameter meaning. It supplies the interval range (60 seconds to 31 days) for interval_seconds, which is genuinely useful, but says nothing about the required project_id or the default false for enabled. Only partial compensation for the coverage gap.

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 a specific verb pair (enable/disable) and resource (a project's recurring audit), and the word 'recurring' plus the interval range clearly distinguishes it from one-off siblings like run_project_audit and audit_live_site.

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 gives a real prerequisite (a separate mcp-seo-monitor worker must be running, stdio server launches no background work), which implies when this is usable. However, it never names or contrasts an alternative tool, so the agent must infer that this is the scheduling counterpart to run_project_audit.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description earns credit by disclosing non-obvious traits: each inspected URL costs 1 API call, sitemap_url is included in the report but not crawled, and the sample is not coverage-complete. It does not mention rate limits or runtime, but this is solid added 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?

Purpose and its key limitation are front-loaded before the Args block, and every sentence adds information. The docstring-style Args block is slightly verbose but each entry is necessary given the schema provides no descriptions.

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?

An output schema exists, so return values need not be explained. For a read-only audit tool with cost-per-URL implications, the description covers scope limits, parameter formats, and cost drivers adequately; only cross-tool routing guidance is absent.

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 0%, so the description carries the full burden and mostly does: it gives the exact site_url format ("sc-domain:example.com"), clarifies sitemap_url is report-only and not crawled, and gives max_inspect's range, default, and per-call cost. Minor gaps like behavior at max_inspect=0 remain, but this is strong compensation.

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 specific verbs and resources: sitemap submission health, performance, and indexing issues on a sampled set of top pages. It also bounds its own scope (sample, not full coverage). It doesn't explicitly distinguish itself from siblings like analyze_sitemap or get_sitemaps, which is the only clarity gap.

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?

Usage is implied through the sampling caveat ('cannot establish indexing coverage across the entire property'), which tells the agent when the result is insufficient. However, it never says when to pick this over analyze_sitemap, get_sitemaps, or crawl_site_seo, nor does it name prerequisites beyond the property URL.

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, and non-destructive behavior, so safety is covered. The description adds a genuine behavioral nuance — that it operates only on query-visible traffic — plus a caveat about single-period results, but says nothing about rate limits or output characteristics.

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?

Purpose is front-loaded, followed by a short scope caveat and a compact Args block. The Args list repeats the schema's parameter names but is justified by the 0% schema description coverage; overall there is little wasted text.

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?

An output schema exists, so return values need no explanation. The description covers purpose, the branded/non-branded scope, all three parameters, and a usage caveat, leaving only minor gaps such as how brand matching is performed.

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 0%, so the description must carry params, and it does: it clarifies site_url is the "exact GSC property URL," gives a concrete brand_name example, and restates the days default. This meaningfully compensates for the empty schema titles.

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 first sentence states a specific verb and resource — splitting search performance by branded vs non-branded queries — which is distinct from siblings like compare_search_periods or get_search_analytics. It does not explicitly contrast itself with those siblings, but the operation is 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?

"One period alone does not establish growth" implies the intended usage context (trend comparison over time) but never names an alternative tool or an explicit when/when-not condition. Guidance is present but implied rather than directive.

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, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that resubmission is supported and that the property URL must be exact, which is genuinely useful. It does not disclose auth requirements, error behavior, or what the response confirms.

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 lines total: one action sentence followed by an Args list. Front-loaded and waste-free, though the Args block is a restatement of the schema parameter names rather than a tightening of them.

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?

Output schema exists, so return values need not be described, and annotations cover the safety profile. What is missing is the exactness requirement for the site_url format beyond the word 'Exact', plus any hint about what happens when the property doesn't match or the sitemap is invalid.

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 0%, so the description carries the burden of explaining both parameters. The Args block does so meaningfully ('Exact GSC property URL' and 'Full URL of the sitemap'), though the annotations on format are terse and no examples are given for either URL shape.

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 a specific verb and resource: 'Submit or resubmit a sitemap to Google.' That distinguishes it from get_sitemaps, delete_sitemap, and analyze_sitemap by action, though it does not explicitly name those siblings as alternatives.

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 when-to-use guidance, no prerequisites, and no mention of related siblings (e.g., analyze_sitemap to validate before submitting, or delete_sitemap). The 'resubmit' wording implies an update case but never states it as a condition.

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