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

Adds meaningful behavioral context beyond the annotations: the property remains unverified and returns no data until ownership is proven, and duplicate adds are no-ops rather than errors. These are exactly the lifecycle and idempotency details an agent needs for a mutation tool, and they align with the annotation hints rather than 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?

Three tightly written sentences, front-loaded with the core action and immediately followed by the critical caveat and next steps. Every sentence contributes useful information with no filler.

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

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

Given the lack of an output schema, the description adequately explains the tool's effect and post-conditions, and the detailed input schema covers parameter nuances. It could say more about what the call itself returns on success, but for this registration step the lifecycle guidance is strong enough.

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 both parameters, including the important URL-prefix vs domain-property distinction and the account selection. The description adds no further parameter-level meaning beyond what the schema provides, 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?

States a specific verb ('register/add') and resource ('property in Search Console'), and distinguishes the operation from sibling tools by clarifying that it only adds and leaves the property unverified. An agent can tell this apart from get_site, list_sites, delete_site, and verify_site directly from the description.

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

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

Gives clear context for when this is the right tool and explicitly names the follow-up tools get_verification_token and verify_site. It also usefully notes that re-adding an existing property is a no-op rather than an error. It stops short of explicitly stating when not to use it or naming alternatives like list_sites for inspection, so it is clear but not fully exhaustive.

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

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

Annotations already declare readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description adds real behavioral context beyond the schema: the default 28-vs-28 comparison and the sort order (biggest losses at the bottom, gains at the top). It omits error behavior for unsupported dimensions, which the schema covers instead.

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

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

Three sentences, front-loaded with the core concept, then intent routing, then default behavior and sort order. No filler; each sentence adds distinct 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 6-parameter read tool with no output schema, the definition conveys the comparison model, default window, dimensions and result ordering. It could say more about what a returned row contains, but the essential calling information is present.

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 83%, so the baseline is 3, but the description adds value the schema lacks: it explains the 'days' parameter in terms of two adjacent windows, not just a length, and summarizes the dimension options. That deepens semantics beyond the enum definitions.

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

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

States a specific verb+resource ('two equal windows side by side with the deltas already computed') and enumerates what it produces (changes per query, page, country, device). Distinct from siblings like query_search_analytics or top_queries, which retrieve a single window without deltas.

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?

Routes by user intent with quoted phrasing ('what changed', 'are we up or down', 'which pages lost traffic') and states the default comparison window. It does not explicitly name the sibling alternatives an agent should prefer instead, which keeps it 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 cover destructiveHint=true and idempotentHint=false, yet the description adds critical non-redundant behavior: history is no longer readable until re-added and re-verified, and Google offers no undo. This is exactly the extra context an agent needs before firing a destructive call.

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

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

Two sentences, zero waste: the first states what and where, the second front-loads the irreversibility before the confirm instruction. Nothing repetitious.

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, non-idempotent mutation with no output schema, the description supplies the consequence and undo profile, and annotations cover the safety flags. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds the meaning of the confirm gate ("Set confirm to true to proceed"), clarifying it as an active authorization step rather than merely an optional flag. The site/account parameter semantics come entirely from the schema.

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

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

States a specific verb and resource ("Remove a property from this Google account's Search Console") with scope qualifier. It is clearly distinguishable from siblings like delete_sitemap or verify_site, which operate on different sub-resources.

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

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

Gives clear context for when to invoke — it warns that history becomes unreadable and there is no undo, then instructs "Set confirm to true to proceed." It does not explicitly name an alternative tool or a when-not condition, but the destructive consequence framing provides adequate invocation 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 flag destructiveHint=true, non-idempotent and openWorld, but the description goes further by enumerating exactly what is and is not destroyed: no deindexing, no file deletion, loss of submission history and per-sitemap coverage. That is precisely the context an agent needs before a destructive call.

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

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

Four short sentences, front-loaded with the action and scope, then the negative consequences, then the gating flag. No filler 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?

For a destructive, no-output-schema tool, the description supplies the blast radius, the irreversible-loss detail, and the confirmation gate — everything an agent needs to call it safely. Return values are unnecessary since the operation produces no meaningful payload.

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

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

Schema coverage is 100%, so all four parameters (including the nuanced site-vs-domain property distinction and account selection) are fully documented in the schema itself. The description's only parameter remark, 'Set confirm to true to proceed', largely restates the schema's confirm description, adding little beyond the baseline.

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

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

