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

Even with annotations available (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds substantial behavioral context: the property starts UNVERIFIED with a specific permission level, data calls will 403 until verification, success returns an empty API response, and the required OAuth scope is stated. This goes well beyond annotation signals.

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

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

The description is a single, tightly packed paragraph that front-loads the action and then efficiently delivers critical caveats (verification, response shape, scope requirement). Every sentence earns its place without redundancy or fluff.

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

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

With no output schema, the description fully explains the expected success response and the unverified-state behavior. It covers the mutation, prerequisites, failure modes, and permissions, making it complete for a one-parameter tool with good annotations.

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

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

Schema coverage for the single parameter (site_url) is 100%, including format examples and error notes. The tool description itself does not repeat or add parameter-level detail, so it does not elevate above the schema's already-complete documentation. A baseline of 3 is appropriate.

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

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

The description opens with 'Adds a property to the account's Search Console set,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like list_sites, get_site, and delete_site. It also immediately conveys the key scope of the operation.

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

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

The description provides robust usage guidance: it states that adding a property is not sufficient for data access, explicitly notes that verification happens through the UI or a separate API, warns that most data calls will return 403 until verified, and clarifies that the readonly OAuth scope cannot mutate. These are clear when-to-use and when-not-to-use directives.

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

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

The description goes well beyond the annotations by clarifying that no data is deleted, other owners keep access, the action is reversible (can be re-added later), and the success response format. It also specifies the required OAuth scope. This provides substantial behavioral context that annotations alone don't 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?

The description is concise and well-structured: three sentences, each adding value. It leads with the core purpose, then clarifies non-destructive behavior and success/scope details. No wasted words.

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

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

Given the tool's simplicity (one parameter, full schema coverage, no output schema), the description is complete. It explains behavior, side effects, reversibility, auth requirements, and response shape, leaving no significant gaps for an agent to guess.

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 schema already has 100% coverage with a detailed description of site_url, including format examples and error conditions. The tool description doesn't add anything parameter-specific beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the specific action: 'Removes (unlinks) a property from the account's Search Console set.' It uses a specific verb and resource, and the parenthetical '(unlinks)' distinguishes this from data deletion, differentiating it from sibling tools like add_site or delete_sitemap.

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

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

The description provides clear context: it explains this only removes the property from THIS account's list, that no data is deleted, and that it can be re-added later. It also notes the required OAuth scope. It doesn't explicitly name alternatives, but it does indicate when not to use it (not for data deletion), which is sufficient.

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 significant behavioral context beyond the annotations: the file is not deleted, discovery may still happen, success returns an empty response, and full OAuth scope is required. It could mention idempotency given the idempotentHint, but the disclosure is already strong.

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

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

The description is two sentences, front-loaded with the main action and then the important caveats. Every sentence provides necessary information without redundancy.

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

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

For a simple destructive tool with two well-documented parameters, it covers the key aspects: purpose, side effects, authentication, and response format. It does not describe error scenarios or edge cases, but these are less critical given the idempotentHint and lack of 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?

The input schema fully describes both parameters, including detailed formats and error conditions for site_url. The description itself adds no parameter information, so baseline 3 applies.

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 opens with 'Removes a sitemap from Search Console', using a specific verb and resource that clearly identifies the action. It also distinguishes itself from deleting the actual file, differentiating it from similar sitemap tools like submit_sitemap or list_sitemaps.

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

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

Provides clear context that this only removes the submission, not the file, and warns that Google may still discover it via robots.txt. It does not explicitly name alternative tools or state when not to use it, but the usage scope is evident from the description.

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, covering the safety profile. The description adds valuable behavioral context: it returns a specific format, and a 404 indicates the input doesn't match any registered property, with guidance on checking the format. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the purpose and return format, and uses no wasteful words. Every sentence earns its place: one states the result and the other explains the 404 error and recovery action.

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

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

For a simple single-parameter lookup with no output schema, the description sufficiently covers the return shape and error condition. It also points to list_sites for verifying exact formats, which completes the context. No critical information 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?

The input schema has 100% coverage with a highly detailed description of site_url, including exact format expectations and example values. The tool description itself does not add much parameter semantics beyond what the schema provides, but the schema is thorough, so a baseline 3 is appropriate.

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

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

The description clearly states the tool returns one property's entry with a specific structure ({ siteUrl, permissionLevel }), using the verb 'Returns' and identifying the resource as 'property's entry'. It distinguishes itself from siblings like list_sites by focusing on a single property rather than listing all, and from add_site/delete_site by being a getter.

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 context for when to use this tool: when you need a specific property's details and need to verify the exact format. It implicitly advises using list_sites to check registered values when a 404 occurs. However, it does not explicitly state 'use this instead of list_sites when you need a single property' or mention any 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 readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds value by enumerating the return fields (errors/warnings, isPending, timestamps) and indicating the sitemap must be submitted, which provides useful context beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary action and return information, and every clause contributes. The structure is efficient and free of repetition, making it easy for an agent to parse quickly.

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 getter with strong annotations and fully documented parameters, the description provides sufficient context. It names the return shape and fields, specifies the use case, and requirements like 'submitted sitemap,' making it complete for invocation decisions.

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

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

Schema coverage is 100%, and the schema descriptions for site_url and feedpath are detailed with examples and constraints. The description does not add additional parameter semantics; it only restates 'submitted sitemap' without altering the schema's already thorough documentation.

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

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

The description clearly states it returns one submitted sitemap's details, explicitly listing the fields returned and the WmxSitemap shape. It distinguishes from list_sitemaps by focusing on a single sitemap and also from submit_sitemap by its read-only retrieval purpose.

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

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

The description explicitly says 'Useful to check processing status after submit_sitemap,' giving a clear when-to-use scenario. It references list_sitemaps for shape comparison, implying the alternative for listing all sitemaps, but does not explicitly state exclusions or other alternatives.

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

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

Adds substantial behavioral context beyond the read-only/idempotent annotations: data lag of 2-3 days, Pacific Time calendar dates, ctr reported as a fraction, anonymized long-tail queries not returned, and same quota as search_analytics. No contradiction with annotations; the description enriches the operational expectations.

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?

Every sentence earns its place: purpose, output row format, timezone and lag, anonymization caveat, and alternative usage are packed into a tight paragraph. Well front-loaded and 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?

Despite no output schema, the description covers the return row structure (keys[0] as query string, metrics), date handling, data lag, quota behavior, and exclusions. For a tool with 7 parameters and no output schema, this is unusually complete.

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

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

Schema coverage is 100% with descriptions on all parameters, so the description need not repeat them. It does not add meaning beyond the schema for parameters; the row structure note refers to output, not parameter semantics. Baseline 3 is appropriate.

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

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

The description clearly states it is a convenience wrapper for retrieving top search queries, sorted by clicks descending. It explicitly differentiates itself from the sibling search_analytics tool by naming it and scoping the purpose to 'the most common ask.'

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

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

Provides explicit when-to-use and when-not-to-use guidance: 'use search_analytics directly for other dimensions, pagination, fresh data or regex filters.' This directly addresses alternatives and exclusion criteria.

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 (readOnly=true, idempotent=true, destructiveHint=false), the description adds significant behavioral details: quota limits (2,000/day and 600/min), the retired mobileUsabilityResult field, the distinction between indexed and live status, and the potential for 429/403 errors. This rich context goes far beyond what annotations provide and helps the agent anticipate real-world 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?

The description is long but every sentence earns its place. It begins with a clear purpose, then details the return structure (essential since there is no output schema), and ends with practical usage warnings. The information is well-organized and front-loaded, making it easy for an agent to quickly grasp the tool's function and constraints.

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

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

Given the complexity of the return object and the absence of an output schema, the description is remarkably complete. It enumerates all major response fields, explains the non-live nature, flags deprecated fields, and provides quota guidance. This fully equips an agent to invoke the tool correctly and interpret results.

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

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

The input schema already provides complete descriptions for all three parameters, including formats and examples (e.g., site_url format, language_code default). The description does not add any parameter-specific semantics beyond what the schema covers, so a baseline score of 3 is appropriate given 100% schema 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 clearly states the tool inspects a URL's status in the Google index via the URL Inspection API. It specifies the resource ('URL'), the action ('inspects'), and the scope ('status in the Google index'), distinguishing it from sibling tools that manage sites or sitemaps.

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

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

The description provides clear context on when to use the tool, including a caveat that it returns only the currently indexed version and is NOT a live test. It also includes a quota warning, guiding agents to throttle batch inspections. However, it does not explicitly mention alternative tools or when NOT to use it beyond the live-test exclusion.

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 (readOnlyHint, idempotentHint, etc.), the description discloses detailed behavioral traits: the exact return shape, the meaning of per-sitemap fields, and a critical deprecation warning about contents[].indexed. This adds significant transparency and does not contradict annotations.

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

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

The description is a single dense sentence that conveys the core purpose, conditional behavior, return shape, field details, and a deprecation advisory. It is efficient but not as cleanly structured as a two-sentence example, hence a slight deduction.

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

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

Given the lack of an output schema, the description fully explains the return values and important nuances. It also covers error behavior indirectly through the schema (site_url mismatch) and the deprecated field warning, making it complete for the 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 100% and the schema already provides thorough parameter descriptions for site_url and sitemap_index. The description does not add new parameter semantics beyond what the schema captures, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's verb ('Lists') and resource ('sitemaps submitted for a property'), and further specifies the conditional behavior with sitemap_index. It distinguishes from sibling tools like submit_sitemap and delete_sitemap by focusing on reading/listing rather than mutation.

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 implicitly clarifies when to use the tool (to list submitted sitemaps) and adds a specific use case for sitemap_index (listing children). However, it does not explicitly mention alternatives or exclusions, so it lacks full when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, but the description adds rich context: the return structure (siteEntry with siteUrl and permissionLevel), the two property types, and the critical exact-match requirement causing 403/404. This goes beyond what annotations provide and prepares the agent for real-world usage.

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

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

The description is concise (3 sentences) and well-structured: the main action first, then the return format, then the critical usage warning. Every sentence adds important information without redundancy.

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

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

Given there is no output schema and no parameters, the description fully specifies the return structure, the possible permissionLevel values, and the important exact-match caveat. It even warns of 403/404 errors. For a zero-parameter list tool, this is complete and actionable.

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 the schema is fully covered. The description instead explains the meaning of return values (siteUrl, permissionLevel) and their possible enumerated values, which is useful for downstream tools that need siteUrl. No parameter explanation is required, but the return semantics compensate well. Baseline for 0 params is 4.

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

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

The description clearly states the tool 'Lists every Search Console property the authenticated account can access.' This uses a specific verb+resource and directly distinguishes it from siblings like get_site by emphasizing 'every' property. The title and description align, and the return format is specified.

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

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

Explicit guidance is provided: 'Call this FIRST: every other tool needs the siteUrl exactly as returned here.' This tells the agent when to use this tool before others and warns about the consequences of near-matches. No alternative is mentioned, but the instruction is unambiguous and valuable.

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 openWorldHint=true, setting the safety baseline. The description adds useful non-obvious behaviors: the Bearer token is added automatically, the method defaults to GET, and specific endpoints (sites.add, sitemaps.submit) are PUT with no body and return an empty response on success. This enriches the agent's understanding beyond annotations.

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

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

The description is compact—roughly three sentences—and front-loaded with the core 'escape hatch' purpose. Every sentence adds value: path format, URL encoding, query strings, auth, default method, and PUT endpoint notes. No wasted words.

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

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

Given this is an open-ended raw API tool, the description covers the essentials: usage scope, path encoding, auth, method defaults, and specific endpoint quirks. There is no output schema, but the tool's raw passthrough nature makes return format self-evident. The description is sufficient for an agent to use 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?

The schema already has 100% coverage, but the description goes further by explaining that siteUrl and feedpath are path segments requiring encodeURIComponent, that paths may include query strings, and clarifies body usage (POST only, PUT endpoints take no body). This added semantics is critical for correctly constructing the path parameter.

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

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

The description opens with 'Escape hatch to call any Google Search Console API path directly', which states a specific verb ('call') and resource ('any Google Search Console API path'), clearly distinguishing it from the typed sibling tools. The title 'Raw Search Console API call' reinforces this purpose.

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

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

It explicitly says 'for requests the typed tools don't cover', which tells the agent when to use this tool versus the typed alternatives. It also explains that there are two API surfaces ('webmasters/v3/...' and 'v1/...') and provides an example path, giving clear contextual guidance.

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

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds valuable behavioral context beyond annotations: 2-3 day data lag, inclusive Pacific Time dates, pagination behavior (no page token, loop until empty), long-tail data anonymization, and the 1,200 qpm quota. No contradiction with annotations.

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

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

The description is dense but every sentence carries useful information. It opens with the core purpose, then progressively details output, date semantics, pagination, data caveats, and quota. No filler or repetition; the structure front-loads the most important information and then covers edge cases.

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?

This is a 10-parameter tool with no output schema, so the description must explain both request nuances and return shape. It covers row structure, sorting, pagination, dimension effects, data lag, and quota. Combined with the 100% schema coverage, the agent has everything needed to invoke and interpret results 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?

Even though schema descriptions cover 100% of parameters, the description adds semantic depth: explains keys[] ordering, ctr fraction, inclusive end_date, pagination with start_row/row_limit, why data_state 'all' matters, and the grouping caveat that summed rows won't match totals. These clarifications go well beyond schema property descriptions.

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

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

The description clearly states the tool's function: 'Runs a Search Analytics (performance) query for a property' with specific metrics (clicks, impressions, CTR, position) and grouping by dimensions. It distinguishes itself from siblings like list_sites or get_top_queries by focusing on the full analytics query capability, and even explains output row structure.

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 rich usage context: how to get a totals row (no dimensions), pagination via start_row/row_limit, data_state selection for fresh data, and the caveat about anonymized data when grouping by query/page. However, it does not explicitly mention when to choose this tool over alternatives like get_top_queries, so it stops short of full 'when-not' 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?

The description adds valuable details beyond annotations: the empty API response shape, asynchronous processing, and the need for full OAuth scope. These are pragmatic behavioral insights that help the agent anticipate outcomes and 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?

Three sentences, front-loaded with action and scope. Every sentence adds value: the action, the feedpath constraint, the response behavior, the asynchronous nature, the follow-up tool, and the auth requirement. No redundancy or fluff.

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 two parameters and no output schema, this description is complete. It covers purpose, response format, async processing, OAuth requirement, and the recommended follow-up. The rich schema examples further fill in any remaining context.

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

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

The input schema already provides comprehensive descriptions for both parameters (feedpath format and site_url formats with examples). The description only restates the feedpath requirement ('full URL on the property') without adding new semantics, so it does not rise above the schema baseline.

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

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

The description clearly states the action ('Submits (or resubmits) a sitemap for the property') with a specific verb and resource. It distinguishes from sibling tools like list_sitemaps, get_sitemap, and delete_sitemap by focusing on the submission operation.

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

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

Provides clear context for when to use the tool and a follow-up action ('check errors/warnings later with get_sitemap'), plus an important prerequisite (full OAuth scope). It does not explicitly contrast with alternatives, but the purpose is distinct enough that the usage is implied.

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