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

Beyond the readOnlyHint annotation, the description adds valuable behavioral details about pagination metadata and the 100,000-row safety ceiling, plus the caveat that Search Console may still return only top data. This discloses limitations and external behavior without contradicting any 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?

Two sentences with no filler: the first delivers the main purpose, metrics, and dimension options; the second front-loads the pagination caveat. Every sentence earns its place and the most important behavior is highlighted early.

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

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

The description covers purpose, supported dimensions, and a key behavioral limitation. An output schema exists for return format, annotations cover read-only safety, and the schema documents parameter details, so nothing essential an agent needs to call this 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 describes all 6 parameters with coverage at 100%, including date formats, dimension enum, and site_url format details. The description only restates the dimension list and period comparison, adding no new parameter-level meaning beyond the schema baseline.

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

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

The description uses a specific verb ('Compare') and names the exact resource ('Search Console performance metrics') with concrete metrics and dimensions. It clearly distinguishes this from the sibling 'analytics.query' by emphasizing comparison across two distinct date ranges rather than a single period.

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 states the context for use: comparing performance between two date ranges for a selected dimension. It does not explicitly name alternatives or provide when-not-to-use guidance, but the comparison purpose is unambiguous enough to imply selection over a single-period query.

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

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

Annotations already signal read-only and open-world behavior, and the description adds substantial context: 2-3 day data lag, anonymized low-volume queries being omitted, impression-weighted average position, CTR as a 0-1 fraction, and pagination via next_start_row. This is unusually transparent and leaves little to guess about response 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?

Although long, the description is front-loaded with purpose and return shape, then organized into a clearly labeled 'IMPORTANT BEHAVIORS' section with focused bullets. Every sentence carries operational meaning, and the length is justified by the tool's 10-parameter complexity.

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 tool with 10 parameters, the description covers return structure, pagination, data freshness, aggregation semantics, filter usage, and data_state behavior. This is sufficient for an agent to select correct parameter values and interpret results reliably; no significant operational gap remains.

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 parameters are already well documented and the baseline is 3. The description adds valuable interpretation beyond the schema, such as RE2 syntax for regex filters, brand vs non-brand filter strategy, and the warning that summing per-query rows undercounts totals, which raises it to 4.

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

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

The opening sentence names a specific verb and resource: querying Google Search Console search analytics data, then defines the return envelope and row fields. This makes the tool's function unmistakable and enough to distinguish it from sibling analytics tools even without an explicit contrast.

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 'IMPORTANT BEHAVIORS' section gives explicit when-to/when-not guidance: use dimensions: [] for site totals, do not sum per-query rows, use matching dimensions for top queries, and pass 'final' only when stable data is requested. It does not explicitly route the agent to sibling tools such as analytics.compare, so it stops short of a full alternative-selection explanation.

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

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

Annotations already indicate readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining date-range derivation logic: if one boundary is omitted, the server derives the other to form an inclusive 30-day range, and generated end dates are capped at the latest complete date. This goes beyond the annotations and helps agents set expectations correctly.

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 two sentences with no redundant filler. The primary purpose is front-loaded, and the second sentence efficiently communicates key behavioral nuance. Every clause earns its place, making it easy for an agent to parse quickly.

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 a moderate complexity with four parameters and a full output schema, and the description covers its core purpose and date behavior. The schema handles parameter details and return values, so the description doesn't need to restate them. The main gap is the lack of explicit usage alternatives, but this is not critical for executing the tool correctly given the rich schema and annotations.

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% for all four parameters, so the baseline is 3. The description's date-derivation explanation partially overlaps with schema text, but it adds the phrase 'inclusive 30-day range,' which clarifies the interaction between start_date and end_date. Overall, the description does not need to compensate for missing schema info, so a 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 a specific action and resource: 'Retrieve a list of site pages that have received search impressions.' It also adds the important nuance of serving as a 'proxy list of indexed pages,' which distinguishes it from sibling tools like sitemaps.list or urls.inspect. Even without naming siblings, the purpose is explicit and 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 usage context is implied through the description of what the tool returns (pages with impressions as a proxy for indexed pages), but there is no explicit guidance on when to choose this tool over alternatives such as sitemaps.list or analytics.query. No when-not-to-use conditions or sibling comparisons are provided.

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

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

