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

Annotations already mark readOnlyHint=false and idempotentHint=true, but the description adds critical behavioral context: the resulting property may be unverified and all data calls will return 403. This failure-mode disclosure goes beyond what annotations provide.

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

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

Two sentences with no wasted words. The key caveat (no ownership verification) is front-loaded, and the alternative tool is named explicitly.

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 tool with an output schema and annotations covering safety and idempotency, the description provides all necessary context for correct selection and invocation. It fills the one important gap—ownership verification—and points to the correct full workflow.

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 description itself does not elaborate on site_url, but the input schema documents it 100% including accepted formats and the GSC_SITE_URL fallback behavior. With high schema description coverage, a baseline of 3 is appropriate; the description neither adds nor contradicts parameter meaning.

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

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

The description states a specific verb and resource ('Adds a property to Search Console') and immediately distinguishes itself from the sibling setup_site by emphasizing this tool does NOT verify ownership. This makes the tool's role clear relative to its siblings.

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

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

The description gives explicit when-to-use guidance: 'To actually get a working property, use setup_site' and lists the correct order of tools. It also states the consequence of standalone use (siteUnverifiedUser, 403 errors), making exclusion conditions clear.

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

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

The description adds significant behavioral detail beyond the annotations: the first call returns a confirmation token and the second performs the removal. This is critical for an agent to invoke the tool correctly and complements the destructiveHint and idempotentHint annotations without contradiction.

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

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

Two concise sentences convey the core purpose and the crucial two-step workflow without waste. The most important behavioral nuance is front-loaded and clearly structured.

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

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

The description is complete for a destructive two-step tool: it states the action, the token workflow, and is supported by rich parameter schema, output schema, and annotations covering safety and idempotency. No critical calling information is missing.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description's two-step mention reinforces the role of confirm_token but does not add substantial meaning beyond what the schema already states.

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

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

The description uses a specific verb ('Removes') and resource ('a property from Search Console'), clearly distinguishing it from sibling delete_sitemap. The two-step behavior is also stated, making the tool's function unambiguous.

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

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

The description provides clear context for when to use this tool: when removing a Search Console property. It also gives essential procedural guidance about the two-step confirmation flow, though it does not explicitly reference sibling alternatives or exclusion conditions.

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

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

Annotations already establish destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds valuable non-obvious behavior beyond those annotations: the tool does not delete immediately and instead requires a two-step confirmation flow. The confirm_token schema text adds token semantics ('previous refusal', 'cannot be guessed or reused') that meaningfully explain the safety mechanism.

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 zero waste. The primary purpose is front-loaded, and the critical two-step caveat immediately follows so the agent is warned before invoking. Every word earns its place.

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

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

For a moderately complex destructive tool, the essential non-obvious behavior (two-step confirmation) is disclosed, all three parameters are thoroughly documented in the schema, annotations cover destructiveness and idempotency, and an output schema exists so return values need not be described. Slight gap: no explicit statement about what happens on the first call's outcome beyond receiving a token, but the parameter description covers this adequately.

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 carries the full load: feedpath, site_url with exact format examples and the trailing-slash rule, and confirm_token with its workflow. The main description adds the two-step context that motivates confirm_token's existence, but the schema already explains this parameter's purpose in detail. Baseline 3 is appropriate since 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?

The description uses a specific verb and resource: 'Removes a sitemap from the property.' This clearly differentiates it from the sibling delete_site (removes a site, not a sitemap) and from submit_sitemap/list_sitemaps/get_sitemap, which operate on sitemaps in different ways. The two-step flow detail further pins down what the tool does.

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

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

The description gives clear procedural guidance for how to invoke the tool correctly: call once to receive a confirmation token, then again to perform removal. The confirm_token parameter description reinforces this ('Call without it first to see what would happen and receive the token'). However, it does not explicitly name alternatives or state when-not-to-use conditions relative to siblings like delete_site or submit_sitemap.

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

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

Annotations already mark this as read-only and idempotent, so the description correctly aligns with those. It adds genuinely useful behavioral context: the credential must be a verified owner, Search Console user access is insufficient, and a 403 error does not distinguish which requirement is missing. This goes well beyond the structured annotations.

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

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

