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

Annotations already declare readOnly=false, idempotent=true, destructive=false, and openWorld=true, so the safety profile is covered. The description adds a behavioral constraint those annotations cannot express: the site must already be verified, making the call contingent on a prior step. It does not describe failure modes for an unverified site, keeping it out of the 5 band.

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

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

Two sentences, no filler, with the core action and its prerequisite both front-loaded. 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?

For a single-parameter mutation with full schema coverage, an output schema absent, and annotations covering the safety profile, the description supplies the one missing piece (the verify_site prerequisite). Only a note about error behavior for unverified sites would make it fully complete.

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

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

Schema coverage is 100% and the 'site' property description already carries the format examples (URL-prefix vs. sc-domain). The tool description adds no parameter meaning beyond that, so the baseline 3 for fully-documented schemas 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 ('Adds a VERIFIED site to Search Console'), includes the underlying API method (sites.add), and the 'VERIFIED' qualifier scopes it against the sibling verify_site. An agent can tell this is the registration step that follows verification rather than a sibling like list_sites or setup_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?

'Run verify_site first' gives an explicit prerequisite and ordering against a named sibling, which is strong when-to-use guidance. It stops short of stating when NOT to use it or what to do on failure, so it falls just below the top band.

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

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

Adds substantial behavior beyond the annotations: the call returns immediately with a consent URL rather than blocking, consent must be granted on the same machine (loopback 127.0.0.1 constraint), and the refresh token is persisted in the OS config dir with 0600 permissions. This is exactly the auth-sensitive context an agent cannot get from openWorldHint alone, and it does not conflict with the annotations.

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

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

Four short, front-loaded sentences that each carry distinct load: mechanism, return behavior, next step, and side effect. No restatement of the tool name or 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 one-parameter flow tool with no output schema, the description covers what is returned (consent URL), what the agent should do next (poll auth_status), and where credentials land. The only omission is any explanation of timeoutSeconds, which is the sole remaining hole.

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

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

Schema description coverage is 0% and the single parameter timeoutSeconds is never mentioned in the description, so its units, default, or effect are undocumented anywhere. The description compensates richly on behavior but not on parameters, leaving a genuine gap for the one input an agent must supply.

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 (one-time Google OAuth login via loopback on 127.0.0.1) and its immediate effect (returns a consent URL). It also differentiates from siblings by naming auth_status as the polling counterpart, so an agent can route between them 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 clear operating context: 'one-time', 'the owner opens it in a browser on THIS machine', and 'Poll auth_status until ready'. The 'one-time' qualifier implies this should not be re-run routinely, but there is no explicit when-not guidance or statement of prerequisites/failure handling.

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 only annotation is readOnlyHint=false, which just confirms this is a mutation; the description goes further by disclosing exactly what is destroyed (the stored refresh token) and where it lives (this machine). It does not say whether server-side sessions are also revoked or whether authentication is required, but for a minimal-annotation tool this adds real behavioral value.

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

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

A single sentence with zero filler, front-loading the action and its object. Nothing could be removed without losing meaning.

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

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

For a no-parameter, no-output-schema tool, the description covers the essential effect and its local scope. The only residual gap is the post-condition (whether the server session is invalidated or a re-login is required), which is minor here.

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 and there is nothing for the description to disambiguate. No parameter-level information is needed or missing.

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

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

The description names a specific verb (deletes) and resource (stored refresh token) plus a scope qualifier (from this machine), so an agent can distinguish it from auth_login and auth_status. It stops short of explicitly contrasting itself with those siblings, which keeps it at 4 rather than 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named (e.g., how to re-authenticate afterward). The effect described implies a logout scenario, but the agent must infer the trigger condition entirely.

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

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

Annotations already mark this readOnlyHint=true and openWorldHint=true, so safety and external-call context are covered. The description adds a genuine disclosure beyond them — 'Never returns secrets' — though it says nothing about latency or whether the check performs a live network round-trip.

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 tightly packed sentence covering three questions (signed in?, which mode?, what next?) plus a security guarantee, 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?

No output schema exists, and the description does name the content of the reply — sign-in state, mode, and remediation guidance — which is the essential return information. It could say more about the shape of those fields, but for a zero-parameter status tool this is close to 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?

The schema declares zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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 query: whether site-indexer is signed in to Google, plus the auth mode, and it distinguishes itself from siblings auth_login/auth_logout by being purely a status read. An agent can pick this over the login/logout tools 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?

