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

Beyond the readOnlyHint=true annotation, the description discloses a concrete rate limit (2,000/day), a per-call cap (100 URLs), and the nature of the return data (summary with issues highlighted). It also adds a crucial behavioral instruction: base analysis only on returned data, report exact numbers, and do not speculate. This meaningfully enriches what annotations alone 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 description is compact and front-loaded with the core purpose, followed by limits and a high-value analysis directive. The IMPORTANT block, while emphatic, earns its place because it shapes agent behavior on a data-querying tool. Every sentence contributes.

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 two-parameter, batch read tool with no output schema, the description is complete: it states what the tool does, what it returns, its rate and size limits, and how the agent should handle the returned data. It also benefits from schema coverage for parameter details, so nothing essential 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 description coverage is 100%, with both urls and siteUrl already documented in the input schema. The description does not add substantial new parameter-level meaning beyond what schema provides; it only restates the max 100 URLs constraint that is already visible in maxItems. Baseline 3 is therefore 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 a specific verb and resource ('Inspect multiple URLs at once') and distinguishes it from the single-URL sibling tool by emphasizing batch operation. It also states the output ('summary of index status across all URLs with issues highlighted'), making the tool's purpose 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?

The description clearly signals when to use this tool: when inspecting multiple URLs at once. It also gives operational guardrails (max 100 URLs per call, rate limit). However, it does not explicitly name the alternative inspect_url or state 'for a single URL, use inspect_url instead,' so it stops short of a full when-not/exclusion statement.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds meaningful behavioral guidance beyond these: base analysis only on returned data, report exact numbers, avoid speculation, and explicitly say when data is insufficient. This aligns with openWorldHint=false and gives the agent concrete handling instructions.

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 and well-structured: the first sentence defines the concept, the second states the output value, and the third provides essential analytical guardrails. Every sentence earns its place; there is no filler or repetition of schema details.

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 partially conveys what the tool returns by stating it shows which pages rank for the same keywords and implies numeric results through 'report exact numbers.' It is sufficient for an agent to understand the tool's general output, though a more explicit return shape or field-level detail would improve completeness given the absence of an 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 description coverage is 83%, so the parameters are already well documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, such as date handling, row limits, or minImpressions. The baseline of 3 applies because the schema carries the parameter documentation burden.

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 detects keyword cannibalization and defines it as multiple pages from the same site competing for the same queries, splitting ranking potential. It identifies the output (which pages rank for the same keywords) but does not explicitly differentiate itself from sibling tools like search_analytics or topic_clusters, so it is clear but lacks explicit sibling positioning.

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: use when you need to detect keyword cannibalization or decide whether to consolidate pages. However, the description does not state when to prefer this tool over related tools such as find_opportunities or topic_clusters, nor does it provide exclusions or alternative routing. The IMPORTANT note is about data discipline, not about when to invoke the tool.

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 readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds value beyond annotations by stating the return type (delta calculations) and enforcing a data-only analysis rule, which is useful for agents using the response.

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 front-loaded: purpose, output, use cases, then a critical guidance note. Every sentence earns its place, and there is no redundant 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?

For a comparison tool with no output schema, the description sufficiently describes the returned metrics and sets expectations for data-driven analysis. Minor gaps remain around delta sign conventions and exact response shape, but the tool is still completely invocable from the information provided.

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 88%, so the structured schema already documents most parameters. The description mentions 'two date ranges' and the computed metrics but adds little parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource ('Compare search performance between two date ranges') and names the exact output metrics (deltas for clicks, impressions, CTR, position). This inherently distinguishes it from single-period analytics tools like search_analytics, even though no sibling is named 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?

The description gives clear use cases: tracking SEO changes, algorithm updates, and seasonal trends. It provides good context for when to select this tool, though it does not explicitly state when not to use it or name alternatives.

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

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

Annotations already mark it read-only/non-destructive, and the description adds meaningful handling guidance: 'Base your analysis only on the data returned by this tool', 'Report exact numbers', and 'Do not speculate'. It also recognizes potential data insufficiency and instructs the agent to say so, which goes beyond the structured hints.

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

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

The description is front-loaded with the core definition and threshold, then adds concise usage/output behavior. Every sentence earns its place; the 'IMPORTANT' clause is compact and high-value rather than 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 read-only analysis tool with no output schema, the description explains what it identifies, the threshold logic, and how to handle insufficient data. It does not spell out the exact response shape/metrics, but an agent has enough context to invoke the tool and interpret the returned pages.

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

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