Three sentences, each earning its place: the primary return value, the scope limitation, and the authentication requirement. The most important detail is front-loaded, and there is no redundant or vague phrasing.

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, read-only tool with an output schema and rich annotations, the description is fully sufficient. It explains what the tool reports, what it does not report, how to answer the excluded question, and the credential requirements needed for a successful call.

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

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

The single parameter url is described in the schema with 100% coverage, so the description does not need to add much. It does reinforce that the URL is used for notification history lookup, but it adds no extra format or interpretation details beyond the schema.

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

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

The description states a very specific verb and resource: it returns the last notification time and type for a URL through the Indexing API. It further differentiates itself by clarifying that it does not report indexing status, and explicitly names inspect_url as the sibling that answers that question.

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

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

The description clearly tells the agent when this tool is appropriate: when checking notification history for a credential. It also explicitly redirects to inspect_url when the question is about page indexing, and it specifies the ownership prerequisite, which is a vital usage constraint.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the non-obvious fact that the two property spellings are separate properties holding separate data, which is useful. It does not describe return format or error behavior, but the output schema covers return values.

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 core operation is front-loaded, followed by the use case and the key caveat. Every sentence contributes essential 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 single-parameter, read-only tool with a complete input schema and an output schema, the description is sufficiently complete. It conveys the key caveat about property spellings and the permission-level return. A minor gap is the absence of alternative tool names, but the low complexity makes this a non-critical omission.

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 already documents site_url, including the two spellings and the trailing-slash requirement. The description adds semantic value by explaining why the choice matters: the two spellings are separate properties holding separate data. This is meaning beyond the schema.

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

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

States a specific verb and resource: 'Returns one property and the permission level this credential has on it.' The singular 'one property' clearly distinguishes it from list_sites, but it does not explicitly differentiate it from sibling get_verified_site, so sibling distinction is only partial.

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

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

Provides a concrete use case: 'Useful for settling which of the two spellings exists.' This gives clear contextual guidance on when to call this tool. It does not state exclusions or name alternative tools, so it stops short of full when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by disclosing that this is the place to see submission errors and that submit_sitemap's response will not contain them. This goes beyond the annotations and helps the agent set expectations.

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

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

The description is just two sentences with no waste. The main action and resource are front-loaded, and each sentence contributes useful information: the return payload and the core use case. This is a model of concise, effective description.

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

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

The tool has only 2 parameters, both fully documented in the schema, and an output schema exists. The description adds the missing behavioral intent: use it to verify a submission. Nothing essential for correct invocation is missing, and annotations cover side effects, so the description is complete for this context.

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

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

Schema description coverage is 100%, so both site_url and feedpath are already well documented in the schema. The description does not add any additional parameter-specific meaning; it only mentions the returned record fields. With complete schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's verb ('Returns') and resource ('full record for a single submitted sitemap'), enumerating the specific fields included. It also distinguishes itself from submit_sitemap by noting that errors appear here and never in submit_sitemap's response, which helps the agent distinguish it from a 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?

The description gives an explicit when-to-use scenario: 'This is how to check whether a submission actually worked.' It also contrasts with submit_sitemap, telling the agent that errors are not visible there. However, it does not provide an explicit when-not-to-use for other siblings like list_sitemaps, so it stops short of a perfect 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?

Even though annotations already declare readOnlyHint and idempotentHint, the description adds valuable behavioral context: nothing is created or claimed, running it against a domain you do not own is safe but pointless, and the token placement is a human step. It also explains why certain verification methods have no token to fetch.

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

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

The description is tightly written in three short paragraphs, with the core purpose front-loaded in the first sentence. Every sentence contributes either a constraint, a clarification, or a next-step instruction, 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 that an output schema exists, the description does not need to explain return values. It covers what the tool returns, where to place the token, property-type constraints, method availability, and the relationship to verify_site, making it complete for an agent to use 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 meaning beyond the schema by explaining which method applies to which property kind and that method defaults to the sensible one. The site_url format is already well covered by the schema, so the description does not need to repeat 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?

The description states a specific verb and resource: it returns the token that proves site ownership and tells where to place it. It also explicitly distinguishes itself from verify_site, which is the sibling that performs the actual verification.

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

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

The description gives explicit when-to-use guidance by property type: DNS for domain properties, FILE or META for URL-prefix properties, and no token for ANALYTICS or TAG_MANAGER. It also directs the agent to call verify_site after the token is placed, clearly identifying the alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that owner emails are included, which is helpful, but it does not disclose failure behavior or permission requirements; with annotations present this is acceptable but not outstanding.

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

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