The phrase 'what to do if not' implies the tool's value in a remediation flow and hints you'd check state before calling auth_login, but no explicit when-to-use or when-not-to-use condition or alternative tool is named.

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 and openWorldHint, so the safety profile is covered; the description adds genuine context beyond them by explaining that it hits the live site rather than Google and by naming failure modes (wrong host, HTML fallback). It omits auth requirements and any rate-limit/timeout 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?

A single front-loaded sentence that packs purpose, scope, and the kinds of problems reported with no filler. Nothing can be trimmed without losing information.

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

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

With no output schema, the description usefully summarizes the return shape (URL count, sample URLs, detected problems), and annotations cover the read-only/open-world profile. Only the undocumented required parameter and auth expectations keep it short of complete.

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

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

Schema coverage is only 50% — 'site' is documented but the required 'sitemapUrl' has no description — and the description never mentions either parameter. It also doesn't clarify the relationship between the required sitemapUrl and the optional site property, leaving the caller to infer 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 verb+resource ('fetches a sitemap from the live site') and scopes it with 'no Google call', which separates it from the Google-API siblings like list_sitemaps, submit_sitemap and inspect_url. It does not name an alternative outright, so differentiation is implied rather than explicit.

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

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

The parenthetical 'no Google call' hints at when this tool is preferable (direct-site inspection without API quota), but there is no explicit when-to-use versus list_sitemaps/inspect_url guidance or prerequisite statement. Usage is implied 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 cover the safety profile (writes, idempotent, open-world, non-destructive), so the description's added detail is what matters: it names the required credentials (NETLIFY_AUTH_TOKEN, CLOUDFLARE_API_TOKEN) and that the record is created in an external DNS provider. 'Skips if it already exists' usefully corroborates idempotentHint, though no failure/rollback behavior is described.

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

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

Two dense sentences with the scoping constraint front-loaded and no filler; every clause carries information. The 'For sc-domain: properties:' opener is slightly awkward but does its job.

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

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

For a 3-parameter external-write tool with annotations and no output schema, the description covers scope, credentials, provider selection and idempotency. What it omits — error handling and what the call returns — is minor since annotations already signal the write/idempotent profile.

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

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

Schema coverage is only 33% — 'method' and 'provider' enums have no schema descriptions — and the description compensates by explaining what the method produces (TXT or CNAME record) and that provider maps to Netlify vs Cloudflare with distinct tokens. This meaningfully fills the documentation gap the schema leaves open.

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

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

States a specific verb+resource ('fetches the DNS token and creates the TXT (or CNAME) record') and scopes it to sc-domain properties, which separates it from the sibling get_verification_token that only retrieves a token. It does not name any sibling explicitly, so it stops short of the top score.

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?

'For sc-domain: properties' implies the applicable condition and 'Skips if it already exists' implies safety on re-run, but there is no explicit when-to-use/when-not guidance and no alternative tool is named for URL-prefix properties. Usage must be inferred.

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 and openWorldHint, so the safety profile is covered. The description adds useful context by spelling out the concrete return payload per method and clarifying that it produces a token but performs no verification.

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 dense sentence with the core action front-loaded and the method-to-output mapping following. Every clause earns its place 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?

With no output schema, the description compensates fully by describing exactly what each method returns. Combined with the schema's site/method docs and the read-only annotation, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both params are documented, giving a baseline of 3. The description goes further by mapping each method enum value to its specific output artifact, adding meaning the schema does not provide.

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 (gets the Google Site Verification token) and precisely enumerates what is returned for each method (FILE, META, DNS_TXT/DNS_CNAME). The closing 'Does not verify' cleanly distinguishes it from the verify_site sibling.

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?

'Does not verify' implies the boundary with verify_site, and enumerating per-method outputs tells the agent it must pick a method. However, it never explicitly names the alternative to use when verification is the goal, so the routing is implied 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?

readOnlyHint=true is already declared, and the parenthetical '(or echoes INDEXNOW_KEY)' usefully explains why a 'generate' operation is nonetheless read-only — the value may come from an environment variable. It further discloses the required deployment step (publish the key file at the site root) and the supported engines, which 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?

Two tight sentences with no filler; the artifact produced and the deployment requirement come first, with the engine restriction as a compact qualifier. 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?

With one fully documented parameter and no output schema, the description covers the essentials: what is produced, where it must be published, and which engines honor it. It stops short of explaining idempotency or the relationship to the ping/submission flow, a minor gap for a tool this simple.

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 'site' parameter is documented with three concrete URL/domain formats, so the schema carries the semantics. The description adds no additional meaning about the parameter, which is the baseline-3 case.

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

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

