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

Beyond the annotations (idempotentHint=true, readOnlyHint=false), the description discloses critical non-obvious behavior: the property remains unverified and yields no data until ownership is proven, and adding an existing property is a no-op rather than an error. This gives the agent expectations that are not derivable from the schema or annotations alone.

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

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

Three sentences with no filler: the primary action is front-loaded, followed by the critical caveat and the idempotent no-op behavior. Every sentence contributes essential operational knowledge.

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 registration tool with two well-documented parameters, the description fully covers the workflow context by naming the exact verification follow-up tools. The absence of an output schema is acceptable because the key agent-facing concern is the unverified state, which is explicitly disclosed.

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 parameter descriptions for site and account are rich, including URL vs domain property shapes and trailing-slash conventions. The main description adds no parameter-specific meaning, but the baseline of 3 is appropriate because the schema itself carries the semantic 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 opens with a specific verb and resource ('Register a property in Search Console'), making the core action unmistakable. It further differentiates itself from verification siblings by stating 'This only adds it' and referencing get_verification_token and verify_site as follow-ups, so the agent cannot confuse it with other property-related tools.

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

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

The description gives clear context for use: it registers a property and explains that verification is separate, instructing to follow with get_verification_token and verify_site. It does not explicitly name alternative tools or state when NOT to use it, but the intended workflow is unambiguous.

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

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

The description discloses useful behavior beyond the annotations: rows are sorted by click change, biggest losses are at the bottom, biggest gains at the top, and the default comparison is the last 28 days against the 28 before them. It leaves exact return fields unstated, but the read-only and idempotent annotations cover the safety 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?

Four sentences, each earning its place: what the tool computes, what questions it answers, the default comparison window, and row ordering. The most important information is front-loaded with no filler.

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

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

For a six-parameter tool with no output schema, the description covers selection criteria, default behavior, dimensions, and output ordering. It would benefit from naming the exact returned metrics, but the schema and annotations already handle parameter types, requiredness, and safety, so the definition is largely 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 high, so the baseline is 3. The description adds the meaningful default-window relationship that the schema's `days` property leaves implicit: the last 28 days are compared against the 28 days before them. Its dimension list mostly restates the schema enum, but the extra context justifies a 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 identifies a concrete resource and outcome: two equal date windows compared with precomputed deltas per query, page, country, or device. It also maps the tool to user intents like 'what changed' and 'are we up or down', making it easy to distinguish from the sibling analytics tools.

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

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

The phrase 'This is the tool for' plus explicit example questions gives strong when-to-use guidance. It does not name alternatives or state when not to use it, so it stops short of full exclusion guidance.

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

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

The description adds meaningful behavioral context beyond the annotations: it warns that history becomes unreadable until the property is re-added and re-verified, states Google does not offer an undo, and explains the confirm flag. This is exactly the kind of destructive, irreversible context an agent needs.

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 followed by the critical consequence and safety instruction. No filler or 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?

The description covers the irreversibility, the access loss, and the confirm requirement, which is strong for a destructive mutation. It does not describe the success/error response shape, but with no output schema and a fairly simple operation, this is a minor gap.

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

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

Schema description coverage is 100%, with rich per-parameter descriptions. The description only adds "Set confirm to true to proceed," which reinforces the schema's confirm parameter without adding new parametric meaning. 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 cleanly states the action: "Remove a property from this Google account's Search Console." It names a specific verb and resource, and the term "property" distinguishes it from sibling tools like 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 purpose and consequences are clear, but the description does not explicitly say when to use this tool versus alternatives such as delete_sitemap or add_site. It implies usage through the action verb, but does not name exclusions or sibling 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?

The description goes well beyond the annotations by explaining exactly what is affected: submission history and per-sitemap coverage are lost, while the sitemap file and URL indexing are not. It also highlights the irreversible nature and the need for confirmation (confirm=true). This provides full transparency for a destructive operation.

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

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