States a specific verb and resource ('Stop tracking a sitemap on a property') and immediately scopes what the operation does not touch. An agent can distinguish it from delete_site, submit_sitemap, and delete_sitemap siblings without opening any 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?

Gives clear operational context — it does not deindex URLs or delete the file, and requires confirm=true to proceed. It does not, however, name the alternative tools (e.g. delete_site for removing the property itself), so sibling routing is left partly 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds no behavioral context on top of that: it does not mention that a mismatched property shape returns 403 (that is relegated to the schema) or what the permission level values are.

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 short sentence with no filler, front-loaded on the resource. It is slightly too terse to read as a complete statement of purpose, which keeps it out of the top band.

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

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

There is no output schema, and the description omits the return shape beyond saying 'permission level.' For a simple two-parameter read tool with full schema coverage and complete annotations this is adequate, but the returned object's fields remain unspecified.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly, including the URL-prefix vs sc-domain: distinction and the 403 consequence. The description adds nothing about parameters, so baseline 3 applies.

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

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

The description names the resource (one property) and the payload (the permission level this account holds), which distinguishes it from list_sites, the plural enumerator in the sibling set. It is a verbless fragment, but 'get_site' plus this phrase is unambiguous about 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?

The description offers no when-to-use guidance and never contrasts itself with list_sites or list_verified_sites, which are the obvious alternatives for property lookups. The only routing advice (call list_sites for exact strings) lives in the schema text for the 'site' param, not in the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's value-add is naming the returned fields (last download, pending/errored status), but it says nothing about auth/permission requirements, error behavior (e.g. what a 403 looks like), or account scoping.

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

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

A single sentence that front-loads the identity of the resource and then lists the payload. No filler, no redundancy with the title.

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 carries the return-value burden and does so by enumerating the key fields. For a read-only single-record lookup with fully documented parameters, this is nearly complete; only the error/permission behavior and the fact that a sitemap must already be submitted are unstated.

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 three parameters (site, account, sitemap_url) are already documented in the schema, including the URL-prefix vs domain-property 403 pitfall and the list_sites/list_accounts pointers. The description adds no parameter detail 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?

States a specific resource ('one submitted sitemap') and enumerates exactly what it returns: last download, last submitted, URL counts per type, and pending/errored status. The word 'one' implicitly distinguishes it from the list_sitemaps sibling, so an agent can tell them apart without opening either schema.

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

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

Usage is only implied: the description says 'submitted sitemap', which suggests it applies to sitemaps already registered via submit_sitemap and is the single-item counterpart to list_sitemaps. There is no explicit when-to-use statement, no precondition (e.g. 'you must know the sitemap_url first'), and no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description still adds meaningful behavioral context by clarifying the side-effect profile ('Minting a token changes nothing on its own') and the external publish-then-verify workflow that annotations cannot express.

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

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

Four short sentences, front-loaded with purpose, then the per-method publish instructions, then the sequencing constraint, then a closing side-effect note. No sentence is filler.

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

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

With no output schema, the description should ideally say what is returned (the token string), which it only implies via 'the returned token'. Otherwise it fully covers prerequisites, method constraints, and follow-up action for a 4-parameter 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% and the schema already states the type/method constraints and identifier formats, so the description's restatement of DNS vs META/FILE and apex TXT placement adds only marginal detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Mint the token that proves ownership of a site or domain') and frames the outcome ('so a new property can be verified'). It is unmistakably distinct from sibling tools like verify_site, add_site, or get_site.

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

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

Explicitly routes the workflow: choose DNS for a domain property, META or FILE for a URL-prefix property, 'Publish the token first, then call verify_site.' The when-to-use and the next step are both spelled out.

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?

Goes well beyond the annotations (which already state readOnly/idempotent/non-destructive) by disclosing hard operational limits: the URL must be under the property, and quota is roughly 2000 inspections/day and 600/minute per property. That rate-limit and loop guidance is exactly the context annotations cannot convey.

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

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

Front-loads what the tool returns, then the diagnostic use case, then the two practical constraints. Dense but every sentence carries information; 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 read-only inspection call with no output schema, the description enumerates the returned fields, states the two required-parameter relationship, and flags the rate limits and property constraint. An agent has everything needed to call it correctly and pace it sensibly.

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 well documented there, including the URL-prefix vs domain property trap and the list_sites cross-reference. The description only restates the 'must sit under the property' constraint, adding no new per-parameter syntax or format 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?

States a specific verb and resource ('Ask Google what it actually knows about one URL') and enumerates the exact data returned (indexed status, sitemap, canonical mismatch, crawl date, mobile usability, rich results, AMP). It is clearly distinguishable from inspect_urls (plural) and 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?