Annotations already convey read/write, idempotency, and destructive hints. The description adds meaningful behavioral context beyond annotations: Google's API restriction, the owner-level permission requirement, and the fact that submission is a request rather than a guaranteed immediate index. This is valuable transparency for an agent deciding whether the call will succeed.

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 two sentences with no filler. The primary action is front-loaded, followed immediately by the critical eligibility restriction. Every sentence earns its place.

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

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

The description is largely complete for this tool's complexity: it covers purpose, eligibility, auth ownership requirement, and the non-general nature of the API. The output schema exists, so return values need no explanation. A minor gap is the lack of an explicit pointer to sitemaps.submit for general pages, but this does not prevent correct invocation.

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

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

The input schema covers 100% of parameters and already provides rich descriptions for both 'url' and 'site_url', including format examples and permission failure modes. The tool description adds no additional parameter-level detail, so the baseline score of 3 applies.

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

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

The description clearly states a specific action ('Requests indexing through Google's Indexing API'), the resource ('a URL within an owner-level Search Console property'), and the critical scope restriction (only JobPosting or livestream BroadcastEvent pages). This distinguishes it from siblings like indexing.list_pages, urls.inspect, and sitemaps.submit.

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 provides an explicit when-not-to-use: 'It is not available for general webpage submission.' It also gives the eligibility criteria for valid submissions. However, it does not explicitly name an alternative tool for general webpage submission, such as sitemaps.submit, which would make the guidance fully complete.

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?

With annotations readOnlyHint=true and openWorldHint=true, the safety profile is already declared. The description adds valuable behavioral context about the pagination metadata flag and the 100,000-row safety ceiling, warning that a false flag does not guarantee full data return. This is exactly the kind of limitation disclosure that helps an agent interpret results correctly and 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?

Three sentences: purpose, definition, and a critical data-completeness caveat. Every sentence earns its place, and the caveat is placed at the end after the main purpose. No fluff or repetition 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?

The tool has an output schema, so return values need not be explained. The description covers what the tool does, the key limitation (pagination ceiling), and the site_url precondition is covered in the schema. It could add more context about typical use cases or how results should be interpreted, but with the output schema and rich parameter schemas, it is sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds conceptual meaning around the parameters by framing the analysis: 'min_impressions' and 'min_page_percentage' relate to how a page qualifies as cannibalizing. However, most parameter-level detail lives in the schema; the description itself doesn't explain defaults or constraints. A 4 is warranted because the description enriches the semantic model of the parameters even though it doesn't restate them.

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 ('Analyze', 'detect') and resource ('search analytics', 'keyword cannibalization') and clearly explains the concept ('multiple pages compete for the same query'). This distinguishes it from sibling analytics tools like analytics.query (generic querying) and insights.quick_wins/content_decay (other insight types).

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 detecting cannibalization specifically, which differentiates it from siblings, but it does not explicitly state when not to use it or name alternatives. It does include a practical precondition ('call sites.list first if unsure') about site_url format, which helps agents use it correctly. Missing explicit exclusion guidance, but the domain-specific wording is enough for most selection cases.

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

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

The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context by disclosing that pagination metadata flags when a source period hits the 100,000-row safety ceiling and that Search Console may still return only top data. This is useful beyond the annotations and schema.

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

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

Two sentences with no redundancy. The first sentence front-loads the core purpose and mechanism; the second adds an important data-limitation caveat. Every sentence earns its place.

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

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

Given the rich input schema, full parameter descriptions, output schema, and annotations, the description is complete. It covers the central comparison method and the key safety-ceiling caveat. Nothing critical for an agent to select or call the tool correctly appears 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: site_url explains formats and permission pitfalls, while compare_days explains default, range, and tradeoffs. The description reinforces the comparison logic but does not add significant parameter 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?

The description opens with a specific verb ('Identify content decay') and names the resource and method: comparing search clicks for site pages across two contiguous periods and finding pages with the largest traffic drops. This clearly differentiates the tool from siblings like insights.cannibalization and analytics.compare by signal and 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 usage context is implied by the phrase 'Identify content decay' but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Siblings such as insights.cannibalization and analytics.compare exist, but the description does not explain how to choose among them.

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 valuable behavior beyond the readOnlyHint and openWorldHint annotations: it clarifies that CTR is reporting context, not a filter, and discloses the 100,000-row safety ceiling with pagination metadata. The caveat that a false flag does not guarantee full Search Console data is especially transparent and prevents over-trust in the result set.

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

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

Three sentences, each earning its place: the first defines the core query filter, the second lists return metrics and clarifies CTR's role, the third discloses pagination limitations. It is front-loaded 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?

Given the output schema, annotations, and 100% parameter coverage, the description is complete for safe invocation. It covers defaults, return columns, the non-filter semantics of CTR, and the pagination ceiling. No critical operational 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?

Schema description coverage is 100%, so each parameter already carries meaning. The description adds some framing around the defaults (8-20 striking-distance range) and confirms min_impressions is an eligibility threshold, but it does not need to compensate for missing parameter documentation.

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 ('search queries') and a precise eligibility shape: impressions threshold plus a striking-distance position range. It clearly differentiates this from sibling tools like insights.cannibalization or insights.content_decay by framing the output as quick wins based on position and impressions.

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 a clear usage context: call this when the agent needs to surface queries just outside the top results that are worth optimizing. It does not explicitly name alternative tools or when-not-to-use conditions, but the eligibility criteria are specific enough to steer selection.

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 readOnlyHint and openWorldHint annotations by disclosing the output format (markdown), the time window (7 days ending on end_date), the comparative nature (week-over-week), included sections, and the default behavior for end_date. There is no contradiction with annotations; the read-only nature is consistent.

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 purpose is first, followed by the specific output contents and a default behavior note. Every sentence 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?

For a tool with only 2 parameters, 1 required, an output schema, and read-only annotations, the description is sufficiently complete. It explains what the report contains, the date window, the target property scope, and the default end_date behavior. No critical calling 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?

With schema description coverage at 100%, the input schema already fully documents both parameters, including the site_url format variants and the default for end_date. The tool description adds no meaning beyond what the schema provides, 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 identifies a specific verb ('Generate'), a resource ('weekly SEO report for one Google Search Console property'), and the exact output scope (7 days ending on end_date, week-over-week comparison, top pages, query trends, action item). This makes it easy to distinguish from siblings like analytics.query or individual insights tools.

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

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

The description makes the intended use clear: produce a plain-language weekly digest for a single GSC property. It does not explicitly mention when to use a sibling like analytics.query instead, but the context of a scheduled/plain-language weekly report is enough to guide selection. It lacks explicit exclusions or alternative-routing guidance, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds that the tool returns a catalog, access mode, and auth status while taking no arguments. It frames the tool as a safe first step, but does not describe potential edge cases or staleness of auth status; still, the extras are useful.

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 serve a distinct purpose: describing the output, giving usage guidance, and noting the return payload plus lack of arguments. There is no fluff and the most important information is front-loaded.

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

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

With no parameters, an output schema, and safety annotations, the description supplies all needed behavioral context. It even names the return elements, so an agent can decide to call it without opening the schema.

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

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

With zero parameters, the schema is trivially complete and the description explicitly reinforces 'Takes no arguments.' This matches the baseline for parameter-free tools and leaves nothing ambiguous.

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 lists every tool, the configured access mode, and auth status. This clearly differentiates it from data-oriented siblings like sites.list or analytics.query, marking it as a discovery tool.

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

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

It explicitly says to call this first when unsure about available tools, whether the deployment is read-only, or whether the user is connected. This provides concrete triggers for use and implies it precedes other operations.

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 destructiveHint=true and idempotentHint=true, so the description doesn't repeat those. The description confirms the destructive nature with 'Remove/delete'. It adds the behavior that site_url format errors can cause permission errors even for legitimate owners, which is useful context. 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 main description is a single concise sentence, but the site_url guidance in the schema is lengthy and highly informative. The description text itself is appropriately short, though it could have front-loaded a warning about the destructive nature.

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 operation with clear annotations (destructiveHint=true), the safety profile is conveyed. The site_url format explanation covers the main usage pitfall. An output schema exists so return value documentation isn't needed. The description could mention idempotence implications, but idempotentHint already covers that.

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 parameter semantics are already well-documented in the schema. The description additionally clarifies the site_url format pitfall and instructs calling sites.list first, which adds real value beyond the schema. The feedpath parameter is documented with an example in the schema itself.

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 specific action ('Remove/delete a submitted sitemap') and the resource ('sitemap from your Google Search Console account'). It differentiates from siblings like sitemaps.list and sitemaps.submit by focusing on the delete operation, though it doesn't explicitly name alternatives.

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 context implies deletion of an already-submitted sitemap. The site_url parameter description gives important guidance about property formats and calls out that sites.list should be called first if unsure. However, it doesn't explicitly state when not to use this tool or contrast it with sitemaps.submit or sitemaps.get.

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 the read-only nature is established. The description adds that the operation returns status and details of a submitted sitemap, but it does not disclose additional behavioral context such as error conditions, rate limits, or special case handling. This is acceptable but not richly transparent.

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 a single, focused sentence with no filler or redundancy. It is appropriately sized for a simple read-only getter and front-loads the core purpose immediately.

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

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

For a two-parameter read-only tool with full schema coverage and an output schema, the description is complete enough to support correct invocation. It clarifies that the tool targets a single submitted sitemap, while the schema covers the required parameter semantics and the annotations cover safety.

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 already have detailed descriptions, including site_url format guidance and a note about permission errors. The tool description does not add parameter-level meaning, but the schema carries the full burden, 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 uses a specific verb ('Get') and resource ('status and details of a single sitemap submitted to Google Search Console'). It clearly identifies what the tool does and, by saying 'single sitemap,' implicitly distinguishes it from sitemaps.list, which deals with multiple sitemaps.

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

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

The description provides no explicit guidance about when to use this tool versus the sibling sitemaps.list, sitemaps.submit, or sitemaps.delete. It implies use for an individual sitemap's details but gives no alternative selection criteria or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds valuable behavioral context by enumerating the returned fields and explicitly noting that Google's deprecated sitemap indexed count is intentionally omitted, which prevents an agent from assuming that field will exist. This is useful beyond the annotations without overreaching.

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

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

Three sentences with no filler: action and scope first, return values second, and usage guidance last. The mention of the intentional omission is relevant and concise, and 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 one-parameter read-only listing tool with an output schema and annotations, the description covers purpose, return values, an important omission, and use cases. Nothing an agent needs to decide whether to call this tool is missing.

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

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

Schema description coverage is 100%, and the site_url parameter already has a detailed description including format examples and a permission-error warning. The tool description itself adds no extra parameter information, so the baseline of 3 is appropriate; the schema carries the semantic weight.

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 verb ('List') and resource ('all sitemaps submitted for a Search Console property'), and clarifies scope with 'all'. The description also distinguishes itself from sibling sitemap tools by focusing on listing existing submissions, and it specifies the key returned data fields. This makes the tool's purpose unmistakable even 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?

Provides explicit usage context: 'Use this when the user asks about sitemap health, submission status, or wants to audit which sitemaps are working.' It does not explicitly state when not to use it or mention alternatives, but for a list operation the positive use cases are clear enough to guide an agent.

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 convey that the operation is mutating, open-world, idempotent, and non-destructive. The description adds no behavioral context beyond stating the action, such as retry safety, external side effects, or error behavior. It does not contradict 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?

The description is a single, front-loaded sentence with no filler. Every word earns its place, and the action and target are immediately clear.

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 submit operation, the description is largely complete when combined with the rich input schema, output schema, and annotations. The only notable gap is lack of explicit usage guidance relative to sibling tools, but the structured context covers invocation needs well.

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

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

Schema description coverage is 100%, and the schema provides rich parameter details, especially for site_url with format examples and error guidance. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Submit') with a clear resource ('a new sitemap') and destination ('Google Search Console account'). This clearly distinguishes the tool from sibling sitemap operations like sitemaps.list, sitemaps.get, and sitemaps.delete.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of related calls like sites.list or sitemaps.list. The schema's site_url description hints at calling sites.list first, but the tool description itself provides no usage direction.

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

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

Annotations already indicate a mutating but non-destructive operation, and the description adds no side-effect or error behavior beyond the obvious 'Add' semantics. The format note is useful but is parameter constraint rather than behavioral disclosure.

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 the core action front-loaded and the critical format caveat isolated in a short Note. No filler words or redundant elaboration.

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 mutating tool with a detailed schema, an output schema, and annotations, the definition covers the essentials. It lacks a brief statement of prerequisites or expected results, but the schema compensates for the main risk of using the wrong identifier format.

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

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

The input schema already provides 100% coverage of site_url, including both formats and a warning about permission errors. The description's note largely repeats that schema guidance and adds no new parameter semantics.

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 ('Add') and resource ('new website property') against a Google Search Console account. The operation is unique among sibling tools like sites.list and sites.delete, so an agent can distinguish it 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 phrase 'Add a new website property' implies when the tool should be used, but the description does not explicitly compare it with alternatives or say when not to use it. The format note is a prerequisite for the parameter, not a usage-routing guideline.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description aligns with 'Remove'. It adds context that the property must be 'existing' and scoped to the user's account. The parameter description further warns that an incorrect format returns a permission error even for an owner, which is extra behavioral nuance beyond 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?

The description is a single, front-loaded sentence with no filler. It conveys the action and object immediately without wasting tokens.

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 destructive operation with one well-documented parameter, annotations conveying destructive behavior, and an output schema present, the description is sufficient. It does not need to explain return values or side effects beyond what annotations and the schema already cover.

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 has 100% schema description coverage, including exact format, examples, and a warning about wrong formats. The tool-level description adds no parameter information, but the schema fully compensates, so the baseline of 3 applies.

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

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

The description states a specific verb ('Remove') and a clear resource ('existing website property from your Google Search Console account'). This distinguishes it from sibling tools like sitemaps.delete (which targets sitemaps) and sites.add (which adds a property).

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 intended use clear: deleting a Search Console property. It does not explicitly name alternatives or exclusions, but the resource distinction is obvious from the title and sibling list. The schema's note to 'call sites.list first if unsure' is parameter guidance rather than tool-selection 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 provide readOnlyHint=true and openWorldHint=true. The description adds meaningful context by stating the exact output format and clarifying that it only lists properties the connected account can access, without contradicting 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?

Three sentences, each earning its place: the first states what the tool does and returns, the second gives natural-language triggers, and the third explains the discovery role. No fluff or repetition.

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

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

For a zero-parameter, read-only tool with an output schema and clear annotations, this description is complete. It covers purpose, output structure, triggering user intents, and integration with other 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?

The tool has zero parameters and an empty input schema, so the baseline is 4. No parameter explanations are needed, and the description appropriately focuses on behavior and usage rather than inputs.

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

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

The description states a specific verb ('List') and resource ('Google Search Console properties'), and scopes it to the connected account's accessible sites. It also specifies the return shape ({ siteUrl, permissionLevel }), making it clearly distinct from sibling tools like sites.add and sites.delete.

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 trigger phrases ('what sites do I have?', 'what properties are connected?') and an explicit discovery-use case before tools requiring site_url. It lacks an explicit 'do not use when...' clause, so it's strong but not 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?

Annotations already indicate readOnlyHint, but the description adds meaningful behavioral context beyond that: there is no batch endpoint, repeated calls are needed for multiple URLs, and Google caps URL inspections at roughly 2,000 per property per day. It also details the return content, which helps the agent predict what the tool will produce. No contradiction with annotations exists.

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

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

The description is compact and well-structured: the first sentence states purpose and outputs, the second gives usage triggers, and the third covers bulk behavior and rate limits. Every sentence contributes useful information without redundancy 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?

Given the tool's complexity, the description is complete: it covers purpose, outputs, when to use, bulk limitations, rate caps, and the parameter caveats are in the schema. An output schema exists, so the description does not need to enumerate return types. Nothing an agent would need to decide whether and how to call this tool 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 baseline is 3; the parameter meanings, formats, and constraints are already fully described in the input schema. The tool description itself does not add new parameter-level detail beyond what the schema provides, though it reinforces the single-URL scope.

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

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

The description opens with a specific verb and resource: 'Inspect a single URL's index status in Google.' It enumerates the returned dimensions (indexed status, last crawl date, mobile usability, rich-results eligibility, AMP results), making the tool's purpose concrete and unambiguous. It also distinguishes this from bulk operations by emphasizing the single-URL 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 gives explicit trigger conditions: use when the user asks 'is X indexed?', 'why isn't X showing in Google?', or wants a deep look at one page. It also gives clear guidance for bulk checks ('call this tool repeatedly — there is no batch endpoint') and discloses the 2,000-calls-per-day cap, so an agent knows the operational boundaries.

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