The description is concise and well-structured: it states the core action, clarifies what is not affected, notes what is lost, and instructs on confirmation. Every sentence adds meaningful 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 destructive tool with no output schema, the description thoroughly covers necessary context: the exact scope of impact, irreversibility, and the required confirmation flag. Combined with a rich parameter schema, an agent has all the information needed to invoke the tool safely and correctly.

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

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

The input schema already provides 100% coverage with detailed descriptions for all four parameters. The tool description adds no additional parameter-level information beyond what the schema already states, 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 states a specific action ('Stop tracking a sitemap on a property'), clearly identifies the resource, and explicitly distinguishes what the tool does not do (does not deindex URLs, does not delete the file). This makes it easy to differentiate from sibling tools like submit_sitemap or delete_site.

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

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

The description clearly conveys the intended use (stopping tracking a sitemap) but does not explicitly state when to use it versus alternatives, nor does it mention any preconditions or alternative tools. The context of the destructive operation is implied, but no explicit when/when-not guidance is given.

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

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

Annotations已声明readOnlyHint=true和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?

描述非常简短，没有冗余文字，但由于缺少动词，结构上不完整。它更像一个名词短语而非功能说明，虽然简洁但未能有效传达工具用途。

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?

对于如此简单的读操作，描述仅提及输出包含属性和权限级别，未说明具体返回结构或使用场景。由于目的模糊且没有输出schema，整体上下文不够完整，无法让agent确定调用后的预期结果。

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对site和account两个参数有100%覆盖，详细说明了属性和账号的格式及注意事项。描述本身未添加参数信息，但schema已足够充分，因此给予基线3分。

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?

描述是名词短语'One property and the permission level this account holds on it.'，缺少明确的动词（如'Retrieves'或'Gets'），未直接说明工具执行的操作。虽然从工具名推测是获取站点，但描述本身没有清晰表达目的，也未与兄弟工具区分。

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?

描述未提供任何关于何时使用此工具或何时选择替代工具（如list_sites、get_verification_token）的指导。尽管site参数的描述中提及调用list_sites，但这仅涉及参数值，而非工具选择的情景。

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

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

Annotations already provide the safety profile: readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful return-context but no additional side-effect or authorization behavior beyond what the schema and annotations already 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?

A single front-loaded sentence that names the resource, scope, and specific returned details without wasted words. Every clause contributes information an agent needs.

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

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

For a simple read-only lookup, the description combined with the rich input schema covers required inputs, safety, and expected return content. There is no output schema, so the listed return fields are helpful, though exact field names are not specified.

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 detailed explanations for all three parameters including property formats, account defaults, and examples. The tool description itself adds no parameter-level meaning, 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 states a specific operation: retrieving details for one submitted sitemap. It enumerates concrete returned attributes (last download, last submitted, URL counts per type, pending/errored status), which clearly distinguishes it from list_sitemaps or mutation 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?

Usage is implied: use this when you need details for a single submitted sitemap. However, it does not explicitly name alternatives such as list_sitemaps for enumerating sitemaps or submit_sitemap for adding one, so the agent must infer routing from sibling names.

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?

Explicitly states a non-obvious behavior: 'Minting a token changes nothing on its own.' This is valuable beyond the readOnlyHint/idempotentHint annotations, because it clarifies that the tool is safe but also that the verification flow is incomplete until verify_site is called.

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

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

Four sentences, each earning its place: first states the purpose, second and third give method-specific instructions, fourth clarifies side effects. 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?

For a tool with no output schema, the description covers the critical context: why to use it, how to use it with different property types, and what it does NOT do. Minor gap: it doesn't describe the token format or what the response contains, but the flow is clear enough for an agent to proceed 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 100%, so the schema already documents all parameters thoroughly. The description adds context about how method relates to property type, but that is also partly in the schema's enum descriptions. The description doesn't add much beyond the schema, hence baseline 3.

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 specific verb ('Mint') and resource ('the token that proves ownership'), immediately distinguishing this from verification itself. It also pre-empts confusion with the sibling verify_site by explaining the token's role.

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

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