Gives an explicit use case ('This is the tool for why is this page not showing up') and warns to inspect selective pages rather than a whole site. It doesn't name the sibling batch tool inspect_urls as the alternative for that case, so routing is slightly less complete than 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?

Goes well beyond the annotations by disclosing concurrency/throttling ("run a few at a time to stay inside the per-minute quota"), partial-failure semantics ("one URL failing does not sink the rest"), and a numeric quota ceiling (~2000 inspections/day/property). These are operational facts an agent cannot infer from readOnlyHint/idempotentHint.

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 tight sentences, front-loaded with purpose and return value, then usage, then operational constraints. No wasted clauses or restated schema.

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

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

With no output schema, the description carries the return-value burden and does so (indexed/not, canonical, last crawl). Combined with quota, throttling, and partial-failure notes, an agent has everything needed to call this correctly and reason about failures.

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 parameters are already well documented, including the site-shape 403 warning. The description reinforces that all URLs must belong to the property but adds no syntax or format detail 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?

States a specific verb and resource with scope ("several URLs on the same property in one call") and names the return contents (indexation status, Google's canonical, last crawl). It is clearly distinguishable from the sibling inspect_url, which handles a single URL.

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

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

Gives an explicit triggering scenario ("check a batch of pages after a launch or a migration") and a caution about batch sizing. It stops short of explicitly naming inspect_url as the single-URL alternative, but the batch framing makes the split 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real behavioral context beyond them: the output determines account resolution for every other tool, and the account argument is the switching mechanism. It does not describe the return shape, but that is a minor omission for a read-only list.

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 tight sentences with no filler. The identity of the tool comes first, followed immediately by the actionable detail about the default account and how to switch.

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 zero parameters, no output schema, and annotations that already declare the read-only, idempotent nature, the description covers everything needed to select and invoke it. The only gap is that the exact return shape (e.g., a list of emails plus a default marker) is left implicit.

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

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

The tool takes zero parameters, so the baseline is 4. The description's mention of the `account` argument is a cross-tool usage note rather than a parameter of this tool, but it is still helpful context about how the listed emails get consumed.

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

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

States a specific verb and resource ('List the Google accounts this server can act as') and goes further by naming the second piece of information returned: which account is the default. This is unambiguous and clearly distinct from every sibling tool, all of which operate on sites/sitemaps/analytics rather than accounts.

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?

Explains the context for calling it (to learn the available accounts and the default) and routes the agent to the alternative action: 'Pass an email as the `account` argument on any other tool to switch.' No explicit when-not-to-use case is given, but the cross-tool relationship is spelled out.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), and the description adds real behavioral content: the returned fields (lastDownloaded, URL counts per content type, warnings/errors) plus a non-obvious diagnostic signal about silently stalled sitemaps. It omits pagination/limits, keeping it from a 5.

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

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

Two sentences, purpose front-loaded, and the second sentence earns its space by explaining a signal the UI hides. Slightly narrative in tone but no wasted clauses.

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 carries the return-value burden and does so well by naming the fields returned. The remaining gap is operational detail (pagination, sitemap_index scope), which is minor for a simple read.

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 site, account, and sitemap_index are already fully documented in the schema, including the 403 warning about property shapes. The description adds no parameter-level meaning, so the 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?

States a specific verb (list) and resource (every sitemap submitted for a property), and the plural scope clearly separates it from get_sitemap, submit_sitemap, and delete_sitemap. An agent can tell what it returns without opening the 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?

Usage is only implied: it frames the tool as a monitoring surface (stale sitemaps 'show up here'), but never states when to choose it over get_sitemap or that sitemap_index narrows the listing. No explicit when/when-not or alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: the permission levels it returns and the trailing-slash / sc-domain: mismatch that manifests as a permissions error, which is a non-obvious behavioral trap. No pagination or volume notes, hence 4 not 5.

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

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

Three sentences, no filler, front-loaded with what is returned and what the caller should do with it. The gotcha sentence earns its place by preventing a real failure mode.

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

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

There is no output schema, and the description compensates by describing the return shape (properties plus permission level) and the exact format of the returned siteUrl strings. For a single-optional-parameter read tool, nothing an agent needs to call it correctly 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 the single account parameter is fully documented in the schema (including the pointer to list_accounts). The description adds nothing about parameter semantics, so the 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?