The description is one short sentence that front-loads the action and the resource with no filler. Every word contributes 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 one-parameter, read-only getter with a full output schema and complete annotations, the description is enough: it states what is returned and the schema defines exactly how to pass the id. No critical invocation detail is missing.

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

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

The tool description says nothing about the id parameter, but the schema covers it completely (100%) by explaining its source, its opaque nature, and examples. With full schema coverage, the baseline of 3 applies; the description contributes no extra parameter meaning.

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 concrete action ('Returns') and a specific resource ('one verified site'), and it adds the owner-email detail, which distinguishes it from a generic site fetch. It does not explicitly contrast with get_site, so it stops short of full sibling differentiation.

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

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

The description implies this is the tool for retrieving a single verified site, but it gives no explicit when-to-use or when-not-to-use guidance and does not route between get_verified_site and get_site. The useful provenance hint ('as returned by list_verified_sites') lives in the schema, not in the tool 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 mark the tool as read-only, idempotent, and non-destructive, but the description adds substantial behavioral context beyond them: it reports cached Google state rather than a live fetch, and it discloses the exact API budget (2000 calls per property per day, 600 per minute) including the consequence that spending the budget blocks inspection for the rest of the day.

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

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

The description is dense but every sentence adds value. The core purpose is front-loaded in the first sentence, followed by the critical live-fetch caveat and then the budget constraints. No filler or redundant restating of the title or schema is present.

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 output schema exists and the annotations cover safety, the description is remarkably complete: it explains the operational semantics, the data source, the budget limits, and the key non-obvious behavior that results may be stale. An agent has enough context to invoke it correctly and interpret its results appropriately.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters with useful details like the trailing-slash requirement for URL-prefix properties and BCP-47 language codes. The description does not add parameter-specific semantics, but it does not need to because the schema carries the burden.

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

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

The description starts with a specific verb and resource: 'Asks Google what it knows about one URL' and enumerates the exact inspections performed (indexed state, last crawl, sitemaps, canonical, robots, mobile usability, rich-result problems). It clearly distinguishes itself from the sibling inspect_urls by emphasizing 'one URL' and from request_indexing by stating it reports indexed state rather than triggering a fetch.

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

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

The description provides clear context for when to use this tool: when you need Google's indexed view of a URL, explicitly noting it is 'not a live fetch.' It does not explicitly name alternatives or state when not to use it, but the 'indexed state, not a live fetch' caveat conveys the key selection criterion.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful behavior: the API has no batch method and calls are made sequentially, one failure does not abort the rest, the result is condensed, and the daily budget is not a rate limit but can block later inspections. This goes well beyond what annotations already convey.

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

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

The description is compact and front-loaded: the first sentence states the core purpose, the second clarifies execution behavior, and the final sentence covers quota semantics. Every sentence earns its place with 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?

Given that an output schema exists and annotations cover safety, the description adequately covers the remaining operational context: sequential execution, partial failure behavior, condensed output, and quota consequences. Nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and the input schema already documents site_url format, language_code, and inspection_urls constraints. The description adds only the 'up to 20 URLs' and 'one property' constraints, which are already present in the schema, so it provides no substantial additional parameter meaning.

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

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

The description states a specific verb ('Inspects'), the resource ('URLs of one property'), and the scope (up to 20 URLs in a single call, per-URL verdict). It also distinguishes itself from the sibling inspect_url by noting it returns condensed verdicts rather than full reports.

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

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

The description gives explicit guidance on when to use this tool versus inspect_url: use inspect_url for the full report on a single URL, and inspect_urls for condensed verdicts across multiple URLs. It also provides actionable context about the daily budget and its blocking effect.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: listing is passive, Google re-crawls on its own schedule, nothing can force it, and the old ping endpoint is gone. This prevents an agent from expecting or attempting side effects and clarifies the meaning of the status information returned. No contradiction with annotations.

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

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

The first sentence is front-loaded and delivers the core purpose. The second and third sentences add useful related context about idempotent submission and crawl scheduling, but they are slightly tangential to the listing operation itself and could arguably live in the submit_sitemap description. Still, the text is compact and free of 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?