Explicitly explains when to use this vs verify_site: 'Publish the token first, then call verify_site.' Also gives per-property-type method constraints (DNS for domain, META/FILE for URL-prefix), so an agent knows exactly when this tool is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds non-obvious behavior: the property-bound URL requirement and specific quota limits (2000/day, 600/minute). It doesn't describe failure modes or how a non-indexed URL is returned, but given annotation coverage the added context is 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?

Two tightly written sentences: the first front-loads the core behavior and return fields, the second adds use-case and constraints. There is no repetitive or filler content; every clause earns its place.

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

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

The description covers purpose, selection criteria, property constraint, and rate limits, which is nearly everything an agent needs to call correctly. Since there is no output schema, the description summarizes return fields at a semantic level but does not describe the exact response shape or error conditions, leaving a small gap.

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

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

Schema description coverage is 100%, so all parameters (url, site, account, language_code) are already documented. The description only restates the 'under the property' constraint from the schema and adds no new type or format details, meeting the baseline but not exceeding it.

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

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

States a specific action (ask Google about one URL) and enumerates the exact data returned: indexed status, sitemap, canonical comparison, last crawl, mobile usability, rich results, AMP. Names the target use-case ('why is this page not showing up') and, by focusing on 'one URL', distinguishes itself from the plural sibling inspect_urls.

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

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

Gives a clear diagnostic use-case and a practical constraint: inspect only pages that matter because of daily/minute quotas. It says the URL must sit under the property, which tells the agent when this tool is appropriate. It doesn't explicitly name alternative tools for aggregate analysis, but the context 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?

Even though annotations already declare this read-only, idempotent, and non-destructive, the description adds valuable behavioral context: throttled execution ('Requests run a few at a time'), partial-failure isolation ('one URL failing does not sink the rest'), and quota limits ('daily quota is about 2000'). This goes beyond the structured 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?

Four sentences, each earning its place: what the tool does, when to use it, how it behaves under load, and the quota constraint. The key output is front-loaded and 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?

For a read-only batch inspection tool with no output schema, the description sufficiently explains the return shape ('compact table') and the key fields. The operational constraints and failure behavior are covered, and parameter nuances live in the schema. Nothing critical is missing 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 fully documents site, urls, and account. The description adds batch-level context and quotas but doesn't need to explain individual parameters. A baseline of 3 is appropriate because the heavy lifting is done by the input schema.

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

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

The description states a specific verb and resource — 'Inspect several URLs on the same property' — and immediately distinguishes it from the singular sibling inspect_url by emphasizing batch inspection. The compact table with indexed/canonical/last-crawl columns precisely conveys what the tool returns.

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

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

It gives clear context for when to use this tool ('after a launch or a migration') and practical operational guidance about batch size and quotas. It doesn't explicitly contrast with inspect_url or say when to prefer alternatives, so it stops short of a full when-not discussion.

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, establishing a safe read-only operation. The description adds context about the default account behavior ('which one is used when a tool call does not name one'), which is valuable beyond the annotations. However, it doesn't describe the return structure or list format, which is a minor gap.

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 redundant words. The first sentence states the primary function and a key behavioral detail, the second explains the switching mechanism. Every word earns its place, and the description is appropriately sized for the tool's simplicity.

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 parameterless, annotation-rich tool, the description fully covers what an agent needs: what the tool lists, the default account behavior, and how to change accounts. No output schema exists, but the purpose is simple enough that return format is self-evident. 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 tool has zero parameters, and schema description coverage is 100% (empty schema). The baseline for 0 params is 4. The description mentions the `account` argument as a cross-tool concept, which adds context even though it's not a parameter of this tool. No deduction needed.

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

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

The description uses the specific verb 'List' and clearly identifies the resource ('Google accounts this server can act as'). It also distinguishes its purpose from the sibling tools by focusing on account management rather than site operations, making the tool's role immediately clear.

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

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