States a specific verb+resource (every Search Console property this account can reach) and goes further by naming what is returned (permission level) and the exact enum values. It is clearly distinguishable from siblings like get_site, add_site and list_accounts, so an agent can pick it without opening a schema.

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

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

"Start here" and the statement that its siteUrl strings are the exact values every other tool wants gives clear sequencing guidance relative to siblings. It stops short of explicit when-not conditions or naming a competing alternative, so it is strong context rather than a full decision rule.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint), so the bar is lower. The description still adds real context beyond them: the result set spans all Google products rather than only Search Console, which is a scope trait an agent would otherwise not know.

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 short sentences with purpose front-loaded. Sentences two and three slightly overlap in motivating the tool's distinctness, but nothing is padding or restated boilerplate.

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-required-parameter read tool with annotations and no output schema, the description covers purpose, scope breadth, and the sibling decision. The only gap is that it doesn't hint at the shape of the returned entries (e.g., domain vs product fields), which is minor 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 coverage is 100% and the single 'account' parameter is fully documented in the schema, including the guidance to call list_accounts. The description adds no parameter detail of its own, so the 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?

Names a specific resource (every site and domain the signed-in Google account has verified ownership of) and its broadening scope across all Google products. It explicitly distinguishes itself from the sibling list_sites, so an agent can route between them without opening either schema.

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

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

States the exact condition that selects this tool ('tell "not verified yet" apart from "verified but never added"') and names the narrower alternative (list_sites) with the reason a verified domain may not be a Search Console property. When-to-use and sibling routing are both explicit.

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: a two-to-three day finalisation lag that makes a window ending today look short, and Google's privacy withholding of rare queries that makes the query breakdown sum to fewer clicks than the site total. It stops short of rate limits or per-account auth caveats, so it is strong but not exhaustive.

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 load-bearing: capability, routing, then two caveats framed as 'things to know before reading a result as bad news'. The most decision-relevant content is front-loaded and nothing is padding.

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 usefully names the returned metrics and grouping, and covers the two traps that would cause misreading of results. For an 11-parameter tool it is close to complete, though it says nothing about pagination behaviour or response envelope shape, which an agent may need when paging past row_limit.

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

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

Schema description coverage is 91%, so the schema already documents site shapes, type surfaces, data_state, row_limit and dimensions, including the discover/googleNews caveat. The description's dimension list largely restates the enum rather than adding syntax or format detail, so the baseline 3 for schema-driven params 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?

Opens with a specific verb+resource and enumerates exactly what is returned (clicks, impressions, CTR, average position) and the group-by dimensions available. It also explicitly positions itself against named siblings, so an agent can distinguish it from top_queries, top_pages, striking_distance and compare_periods without opening any 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?

States this is the 'full-control tool' and then routes the agent by name: for the common questions, top_queries, top_pages, striking_distance and compare_periods are one call instead of a hand-assembled body. That is explicit when-to-use-this vs when-to-use-alternatives guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds the meaningful behavioral trait that results are ordered by opportunity rather than raw volume, but omits pagination, result shape, and any auth/rate considerations beyond what the schema states.

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

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

Three sentences, front-loaded with the core definition before justification. The closing line ('The single most useful report in Search Console and the UI makes you build it by hand every time') is a value pitch that adds little operational information, though it is brief.

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 analytics query with no output schema, the description conveys what is returned (queries in a positional band ordered by available impressions) and the default window, which is what an agent needs to call it correctly. It stops short of describing the limit/days interaction or pagination, leaving minor gaps.

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

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

Schema coverage is only 43%, so the description should compensate more than it does. It does clarify the position band semantics ('between positions 5 and 20 by default') that maps to min_position/max_position and explains why results are ordered, but days, limit, account and min_impressions get no elaboration beyond defaults already visible 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?

States a specific verb (queries) and resource (queries a property already ranks for, positions 5-20) plus the ordering rule (impressions left on the table). This is clearly distinct from siblings like top_queries or query_search_analytics, which lack the positional band constraint.

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

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

Gives clear context for when to use it ('where a title rewrite or added depth moves traffic, because the ranking work is already done'), which is actionable usage guidance. It does not, however, name an alternative tool or state when NOT to use it versus query_search_analytics/top_queries.

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 idempotent, non-destructive, open-world, non-read-only, but the description adds behavior they cannot express: the call returns immediately, Google fetches on its own schedule, and no counts are available here. That async/no-result-here disclosure is exactly the extra context an agent needs and is not duplicated from structured fields.

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

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

Four short sentences, front-loaded with the action, then the recrawl rationale, then the timing caveat and the read-back pointer. No filler and each sentence carries distinct information.

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

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