The description is complete for a read-only listing tool. It explains what is listed, what details are included, and sets expectations about recrawl behavior. With full schema coverage, an output schema present, and annotations already covering safety and idempotency, nothing essential is missing.

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

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

Schema description coverage is 100%, and both site_url and sitemap_index already have clear, detailed descriptions. The tool description does not add extra parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists sitemaps submitted for a property and enumerates the key returned details (last download time, URL counts per content type, warnings/errors). It distinguishes this from sibling operations like submit_sitemap or get_sitemap by emphasizing the list/submitted scope.

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

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

The description provides clear context for when this tool is relevant: when you need to see submitted sitemaps and their processing status. It also implicitly steers agents away from trying to force a recrawl or find a separate update call, mentioning that submission is idempotent and Google controls the crawl schedule. It does not explicitly name alternative sibling tools, but the guidance is sufficient.

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

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

The annotations already convey read-only, idempotent, non-destructive behavior, and the description adds meaningful context beyond them: permissionLevel meanings, the unverified-property state, and that data calls for unverified properties return 403. This helps the agent understand real-world behavior without contradicting 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?

Every sentence earns its place: the first sets scope and output, the second gives a diagnostic trigger, and the third defines permission levels. The most important usage guidance is front-loaded, and there is no filler or repetition of schema details.

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

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

With no parameters, no required input, and an output schema already present, the description fully covers what an agent needs to call this tool correctly. It explains the output semantics, edge cases, and the recommended diagnostic workflow, leaving no obvious 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?

The tool has zero parameters, so the baseline for this dimension is 4. The description cannot add parameter-level semantics, but it enriches the meaning of the permissionLevel values that appear in the output, which is useful context.

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

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

The description states a specific verb and resource: lists every Search Console property the credential can see, with the permission level on each. It clearly differentiates from siblings like list_verified_sites by explicitly including unverified properties and by focusing on what the credential can access.

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

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

Provides a strong, concrete trigger: the first call to make when anything returns 403. It also tells the agent how to interpret an empty list for fresh service accounts, but it does not explicitly name sibling alternatives or state when not to use this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the list is scoped to verified ownership, includes the full owner list per site, and is semantically distinct from property membership. No contradictions with annotations.

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

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

Three sentences, all substantive: the first states the core function, the second resolves the most likely confusion with list_sites, and the third adds useful cross-tool context. No filler or redundancy.

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

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

With zero parameters and an output schema present, the description fully covers what an agent needs to decide when to call this tool: the exact list scope, the owner list detail, and the distinction from list_sites. The setup_site reference further completes the contextual picture.

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

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

The input schema has zero parameters, so there is no parameter ambiguity. Baseline for zero-parameter tools is 4; the description correctly focuses on what the tool returns rather than inventing parameters to explain.

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

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

The description uses a specific verb ('Lists') and clearly identifies the resource: every site this credential has verified ownership of. It explicitly distinguishes itself from list_sites, so an agent can tell them apart without inspecting schemas.

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

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

The description explicitly contrasts list_verified_sites with list_sites: list_sites returns Search Console properties, while this returns proven ownership, and a site may be in either list independently. It also notes that setup_site compares the two, giving the agent concrete routing 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?

The description goes well beyond the readOnly/idempotent annotations by disclosing data finalization delay (2–3 days behind), the 16-month retention limit, row capping and paging behavior, and Google's anonymization of rare queries when grouping by query. These are non-obvious behavioral traits that materially affect interpretation of results.

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 tight paragraphs: what the tool returns, how to supply dates and freshness expectations, and two caveats about numbers. Information is front-loaded and every sentence adds value, avoiding repetition of the schema's detailed parameter descriptions.

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 query tool with 12 parameters and an output schema, the description covers the critical non-obvious context: the report's scope, date-range alternatives, data freshness/retention, row pagination, and query-dimension aggregation caveats. The output schema handles return values, so nothing needed for correct invocation 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 baseline is 3. The description adds meaningful param-level guidance beyond the schema, especially the warning that query-dimension rows never sum to the property total and that date ranges must be either period or start/end dates. It slightly reinforces row_limit/start_row semantics but those are already well described in the schema.

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

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