The description names a specific verb and resource ('Generates ... an IndexNow key and the key file') and states where the artifact must go ('to publish at the site root'). It is clearly distinguishable from indexnow_ping and get_verification_token, though it does not name them explicitly.

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

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

The engine scope note ('Bing/Yandex/etc only, not Google') tells the agent when this key is useful, which is real routing value. However, it never says when to call this versus the sibling indexnow_ping, nor whether it must precede submission, leaving the workflow implied 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 readOnlyHint=false and openWorldHint=true, so the agent knows this is a mutating, externally-reaching call. The description adds that submission goes to specific external engines, which is useful, but omits rate limits, auth needs, idempotency, or what a submission result looks like.

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, zero waste, with the core action front-loaded and the Google caveat as a tight follow-up. 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?

No output schema and no rich annotations, so the description must carry the behavioral load. It conveys what the tool does and its external scope, but a mutating network tool typically needs more on auth, limits, or expected outcome, which 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 50%, and the schema documents site and key while leaving urls/sitemapUrl without descriptions. The phrase 'given or from the sitemap' maps loosely to those two params and adds some meaning, but the description does not compensate for the coverage gap at 50%.

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 (submits) and resource (URLs) with a clear target (IndexNow/Bing, Yandex, etc.) and notes the two input modes (given URLs or sitemap). It is distinguishable from most siblings, though it does not explicitly contrast itself with submit_sitemap or indexnow_key.

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 'Google ignores IndexNow' note implies a usage constraint and helps frame relevance, but there is no explicit when-to-use guidance, no when-not-to-use statement, and no routing to alternatives such as submit_sitemap. Usage is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so 'read-only' is partly redundant. The description still earns credit for disclosing a behavioral limitation not captured anywhere else: this tool cannot request indexing. It does not mention quota/rate limits, which the real Search Console URL Inspection API imposes.

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

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

One front-loaded sentence naming the operation, the read-only nature, and the returned fields, followed by a single negative constraint. Every clause earns its place 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?

With no output schema, the description usefully enumerates return fields, partially compensating. But an openWorld read tool with two undocumented parameters and no rate-limit context is only adequately described; the parameter gaps are the main shortfall.

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 33%: site has a description, but url and languageCode have none. The description adds nothing about parameter formats or required combos, so an agent must infer how to supply url and what languageCode does. With low coverage, the description should compensate but does not.

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 (URL Inspection) and names the fields returned (verdict, coverage state, last crawl, canonical), so an agent knows exactly what comes back. It does not explicitly distinguish itself from the plural sibling inspect_urls, which is the one remaining ambiguity.

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 exclusion 'Does NOT request indexing (no public API exists for that)' is genuinely useful routing guidance, steering agents away from using this for indexing requests. However it never names an alternative (e.g. inspect_urls for batch, or indexnow_ping for submission), so when-to-use is only implied.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely non-structured information: the quota of ~2,000 inspections/day and 600/min per property, plus the fact that it will read the live sitemap. It stops short of describing failure behavior for unreachable or non-indexable URLs.

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

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

Two sentences, no filler, with the core behavior first and the operational quota second. Every clause carries 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?

There is no output schema, so the description carries the burden of explaining returns; 'summarises how many are indexed' hints at a count but does not say whether per-URL results are returned or how partial failures are reported. Combined with 4 parameters and no usage guidance, the definition is adequate but incomplete.

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

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

Schema description coverage is 75%, so the baseline is 3. The description's 'given, or read from the live sitemap' restates the urls/fromSitemap relationship that the schema already documents, and it says nothing about the limit parameter or the 100-item cap.

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 ('inspects many URLs'), the two input sources (given URLs or live sitemap), and the output intent ('summarises how many are indexed'). The plural 'many URLs' implicitly separates it from the singular sibling inspect_url, but it never names that sibling, so the distinction is left to inference.

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

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

No explicit when-to-use guidance and no alternative is named. An agent must infer from the word 'many' that inspect_url handles the single-URL case, and nothing indicates whether this is preferred over check_sitemap for bulk index checks.

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?

OpenWorldHint and readOnlyHint already declare that this is a safe, far-reaching read operation, so the annotation bar is lower. The description usefully discloses the return payload (last download, errors, warnings, submitted counts). It does not add anything about auth requirements or pagination, so a 3 is appropriate.

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

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

A single front-loaded sentence with no filler, and the scoping 'for a property' arrives before the return-field listing. 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?