The description explains when to use the tool (to discover available accounts and the default account) and provides explicit instructions for switching accounts via the `account` argument on other tools. This gives clear context for usage relative to alternatives without needing to reference sibling 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 mark the call as read-only, idempotent, and non-destructive. The description adds useful behavioral context by revealing that a stop in lastDownloaded indicates Google is no longer reading the sitemap, which is not obvious from the UI or 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 focused sentences with no filler. The first sentence front-loads the core function and return fields, and the second adds a genuinely useful diagnostic insight 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 read-only list tool, the description tells the agent what data will be returned and even highlights a non-obvious way to interpret it. Combined with the thorough parameter schema and safety annotations, 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%, and each parameter is already explained in detail, including site formats, the account default, and sitemap_index filtering. The description adds no parameter-level meaning, 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 names a specific verb ('list') and resource ('sitemaps submitted for a property') and spells out the returned fields: last download time, URL counts per content type, and warnings/errors. This clearly distinguishes it from siblings like get_sitemap, submit_sitemap, and 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 gives clear context for when the tool is useful, especially the diagnostic signal of a stalled lastDownloaded date. It does not explicitly name alternatives or state when not to use it, but the list-focused purpose is unambiguous.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context about permission levels and the exactness of the returned URLs, which is not captured in annotations, enhancing transparency without contradiction.

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

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

Two sentences deliver the core purpose and essential usage context. The first sentence states the resource and scope, the second emphasizes the critical dependency on returned values. No fluff or redundancy.

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

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

Given the annotations and schema, the description is complete for an agent to call correctly. It clarifies the output format (siteUrl and permission) and the importance of exact values, covering all necessary aspects without needing 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?

The single parameter (account) is fully described in the schema, including how to omit it and how to discover valid values via list_accounts. The description does not need to add more, as the schema provides complete semantic 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 it lists all Search Console properties accessible by the account, includes permission levels, and explicitly positions it as the starting point. It distinguishes itself from siblings like get_site and add_site by focusing on the complete enumeration and the necessity of using its returned siteUrl values.

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

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

It explicitly says 'Start here' and explains that the returned siteUrl strings are required by other tools to avoid trailing-slash and sc-domain mismatches. This gives clear when-to-use guidance and highlights a critical dependency, making the usage context unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds the behavioral nuance that verified domains are not automatically Search Console properties, which helps interpret results. However, it doesn't disclose details like data freshness or whether the list includes subdomains, but the annotations carry the main burden.

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

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

Three sentences, each earning its place: the first states scope, the second clarifies the distinction from a sibling, and the third explains the practical use case. No fluff, front-loaded with the core purpose.

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

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

For a simple list tool with no required parameters and no output schema, the description is sufficient. It explains why this tool exists, when to use it, and how it differs from a sibling. The only minor gap is not describing the format of the returned list, but that is not critical given the annotations and simplicity.

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

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

The single parameter 'account' is fully documented in the schema with description and instruction to call list_accounts. The description provides no additional parameter semantics, but schema coverage is 100%, 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 states a specific verb ('list') and resource ('every site and domain this Google account has verified ownership of, across all Google products'), and explicitly differentiates from list_sites. It clearly conveys the scope and purpose, distinguishing it from the sibling tool.

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

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

The description explicitly contrasts with list_sites and explains when to use this tool: to distinguish 'not verified yet' from 'verified but never added'. It also implies when to use the alternative (list_sites for Search Console properties). This provides clear usage context and 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context: a two-to-three-day data finalization lag that explains short-looking recent windows, and Google's privacy withholding of rare queries causing query-level clicks to sum to less than site totals. These are non-obvious data behaviors that directly affect interpretation of results, going beyond annotation defaults.

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 yet information-dense: a one-sentence definition, a one-sentence routing to alternatives, and a marker introducing two critical caveats. Every sentence earns its place, and the most important identifier (what the tool is) is front-loaded. No fluff or repetition of schema content.

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

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