The description identifies the exact resource (Google Search Performance report) and the specific metrics (clicks, impressions, CTR, average position), and clarifies it is the whole report as an API. It is immediately distinguishable from all sibling tools, which are about site management, sitemaps, and indexing rather than 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 gives clear context for when to use the tool — whenever Google Search performance metrics are needed — and offers practical guidance on date-range selection, data finalization lag, row limits, and why the query dimension may undercount totals. It does not name explicit alternatives, but no sibling tool serves this same analytics purpose, so exclusions are unnecessary.

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

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

The description discloses several important non-obvious behaviors: the API silently succeeds and changes nothing for non-qualifying pages, it returns 403 without explaining whether the problem is ownership or verification, and the default quota is 200 URLs per day. This adds substantial context beyond the annotations, which only provide idempotent and non-destructive hints.

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

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

The description is compact and front-loaded: a clear first sentence states the action, followed by essential caveats, auth requirements, and quota. Every sentence earns its place and there is no redundant wording 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 tool with an output schema and annotations, the description covers all operationally critical context: supported use cases, the alternative path for normal pages, auth ownership requirements, failure behavior, a deletion caveat, and quota limits. Nothing needed to use this tool 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?

The input schema already documents both parameters fully, so the baseline is 3. The description adds meaningful extra semantics by explaining that URL_DELETED truly requires the page to return 404 or 410, and that unsupported pages will produce a no-op despite a successful-looking response. This goes beyond the schema without duplicating 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?

The description states a specific action: it tells Google through the Indexing API that a URL was updated or removed. It also clearly differentiates this from a general crawl-injection tool and from sitemap submission, so an agent can distinguish it from siblings like submit_sitemap.

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

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

The description explicitly says this only works for pages with JobPosting or BroadcastEvent structured data, and for any other page the agent should submit a sitemap instead. It also gives the prerequisite that the credential must be a verified owner and notes the quota, leaving no ambiguity about when this tool is appropriate.

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

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

The description explicitly says 'It changes nothing,' which aligns with annotations readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Beyond the annotations, it adds valuable context about the failure mode of premature add_site calls and the DNS/meta-tag details it can return.

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

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

The description is front-loaded with the core purpose and uses the following sentences to explain the ordering pitfall and side-effect-free behavior. Every sentence earns its place, and the structure walks the agent from what the tool does, to why it matters, to what it returns.

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 output schema, one fully documented parameter, and strong annotations, the description is complete. It covers the tool's read-only nature, the domain-specific four-step setup order, the consequence of calling add_site prematurely, and what the tool reports.

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

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

The single parameter site_url is fully covered by the input schema, including format examples and the required trailing slash. The description does not add parameter-specific semantics, but at 100% schema coverage the schema already carries that burden.

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

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

The description states a specific, non-obvious function: reading a property's current state and reporting the exact next step needed. It explicitly contrasts itself with add_site, which succeeds but leaves the property returning 403, making it easy to distinguish from sibling tools.

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

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

It clearly explains when to use this tool — when you need to know where a property stands and what remains to be done. It also warns against the tempting alternative of calling add_site first, giving concrete context on why this tool should be used to check state before acting.

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

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

Beyond the annotations (idempotentHint, readOnlyHint), the description discloses that Google re-crawls on its own schedule, the old ping endpoint is gone, success only means the URL was accepted, and validity is checked later. These are valuable non-obvious behaviors with no annotation contradiction.

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

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

Four sentences with the main action front-loaded, followed by only high-value caveats. No repetition of schema content 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 simple two-parameter tool with an output schema and 100% parameter coverage, the description fully covers behavioral caveats, resubmission semantics, scheduling limitations, and how to observe errors later. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents feedpath and site_url with formats and examples. The description adds no additional parameter-level meaning, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Submits a sitemap URL, or resubmits one Google already knows') and names the resource. It does not explicitly differentiate from the sibling submit_sitemaps, though its singular wording implies a single sitemap.

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

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

It gives explicit resubmission guidance ('submit the same URL again... no separate update call, and submitting is idempotent'), states a limitation ('nothing can force it'), and points to get_sitemap as the place where parse errors surface. This tells an agent when and how to use the tool and what not to expect.

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

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

The description discloses key behavioral traits beyond the annotations: the underlying API has no batch method and calls are made sequentially, per-entry results are reported, and one failure does not stop the rest. This is valuable implementation context the 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?

Three sentences, all high-signal: the core capability is front-loaded, the batch limit is stated immediately, and the sequential execution detail is explained without excess. No filler words or redundant restatements of the 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?