With no output schema, the description carries the burden of describing returns, and it names the four key fields. That, combined with the rich parameter schema and read-only annotations, is nearly complete; only auth/prerequisite context 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%, so the schema already documents the single 'site' parameter in detail, including URL-prefix and sc-domain formats. The description only echoes 'for a property' and adds no format or syntax meaning beyond the schema, matching the baseline for high coverage.

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

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

The description names a specific resource (sitemaps in Search Console) scoped to a property, and enumerates the returned fields, which distinguishes it from the other sitemap siblings (check_sitemap, submit_sitemap). It lacks an explicit listing verb, but the intent is unmistakable. Sibling differentiation is implicit rather than stated.

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

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

There is no guidance on when to use this tool versus check_sitemap, submit_sitemap, or inspect_url. No prerequisites (auth requirements) or exclusions are mentioned. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that results are scoped to the signed-in account and include permission level, which is useful context, but says nothing about pagination, ordering, or result size.

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 clause with no filler, and the account-scoping constraint is front-loaded where it matters.

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 no-argument, read-only listing tool with annotations covering the safety profile, the description supplies the account scope and the notable 'permission level' field. Only minor gaps remain, such as whether results are paginated or filtered.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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 resource ('Search Console properties') and implicitly the list operation, and clarifies the scope as 'for the signed-in account.' It is clear but does not differentiate itself from siblings such as add_site or verify_site, which operate on the same 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., add_site for creating a property). The phrase 'for the signed-in account' hints at an auth precondition but never states it as one.

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 idempotentHint=true, readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description still adds real value beyond that: it explains the stop-on-first-blocker behavior and the returned nextAction payload, which the agent needs to resume the deploy cycle.

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: the first front-loads the loop scope, the second explains the stopping behavior, return value, and re-invocation rule. No filler; 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?

For a complex multi-step orchestrator with no output schema and five parameters, the description covers the flow, the stop condition, and the response shape (nextAction). It is largely complete, missing only explicit guidance on when to prefer the individual step 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 80%, with site, method, dnsProvider, and maxWaitSeconds all documented in the schema itself. The description adds nothing about parameters, so baseline 3 is appropriate when the schema does nearly all the work.

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 orchestration purpose (the whole auth -> verification -> add -> sitemap -> inspection loop) with the verb 'runs', and the multi-step scope visibly distinguishes it from the single-step siblings like verify_site and submit_sitemap. An agent can identify 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 invocation pattern ('Call again after each deploy') and clarifies the loop halts at the first action-needed step, which tells the agent how to interact with it. It does not explicitly contrast against using the individual sibling tools or state when NOT to use this composite.

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 mutation/is-idempotency/open-world profile, so the description only needs to add context. It does add the probe-before-submit behavior and the fact that Google's status is returned, but says nothing about failure behavior (e.g., what happens if the sitemap probe fails) or auth requirements.

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

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

A single dense sentence with the action, default, and return value all front-loaded; 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 2-parameter mutation tool with annotations covering safety and no output schema, the description supplies the default path and return content. It stops short of covering auth prerequisites or error behavior, which is a minor gap given the sibling auth_* 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 coverage is 50% and sitemapUrl has no schema description at all; the description compensates by stating the default value '<site>/sitemap.xml', which explains that parameter's optionality and semantics. The 'site' parameter is already well documented 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 and resource ('submits a sitemap to Search Console'), plus the extra probe step and the returned artifact ('Google's sitemap status'). It is distinguishable from check_sitemap/list_sitemaps, though it never explicitly contrasts itself with those 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 only implied: 'probes then submits' signals it is the write-side counterpart to the read-only sitemap tools, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of prerequisites such as being authenticated first.

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

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

Annotations cover the safety profile (idempotentHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely new context: retry-with-backoff behavior for deploy/DNS propagation and the alreadyVerified return path. It stops short of stating auth requirements or the full return shape.

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 zero filler, front-loading the two-phase flow and then the idempotency guarantee. Every clause 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 usefully discloses the alreadyVerified return value, and annotations carry the external/mutation profile. It is largely complete for a 4-param tool, though it omits any mention of auth prerequisites that a verify call against Google might need.

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 four parameters are already documented in the schema, including method enum defaults and skipPrecheck. The description's mention of file/meta/DNS and the precheck concept mirrors rather than extends 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 specific verb (verify) and resource (site ownership), and the two-phase mechanism (local token check, then Google verification) clearly separates it from siblings like get_verification_token (which only fetches the token) and add_site. An agent can identify the operation 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?

The description makes the prerequisite implicit but clear: a token must already be live locally before this runs, which routes the agent away from using it before setup. However, it does not explicitly name add_site/setup_site as the preceding steps or state when-not to use it.

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