Input schema covers 80% of parameters with clear descriptions. The tool description adds a conceptual context for `months` and 'traffic decline', but does not materially explain siteUrl, rowLimit, minClicks, or searchType beyond what the schema already provides. Schema carries the parameter burden, so baseline 3 is appropriate.

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

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

Description states a precise objective ('Detect content decay') with an exact operational definition ('pages with 3 or more consecutive months of traffic decline') and clarifies the threshold ('One bad month is noise'). This distinguishes it from broader siblings like diagnose_traffic_drops by focusing on sustained multi-month decline.

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 clearly frames the intended use: surface pages needing refresh before disappearing from search results, and implies this is for sustained decline rather than isolated one-month dips. It does not explicitly name alternatives or provide when-not-to-use exclusions, but the context is sufficient for an agent 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: benchmarks are aggregated from multiple studies (directional only), and the tool's output should be treated as evidence-based and not over-interpreted. It doesn't describe return format, but the strong guardrails about data usage compensate.

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 well-structured: the core purpose is in the first sentence, followed by the use case and the critical behavioral guardrails. It's slightly longer than ideal but every sentence earns its place, especially the IMPORTANT directive that constrains an AI agent's output.

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 comparison tool with no output schema, the description covers what the tool does, why to use it, and how to interpret results. It lacks explicit return-format documentation, but the 'do not speculate, report exact numbers' directive tells the agent what to expect qualitatively. Given the rich parameter schema and readOnly annotation, this is reasonably 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 description coverage is 83%, so most parameters are already documented in the schema. The description doesn't add parameter-specific details beyond what the schema provides, but it does clarify the overall purpose of the parameters (position-based benchmark comparison). Baseline 3 is appropriate given the high 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 states a specific verb ('Compare'), a specific resource ('actual click-through rates against industry-average benchmarks by position'), and the intended use case ('Identifies pages or queries with CTR below expected levels'). This clearly distinguishes it from the sibling tools like search_analytics (which reports raw metrics) and find_opportunities (which is broader).

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

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

The description explicitly frames the comparison against industry benchmarks and notes they are 'directional guidance'. It also gives strong guidance on how to use the data: base analysis only on the returned data, report exact numbers, don't speculate, and say if data is insufficient. This is clear usage context with an implied contrast to other analytics tools.

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

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

Annotations already signal destructiveHint=true and readOnlyHint=false. The description goes beyond this by adding a non-obvious behavioral nuance: removing the sitemap from tracking does not block crawling of its URLs. This is valuable context that the structured annotations cannot convey. It doesn't mention reversibility, but the destructive annotation already covers the risk 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?

Two sentences, no filler, and the key action is front-loaded. The clarifying second sentence earns its place because it prevents a dangerous misconception about crawling behavior.

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, full schema coverage, and destructive annotation, the description covers the essential operational facts. It could additionally state that the action is irreversible or describe the response, but these are minor gaps for a low-complexity deletion 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 100%, so the schema already documents both siteUrl and sitemapUrl adequately. The description adds no parameter-level detail beyond what the schema provides, which matches the baseline expectation for full 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 states a specific verb ('Remove') and resource ('a sitemap from Search Console tracking'), and immediately clarifies an important boundary: it does not prevent Google from crawling discovered URLs. This clearly distinguishes the deletion from crawling-related behaviors and sibling tools like submit_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 makes the core usage context clear: use this when you want to stop tracking a sitemap in Search Console. It also provides an explicit exclusion by noting the tool does not stop Google from crawling URLs, which prevents a common misuse. However, it doesn't explicitly name alternatives or state when another sibling would be more appropriate.

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

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

Beyond the readOnlyHint annotation, the description discloses important behaviors: the window comparison, the categorization logic, and the strict instruction to base analysis only on returned data without speculating. It also instructs the agent to admit when data is insufficient, which is valuable non-obvious behavioral guidance.

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 tightly written and front-loads the core purpose before explaining categories and analytical rules. Every sentence adds useful information, including the important anti-speculation guardrail, with no filler or redundancy.

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

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