Given the tool's complexity (eleven parameters, many dimensions) and lack of an output schema, the description provides key interpretive context (data lag, privacy aggregation) that an agent must know to correctly evaluate results. It does not explicitly describe the return structure, but that is largely standard. The missing piece is a brief note on pagination or default row behavior, though schema already covers row_limit and start_row. Overall it is nearly 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 91%, so the input schema already documents parameters thoroughly, including site format, enum meanings, date formats, and default values. The description does not add per-parameter semantics but rather focuses on overall tool behavior. Per the baseline rule for high schema coverage, a score of 3 is appropriate; it adds marginal value by mentioning dimension combinability but not new parameter detail.

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

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

The description opens with the specific verb 'report' and enumerates the exact metrics (clicks, impressions, CTR, average position) and the resource (Google Search), with a clear grouping capability. It explicitly contrasts itself with sibling tools like top_queries and top_pages, distinguishing 'full-control' from convenient one-call alternatives. This leaves no ambiguity about what the tool does.

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

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

The description states a clear use case: the core report for custom dimension combinations, and explicitly advises that for common user questions, top_queries, top_pages, striking_distance, and compare_periods are one-call alternatives instead of assembling a body manually. This gives agents a routing rule. However, it does not explicitly say 'when not to use' beyond that implied contrast, so a small gap remains.

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 that this is read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond the annotations: the default position window of 5-20, the ordering by 'impressions being left on the table,' and the type of page returned. It could disclose the response format, but the safety profile is already covered by 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 first two sentences are reasonably efficient and front-load the key behavior and use case. The third sentence ('The single most useful report...') is subjective marketing and does not help an agent select or invoke the tool. The first sentence also has a grammatical stumble that slightly reduces clarity.

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

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

The tool has seven parameters and no output schema, yet the description explains neither the return shape nor the effect of days, limit, and account. An agent could make a default call with only site, but would lack crucial context about pagination, result contents, and how the ordering is computed. This is incomplete 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 low (~43%), with only site and min_impressions explained in the schema. The description contributes only the default position range and ordering concept; it does not clarify days, limit, account, min_position, or max_position semantics beyond what the schema already implies. Since the schema cannot carry the burden and the description does not compensate, this is a clear 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 identifies a specific report: pages/queries of a Search Console property already ranking between positions 5 and 20, ordered by impression opportunity. This is enough to distinguish it from generic siblings like top_queries or query_search_analytics. The first sentence is slightly awkward ('a property already ranks for'), but the resource and purpose are identifiable.

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 the tool is valuable: when a page already ranks near page one and a title rewrite or added content depth can capture more traffic. It explains why these opportunities are actionable because the ranking work is already done. It does not explicitly name alternatives or exclusion conditions, 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.

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

Annotations already include idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable behavior beyond those: the call returns immediately, Google fetches the sitemap on its own schedule, and no counts are returned. This async caveat is exactly the kind of context agents need.

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

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

Three sentences with no filler. The core action is front-loaded, followed by the most decision-relevant caveats: uniqueness, async behavior, and the correct follow-up tool. Every sentence earns its place.

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

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

Despite having no output schema, the description explains what the response will not contain and what will happen afterward, which is the most likely source of confusion. It also names get_sitemap as the verification path. This is complete enough for an agent to invoke 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 100%, so the baseline is 3. The tool's description text does not add parameter-specific meaning, but the schema already thoroughly documents site property shapes, account selection, and sitemap_url constraints. No deduction is warranted, and there is no extra value to credit.

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: 'Submit or resubmit a sitemap.' It immediately distinguishes the tool by stating it is 'the only way the API can ask Google to recrawl anything' and contrasts it with get_sitemap, making its unique role 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 gives explicit usage context: resubmit after publishing when recrawling is needed. It also tells the agent what not to expect and which alternative to use for verification: 'read the result back with get_sitemap rather than expecting counts here.' This is strong when/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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the default date-range behavior and the three-day trailing lag, which is useful context, but it does not describe pagination, result grouping, or other runtime behavior beyond the defaults.

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 first states the tool's purpose and output, the second gives the default time window. Both sentences earn their place, and the most important information is front-loaded.

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

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