With no output schema, the description compensates by explaining that the call returns immediately and that results must be read via get_sitemap, which is the key thing an agent would otherwise get wrong. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the schema descriptions are richer than anything the tool text provides (property string shapes, 403 risk, account selection). The description adds no parameter-level meaning, so the 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?

States a specific verb and resource ('Submit or resubmit a sitemap') and immediately distinguishes it from the read-side sibling by naming get_sitemap as the way to check results. An agent can tell it apart from list_sitemaps/delete_sitemap/get_sitemap without opening a schema.

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

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

Gives a concrete trigger ('resubmitting after publishing is the programmatic equivalent' of Request indexing) and routes the agent to get_sitemap for the outcome. It stops short of stating explicit exclusions or prerequisites, but the context is clear enough to select the tool confidently.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still contributes a non-obvious behavioral fact — the data lag ('ending three days ago') — which the agent needs to interpret freshness correctly, though it says nothing about pagination, rate limits, or how limit interacts with large result sets.

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 front-loads what is returned, the second front-loads the default time window. Nothing is repeated from the title or annotations.

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

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

For a 7-parameter analytics tool with no output schema, the description does list the returned measures, which partially substitutes for a return schema. However, it omits how limit/pagination behaves, how this differs from query_search_analytics or top_queries, and any prerequisite such as needing a verified property, leaving meaningful gaps.

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

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

Schema coverage is 71%, so the schema already documents site, type, account, country, and query_filter, including the 403 warning for mismatched property shapes and the error behavior for discover/googleNews. The description only adds semantics for the date window (days default 28, ending three days ago) and leaves limit entirely undocumented in both places, so it compensates only partially.

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

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

Names a specific resource (pages on a property) and the ranking metric (most clicks from Google Search), plus the returned measures (impressions, CTR, average position). An agent can distinguish this from the sibling top_queries without opening either schema, since one ranks pages and the other ranks queries.

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

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

The description states the default reporting window ('last 28 days ending three days ago'), which is useful context, but gives no explicit when-to-use or when-not-to-use guidance against alternatives such as top_queries, compare_periods, or query_search_analytics. Usage is implied by the resource name rather than stated.

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

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

Annotations already declare the safe read-only/idempotent profile, and the description adds genuinely useful behavioral context beyond them: the default window ends three days ago because Search Console lags and a window ending today reads as empty. It stops short of covering pagination or rate-limit 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 sentences, zero filler, with the metric list front-loaded and the default-window caveat immediately following. Every clause carries information.

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

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

For a 7-parameter read tool with no output schema, the description usefully enumerates returned metrics (impressions, CTR, average position) and explains the default window. The main gap is the absence of routing guidance versus overlapping siblings, but the parameter and return picture is otherwise 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 86%, so the schema already documents parameters richly (site, type, account, page_filter, country all have detailed descriptions). The description only adds the default-window rationale for 'days', which is marginal over 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?

States a specific verb and resource ('search queries bringing the most clicks to a property') and enumerates the returned metrics. It implicitly distinguishes itself from the sibling top_pages by operating on queries rather than pages, but it never explicitly names or contrasts with alternatives like 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 the default window rationale but gives no guidance on when to choose this tool over siblings such as top_pages or query_search_analytics, nor any exclusions or prerequisites. The agent must infer usage purely from the resource name.

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

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

Annotations already cover safety (idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description adds real value by disclosing the failure mode (fails until the token is reachable) and the expected delay for DNS propagation. It does not describe error/return shape or rate limits, so not a 5.

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

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

Three short sentences, front-loaded with the action and its prerequisite, then failure/timing behavior. 'Retrying is safe' slightly duplicates the idempotentHint annotation, but overall it is tight and every sentence carries weight.

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

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

Covers the prerequisite, external side effect (Google fetches and marks ownership), and the timing/failure behavior an agent needs, with parameters fully documented in the schema and no output schema to explain. It lacks only error-surface detail (what a failed verification returns).

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%, including inline docs for type, method, identifier and account, and enum values are documented. The description adds no parameter-level detail beyond the schema, so the 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?

States a concrete verb+resource (claim ownership of a site via verification) and explicitly ties it to the token produced by the sibling get_verification_token, distinguishing it from list_verified_sites. An agent knows exactly what this does without opening the 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?

Gives a clear precondition (run only once the token is live), names the sibling that mints the token, and warns that DNS verification requires waiting for propagation before retrying. It also states retrying is safe, which resolves the main agent doubt for this call.

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