The description provides the analytical framing, categories, time windows, and reporting constraints, which is strong for a read-only diagnostic tool. However, there is no output schema and the description does not explicitly describe the response shape or fields, so an agent must infer what exact numbers will be returned.

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 75%, with siteUrl, rowLimit, and minClicksDrop already documented in the schema. The description adds no parameter-specific semantics but does not need to because the schema handles most of it. searchType has enum values but no description, and the tool description does not compensate for that 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?

The description opens with a specific verb and resource: 'Find pages that lost traffic and diagnose why.' It then enumerates concrete drop categories (ranking loss, CTR collapse, demand decline), which clearly distinguishes this diagnostic tool from generic analytics or indexing siblings.

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

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

The description clearly implies when to use this tool: when diagnosing traffic drops with a 7-day vs 28-day comparison. It does not explicitly name alternative sibling tools or state when not to use it, but the purpose is specific enough that an agent can infer the correct context.

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

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

Annotations already indicate a read-only, non-destructive operation. The description adds meaningful behavioral context: it compares a recent 7-day window to 28 days prior, and it explicitly instructs the agent to rely only on returned data, report exact numbers, and avoid speculation. This goes beyond the structural 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 front-loaded with the tool's purpose and opportunity categories, then adds the comparison window and usage constraints. It is slightly verbose with the IMPORTANT clause, but every sentence carries operational value and there is 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?

For a tool with no output schema, the description gives a solid understanding of what the tool does, the data window it uses, and how the agent should handle results. It does not describe the response shape or clarify the searchType parameter, but the agent instructions to avoid speculation partially compensate for the missing output details.

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 documents three of four parameters with descriptions, so baseline semantic coverage is already solid. The description enriches the 'type' semantics by explaining what each opportunity category means (e.g., positions 5-20 with high impressions but low CTR), but it does not clarify searchType, which has no schema description.

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: automatically identify SEO opportunities across three named categories (quick wins, declining content, emerging queries). It is specific about the resource and verb, but it does not explicitly differentiate itself from related siblings like diagnose_traffic_drops or content_decay.

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

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