For a read-only report with seven parameters covered mostly by schema descriptions, the description conveys the core output fields and default date range. Since there is no output schema, the explicit mention of impressions, CTR, and average position helps. It does not describe row limits or grouping, but that is not critical for this tool's core usage.

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

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

Schema description coverage is 71%, so the schema already documents most parameters. The description adds no meaning beyond the schema's property descriptions—it does mention output metrics (impressions, CTR, position), but not parameter semantics. With high schema coverage, 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 clearly identifies the resource (pages) and the selection criterion (earning the most clicks from Google Search), and it names the included metrics (impressions, CTR, average position). It does not use an explicit verb like 'returns' or 'lists', and it does not explicitly differentiate itself from sibling tools such as top_queries, but the meaning is still 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 only usage guidance is the default time window ('last 28 days ending three days ago'). There is no instruction on when to choose top_pages over query_search_analytics, top_queries, or other alternatives, and no exclusions or explicit-use conditions are provided.

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

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

The description adds a meaningful behavioral quirk beyond the readOnly/openWorld/idempotent annotations: the default window ends three days ago because an ending-today window reads as empty due to Search Console lag. This is useful operational context that is not available in the annotations or 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 sentences with no filler. The first states the core function and metrics, and the second justifies the default date window with a concrete reason. Every clause earns its place.

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

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

The description names the returned metrics and explains the freshness default, which is important because there is no output schema. Combined with the very detailed parameter schema, an agent can call this correctly, though it does not fully discuss result ordering, pagination, or how it differs from related report tools.

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

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

Schema description coverage is high (86%), and the schema already explains site, type, account, country, and page_filter with useful detail. The main description does not explain any parameters itself, which is acceptable here because the schema carries the semantic 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 identifies the resource: search queries ranked by clicks to a property, with a specific set of metrics (impressions, CTR, average position). It is clear enough to be distinguished from pages-focused siblings, though it does not explicitly name or contrast itself with top_pages or query_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 explains default behavior and a data-lag reason, but provides no guidance about when to choose this tool over query_search_analytics, top_pages, or compare_periods. There are no exclusions or alternative routing cues, leaving the choice to inference.

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 richly discloses behavioral traits beyond annotations. It explains the asynchronous nature of DNS propagation ('sometimes several minutes'), the failure condition ('fails until the token is actually reachable'), and explicitly states idempotency ('Retrying is safe'). This complements the idempotentHint=true annotation by explaining why retrying is safe. It also implies verification is a non-reversible ownership claim but 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 three sentences, each earning its place: the first states the action and requirement, the second explains the failure condition and propagation delay, and the third reassures about retry safety. It is front-loaded with the primary purpose, and no redundant phrases exist.

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

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

The description is complete for a tool with a full input schema and rich annotations. It covers the prerequisite step, the operational behavior, and error recovery. There is no output schema, but the description doesn't need to explain return values because the tool's outcome (ownership claim) is implicit and its behavior is fully disclosed. No critical missing context for an agent to invoke it correctly.

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

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

The input schema covers 100% of parameters with descriptions, including enum explanations and references to get_verification_token for 'identifier' and 'method'. The description adds context about the token being live and reachable but doesn't add parameter-specific meaning beyond the schema. Since schema coverage is complete, 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 clearly states the tool's purpose: 'Claim ownership once the token from get_verification_token is live.' It uses the specific verb 'claim' with the resource 'ownership' and references a prerequisite tool. While it doesn't explicitly differentiate itself from sibling tools beyond mentioning get_verification_token, its unique role in the verification workflow is evident from the description and schema.

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

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

The description gives clear usage context: it must be used after obtaining a token from get_verification_token, and it mentions that the token must be 'actually reachable' before verification succeeds. It doesn't explicitly state when not to use it or name alternatives, but the workflow dependency is clear. The mention that 'Retrying is safe' provides practical usage guidance for handling failures.

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