Given rich parameter descriptions, a complete output schema, and annotations covering safety/idempotency, the description covers all additional operational context an agent needs: concurrency behavior, failure isolation, and practical use case. Nothing critical 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 both parameters are already well-documented in the schema. The description adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('submits'), a resource ('sitemaps for one property'), a clear scope (up to 50 in a single call), and a distinguishing behavior (per-entry success/failure reporting). It clearly differentiates from the singular submit_sitemap sibling without needing to name it.

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

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

The description gives clear context for when to use this tool: when submitting many sitemaps, since it saves a round trip per sitemap and makes large sites practical. It does not explicitly name submit_sitemap as the alternative for a single sitemap, leaving that comparison implicit.

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

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

Beyond the destructiveHint and non-read-only annotations, it reveals the important two-step confirmation behavior and that the token cannot be guessed or reused. The phrase 'returns a confirmation token' is slightly under-specified because the schema reveals it comes from a previous refusal, but no annotation contradiction is present.

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?

Single, front-loaded sentence with the core action stated first, followed by a compact two-step explanation. Every clause contributes; 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 destructive two-step mutation with rich annotations and a full input/output schema, the description covers the essential call flow and the token lifecycle. It does not discuss auth requirements or explicit consequences of removing the last owner, but those are not critical given the schema and annotation coverage.

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. The description adds procedural context for confirm_token (first call yields token, second removes), but adds no additional meaning for id beyond what the schema already provides.

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 the exact action ('Removes this credential from the owners of a site'), identifying both the resource (ownership credential) and the scope (site), which clearly distinguishes it from sibling tools like delete_site or verify_site. The title 'Remove ownership' reinforces the purpose.

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

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

Provides clear procedural guidance: the two-step call sequence and the instruction to call without confirm_token first. It does not explicitly name alternatives or exclusions relative to siblings like update_site_owners or delete_site, so it stops short of a 5.

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

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

The description goes well beyond the annotations by disclosing that the operation REPLACES rather than adds, that an empty list is rejected to prevent accidental wipe, and that the tool requires a two-step confirmation flow. It also explains that existing owners not included in the new list lose access. This fully covers the destructive and non-obvious behaviors.

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

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

The description is front-loaded with the core replace semantics, then gives the necessary safety warning, the prerequisite call, and the two-step flow. Every sentence contributes essential guidance; there is no filler or redundancy beyond intentional emphasis.

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 destructive nature and two-step behavior, the description is complete: it explains the replace behavior, how to avoid removing existing owners, the empty-list safety mechanism, and the token flow. Annotations and output schema cover the remaining metadata, so nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds valuable practical semantics: how to construct the owners list by calling get_verified_site first, and how the confirm_token flow works by first calling without it. This clarifies real usage beyond the schema's field-level descriptions.

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

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

The description opens with a precise verb and object: 'Replaces the list of verified owners of a site.' It clearly explains what the tool does and distinguishes it from related verification tools by describing the owner-list replacement concept rather than simple verification or unverification.

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

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

The description gives strong usage context: it is 'how a second person or a service account is granted ownership' and explicitly instructs callers to get_verified_site first and pass back existing addresses. It does not explicitly name alternative sibling tools or state when not to use it, but the practical guidance is clear.

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

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

Beyond the annotations, the description discloses that the call does not place the token, that failures are usually propagation delays rather than invalid credentials, and that retrying later is the expected response. This substantially reduces the chance of the agent treating a normal propagation failure as a fatal error.

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

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

The description is front-loaded with the core action and effect, then gives the prerequisite, then adds practical failure guidance. Every sentence adds value and there is no filler.

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

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

Given an output schema exists, parameter documentation is complete, and annotations cover idempotency and non-destructiveness, the description fills the remaining gaps: prerequisite steps, the write effect, and real-world failure behavior. Nothing needed for a correct call 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 already explains method defaults and the site_url format. The description reinforces the prerequisite relationship but does not add meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific action (check for the verification token) and its effect (records this credential as an owner), and names the prerequisite get_verification_token. This clearly distinguishes verify_site from siblings like get_verification_token and unverify_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?

It explicitly tells the agent to run get_verification_token first and place the token, and it says this call only checks rather than placing anything. It does not spell out when-not to use it versus unverify_site or update_site_owners, but the sequencing and retry guidance give a clear usage context.

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