The description implies when to use the tool by naming the opportunity types and the 7-day vs 28-day comparison window. However, it does not explicitly state when to prefer this tool over sibling tools such as compare_periods or diagnose_traffic_drops, nor does it give 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 define the operation as read-only (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds a little context by stating what the tool returns (most recent update and removal notifications), but does not disclose other behaviors like empty states, response format, or potential errors. With annotations covering safety, this is adequate but not rich.

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

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

Two sentences with no fluff. The primary action is front-loaded, and the follow-up sentence clarifies the output scope. Every word earns its place.

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

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

For a simple one-parameter read-only tool with no output schema, the description is complete enough for an agent to select and invoke it correctly. It states what is checked, what the result contains, and the required input is clear from the schema. Nothing essential 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 schema provides 100% coverage for the sole parameter, with a description ('The URL to check notification status for'). The tool description simply repeats 'for a URL' without adding value beyond the schema, 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 uses a specific verb ('Check') and a clear resource ('status of Indexing API notifications for a URL'), and specifies that it shows the most recent update and removal notifications. This clearly differentiates it from siblings like notify_url_update because it's about checking status, not sending notifications.

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 usage scenario: after notifications have been sent, an agent can check their status. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or prerequisite actions. This leaves the guidance at an implied level.

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 carry read-only/non-destructive safety, and the description adds the daily 2,000-inspection quota plus a strong evidence-handling policy (report only returned data, no speculation, admit insufficient data). This goes beyond what annotations provide, though it does not disclose error/response edge cases.

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

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

The description is dense and well-ordered: purpose, returned data, quota, then an important caveat. It is slightly verbose due to the repeated guidance in the IMPORTANT sentence, but every part is relevant.

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 compensates by enumerating the returned data fields and adds the quota and non-speculation rules. An agent has enough to call it correctly, though error/empty-response behavior is not covered.

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 documents all three parameters including the siteUrl fallback. The description adds no parameter-level meaning beyond the schema, so the baseline of 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 uses a specific verb ('Inspect') on a specific resource ('a single URL in Google Search Console') and lists concrete returned data (index status, mobile usability, rich results, AMP status, canonical, last crawl time). This clearly distinguishes it from siblings like batch_inspect_urls and search_analytics.

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

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

The description establishes clear scope—single URL inspection and the exact diagnostics returned—so an agent can infer when this tool is appropriate. It does not explicitly name alternatives or state when-not-to-use, though the 'single URL' wording plus the sibling list makes the batch alternative obvious.

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

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

Annotations already mark this as a read-only, non-destructive operation. The description adds useful behavioral context by clarifying that the listing is scoped to the authenticated account and that the response includes property type and permission level, which is not available from annotations or the empty schema.

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 with no filler. The main action and scope are front-loaded, and the added sentence about output fields earns its place by describing what the agent will receive.

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 zero-parameter, read-only listing tool, the description is sufficient: it names the resource, the scope, and the output contents. There is no output schema, so mentioning property type and permission level helps the agent understand the response shape.

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 no parameters, so the baseline is 4. The description gives no parameter details, but none are needed for a zero-parameter tool, and schema coverage is trivially complete.

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 ('List'), a specific resource ('Google Search Console properties'), and a clear scope ('accessible to the authenticated account'). It also states what the result contains (property type and permission level), making it easy to distinguish from sibling tools like 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?

The intended use is clear: call this when you need to see all properties the authenticated account can access. It does not explicitly contrast with alternatives, but no sibling tool is a direct alternative for this listing operation, so the lack of exclusions is acceptable.

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 this a read-only operation, so no contradiction exists. The description adds useful behavioral context by enumerating the returned data categories (status, submission date, error/warning counts, URLs submitted vs indexed) and by instructing the agent to avoid speculation and report exact numbers, which meaningfully shapes how the tool output should be used.

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 and front-loaded with the core action. The additional warning sentences are directly valuable for correct use of the tool's output and do not feel redundant 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?

For a simple tool with one optional parameter, read-only annotations, and no output schema, the description conveys the main return contents and cautions against over-interpreting data. It does not provide a full field-by-field schema of the response, but it covers what an agent needs to call and interpret the tool effectively.

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%: the single parameter siteUrl is already documented with its fallback behavior. The description does not add any further parameter-level meaning, 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 names the action ('List all sitemaps submitted for a site in Search Console') and specifies the resource and scope. It is obvious from the sibling tool names that this is a read/list operation rather than submit or delete, though it does not explicitly differentiate itself from siblings.

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

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

The description implies when to use the tool: whenever a listing of submitted sitemaps and their status counts is needed. However, it gives no explicit guidance about when not to use it or when a sibling like submit_sitemap or delete_sitemap would be more appropriate.

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

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

The description goes beyond the annotations by disclosing the quota and the structured-data requirement, which are important operational constraints. It also clarifies that 'deletion' here means sending a deletion notification via the API, not destructively modifying local data, which aligns with destructiveHint=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?

Two sentences, front-loaded with the core action, and the operational constraints are compactly placed in a note. Every word contributes useful information.

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

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

For a simple two-parameter tool with full schema coverage, the description is nearly complete: it states the action, supported use cases, and quota. It does not describe the response format or error conditions, but no output schema exists and the input side is fully covered.

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 documents both parameters thoroughly with 100% coverage, including the URL format and the enum meanings. The description adds no new parameter-level detail, so the baseline score of 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 uses a specific verb ('Submit') and names the exact resource and API ('URL update or deletion notification via the Indexing API'). It clearly distinguishes this tool from sitemap-submission siblings by focusing on URL-level notifications rather than bulk 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 gives clear eligibility context: it is 'officially supported only for pages with JobPosting or BroadcastEvent structured data' and mentions a daily quota of 200. It does not explicitly name alternative tools or say when not to use it beyond that constraint, but the restriction is strong.

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 safety (readOnlyHint=true, destructiveHint=false). The description goes beyond annotations by adding a strong, explicit instruction to base analysis only on returned data, report exact numbers, avoid speculation, and admit insufficient data. This is valuable behavioral context not present in 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?

The description is concise and front-loaded with the core action. The capability list is dense but relevant, and the IMPORTANT caveat earns its place. It could be slightly more structured, but there is no fluff or repetition.

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

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

The description summarizes capabilities well and the schema covers parameters, but there is no output schema and the description does not explain the response format (e.g., metrics like clicks, impressions, CTR, position). For a data-query tool, this is a meaningful gap, though the 'don't speculate' guidance mitigates some risk.

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

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

Schema description coverage is 100%, so the structured schema already documents all 10 parameters. The description's mentions of regex filters, hourly data, and 25K rows reinforce capabilities but add no new parameter-level meaning beyond the schema.

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

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

Description opens with a clear, specific verb and resource: 'Query Google Search Console performance data.' It further clarifies scope with dimensions, search types, filters, and row limits. It does not explicitly contrast with sibling analytics tools like compare_periods or diagnose_traffic_drops, so it stops short of full sibling differentiation.

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 this tool is for retrieving raw GSC performance data, but it provides no explicit guidance on when to choose it over the many sibling analytics tools. No alternatives, exclusions, or prerequisite conditions 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 mark this as a non-read-only mutation, so the description does not need to repeat that. It adds one useful behavioral precondition—the URL must be accessible and return valid XML—but it does not disclose error conditions, property verification requirements, or duplicate-handling 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?

Two short sentences, front-loaded with the main action and followed by the key precondition. No filler or repetition of schema/annotation data.

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 write action with no output schema, this is nearly complete: the action and the critical input condition are stated. Minor gaps are that it does not mention that the property must be verified in Search Console or describe the success/error response, but these are not blocking for a basic call.

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

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

With 100% schema coverage the baseline is 3; the description earns an extra point by constraining sitemapUrl beyond the schema's uri format: it must be accessible and return valid XML. It does not address siteUrl, but that parameter is already documented with its fallback behavior in the schema.

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

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

The description uses a specific verb and resource: 'Submit a new sitemap to Google Search Console.' This immediately distinguishes it from read/list siblings such as list_sitemaps and from delete_sitemap, so the agent can disambiguate without examining schemas.

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

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

No explicit when-to-use or when-not-to-use guidance is given, and no alternative tool is named. The valid-and-accessible XML precondition offers some context, but the tool's usage is only implied by the verb and resource. An agent is not told to use list_sitemaps for existing entries or delete_sitemap for removal.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: the tool returns aggregate/per-page metrics and top queries, and it includes an important instruction about relying only on returned data, reporting exact numbers, and avoiding speculation. This is valuable operational guidance not present in annotations.

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

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

The description is front-loaded with the core action in the first sentence, followed by output details, use case, and a necessary behavioral warning. It is slightly longer than minimal, but each sentence earns its place; the IMPORTANT instruction is essential for correct use and is not 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?

Given there is no output schema, the description adequately explains what data the tool will return (aggregate and per-page metrics, top queries). It also provides essential analysis constraints. Minor gaps remain: it does not mention the meaning or effect of searchType, nor the default date ranges, though the schema covers those details. The tool is simple enough that the description is sufficiently complete for an agent 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 83%, so the baseline is 3. The description reinforces the meaning of urlPrefix by explaining it in the context of cluster analysis, but it does not add substantial parameter semantics beyond what the schema already provides. Other parameters like endDate, startDate, and searchType are only covered in the schema.

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

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

The description states a specific action ('Analyze performance') with a specific resource ('all pages under a URL path prefix') and concrete examples ('/blog/'). It clearly indicates the tool outputs aggregate, per-page, and top-query metrics, which differentiates it from more general analytics tools. However, it does not explicitly name sibling tools or contrast itself with them, so it misses the full 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 description provides a clear use context: 'Useful for understanding how entire content sections perform.' This tells an agent when the tool is appropriate without ambiguity. It does not explicitly mention when not to use it, nor does it point to alternatives such as search_analytics or compare_periods, so it stops short of full 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 establish this is read-only and non-destructive. The description adds valuable behavioral guardrails: base analysis only on returned data, report exact numbers, avoid speculation, and state when data is insufficient. This goes beyond the structured 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 front-loaded with the core purpose and then adds concise behavioral guidance. The IMPORTANT section has some redundancy among its prohibitions, but each sentence still contributes to correct usage.

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

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

For a tool with no output schema, the description compensates by telling the agent to rely only on returned data and to report exact numbers. It does not specify the response shape, but the verification context and parameters are covered well enough for 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 100%, so the schema already documents all 9 parameters. The description adds little parameter-specific meaning beyond reinforcing that a metric is checked against an expected value, which the schema also conveys. 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 states a specific verb and resource: re-querying the Google Search Console API to verify a claim about search performance data. It clearly differentiates this tool from analysis/reporting siblings like search_analytics and compare_periods by framing it as a verification step before presenting numbers.

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 clear context for when to use the tool: before presenting claims, especially ones from earlier in the conversation. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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