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

The annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds meaningful behavioral context beyond the annotations by disclosing the GSC_ALLOW_DESTRUCTIVE prerequisite and the ownership-verification requirement.

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 short and front-loaded, starting with the action and immediately following with the key prerequisites. The Args section is compact and every sentence adds necessary 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 simple one-parameter mutation tool with an output schema, the description covers the action, required environment flag, ownership-verification caveat, and accepted URL formats. Nothing essential 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 description coverage is 0%, so the description must carry the parameter meaning. It does this well by giving concrete accepted formats: URL-prefix like "https://www.example.com/" and domain like "sc-domain:example.com".

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: "Add a property to your Search Console account." This clearly distinguishes it from siblings such as list_properties, get_site_details, and delete_site.

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

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

It gives clear context and prerequisites: GSC_ALLOW_DESTRUCTIVE=true is required, and ownership must still be verified in Search Console. It does not explicitly name when to use this versus alternatives, but no sibling appears to provide an add-property 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, openWorldHint, and destructiveHint=false, so the description does not need to repeat the safety profile. It adds meaningful behavior by disclosing concurrent inspection, per-URL return fields, batch-size defaults, and the environment variable controlling the limit.

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 return details, then gives a compact Args section. Every sentence provides useful information about behavior, parameters, or limits, with no repetition 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 two-parameter batch inspection tool with an output schema and full annotations, the description is complete. It covers purpose, concurrency, return fields, both parameters, defaults, and batch-size limits.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It documents both parameters well: site_url is the exact property and defaults to GSC_SITE_URL; urls may be one per line or a JSON array, with a default max batch size controlled by GSC_MAX_BATCH_URLS.

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 and resource: inspecting several URLs at once, concurrently. It also distinguishes the batch behavior from single-URL inspection siblings by explicitly saying 'several URLs at once' and describing per-URL results.

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 batch context clear and gives useful limits such as the default max of 10 and the GSC_MAX_BATCH_URLS setting. It does not explicitly name alternatives like inspect_url_enhanced or state when not to use this tool, but the batch scope is clear enough for 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?

Annotations already declare readOnly, openWorld, and idempotent, so the safety bar is low; the description nonetheless adds that the check is against GitHub (external network dependency) and that the result includes a concrete upgrade command. It doesn't cover the no-update-available case or network failure behavior, keeping it short of a 5.

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

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

One sentence, front-loaded with the action and the source, with zero filler. Nothing could be cut without losing information.

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

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

With an output schema present, the description needn't explain return values, and it correctly stays focused on what is checked and where. Only the behavior when already up to date is left unexplained, a minor gap for a zero-parameter tool.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies the call needs no arguments.

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 (check) plus the resource (GitHub for a newer version of Sam GSC MCP) and what it returns (the upgrade command). No sibling tool touches self-versioning, so an agent can route this unambiguously.

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 intent is implied by the name and description, but there is no explicit 'use when' trigger (e.g. after an error suggesting an outdated version) and no exclusion or alternative mentioned. Adequate but leaves timing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuine value by disclosing that results are grouped into named issue buckets and that site_url falls back to the GSC_SITE_URL environment variable, but it omits practical traits such as how many URLs can be checked at once, whether each URL is fetched live (and therefore slow), and any quota 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?

The purpose and the bucket list come first, with parameter notes compactly separated into an Args block; there is no filler. Slightly abbreviated prose style, but every line carries information.

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

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

Because an output schema exists, the return shape need not be explained, and annotations cover safety, so the description is close to sufficient for a 2-parameter tool. What is missing is scale and cost context — how many URLs are reasonable and whether live fetching makes this a slow, open-world call — which matters for an agent deciding between this and a single-URL sibling.

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 0%, the description must supply the semantics, and it largely does: site_url is defined as the 'exact property' with an explicit fallback, and urls is explained as either newline-separated text or a JSON array, matching the anyOf string/array schema. It does not address the empty-string default for urls or any maximum URL count.

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

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

States a concrete verb and resource ('check several URLs') and, more usefully, enumerates the outcome buckets (not indexed, canonical mismatch, robots blocked, noindex, fetch errors, rich-result issues), which makes it distinguishable in output shape from siblings like check_url_status or get_index_coverage. It stops short of naming a sibling it is not, so it is clear but not explicitly differentiated.

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 when this is appropriate (diagnosing indexing problems across multiple URLs) but never states when to prefer it over batch_url_inspection, inspect_url_enhanced, or check_url_status. The only conditional guidance given is the site_url default, which is about parameter setup rather than tool 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real value on top: it discloses the returned data points and the site_url fallback to the GSC_SITE_URL environment variable. It stops short of noting auth/permission requirements or behavior when the URL is outside the property.

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 yes/no answer and returned-signal list are front-loaded, and the compact Args block avoids repetition. Every line earns its place; only minor gain from tightening 'Full URL to check'.

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 0 required params, an output schema present, and only two inputs, the description supplies enough to invoke correctly: property scoping, env-var default, and what comes back. Remaining gaps (auth prerequisites, mismatch behavior) are modest for a read-only check.

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

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

Schema description coverage is 0%, so the description must carry both parameters — it does explain site_url as the exact property with an env-var default, and page_url as the full URL. However, 'Full URL to check' gives no format details (scheme, whether it must belong to the property), leaving a gap on the more important parameter.

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 ('is this URL indexed?') and enumerates the returned signals (coverage state, last crawl, canonical, robots/fetch status). The 'Quick yes/no' framing implicitly distinguishes it from the heavier inspect_url_enhanced and batch_url_inspection siblings, but never names them.

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?

'Quick yes/no' implies this is the lightweight check versus a full inspection, so usage is implied rather than stated. There is no explicit when-to-use/when-not guidance and no named alternative for bulk checks or deep inspection.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so the description's added value is the delta-sign semantics (positive = Period 1 improved, including the inverted case of lower position being better) and the fact that filters apply to both periods. Useful behavioral context beyond structured fields, though it says nothing about pagination or how many dimensions are returned.

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

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

Front-loaded with the core comparison semantics and the sign convention before the Args block, and every line of that block conveys non-obvious information. No restatement of the tool name or filler prose.

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 nine-parameter comparison tool with an output schema already describing return values, the description supplies everything needed to invoke it correctly: period roles, defaults, formats, and filter behavior.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely succeeds: it documents all nine parameters, their date format (YYYY-MM-DD), search_type values, dimensions syntax ('query,page'), and the limit default of 20. The one gap is the filters parameter, whose accepted shape (string vs object vs array) is never clarified.

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 (compare two date ranges item by item) and names the entities being compared (queries, pages). It is clearly distinguishable from sibling analytics tools like get_search_analytics and get_performance_overview because it is explicitly a period-over-period comparison.

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

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

Explains the directional convention (Period 1 analysed vs Period 2 baseline) and the no-argument default (last 28 days vs the preceding 28 days), which is exactly the usage context an agent needs. It does not name an alternative tool or state when not to use a comparison, so it falls 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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot express: the environment-variable gate that must be enabled before 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 destructive gate is front-loaded in the first sentence, and the total length is two short blocks. The 'Args:' listing is slightly boilerplate but earns its place by pinning down the single required parameter.

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?

An output schema exists, so return values need no explanation, and annotations cover the destructive/idempotent semantics. Combined with the explicit auth gate and parameter sourcing, an agent has what it needs to call this correctly; only the accepted property-string formats are unstated.

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

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

Schema coverage is 0%, so the description carries the load, and it does: site_url must be the exact property string, obtained from list_properties. That sourcing constraint is real value beyond the bare 'Site Url' string type, though the exact format (sc-domain: vs URL prefix) is not spelled out.

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 ('Remove') and resource ('a property from your Search Console account'), which an agent can easily separate from add_site or list_properties. It stops short of explicitly naming the sibling it contrasts with, so it lands at clear-but-not-fully-differentiated.

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

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

Gives two concrete usage conditions: the destructive-operation gate (GSC_ALLOW_DESTRUCTIVE=true) and the requirement to obtain the exact property string from list_properties. It does not state when removal is inappropriate or what alternatives exist, but the preconditions are explicit.

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

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

Adds two pieces of context beyond the annotations: the GSC_ALLOW_DESTRUCTIVE=true guard and the non-obvious side effect that already-indexed URLs stay indexed. Annotations already cover destructive/idempotent hints, so this is meaningful added value, though it doesn't mention irreversibility of the unsubmit or error 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?

The destructive action and its guard are front-loaded in the first two sentences, followed by a compact two-line args block. No sentence is wasted.

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 an output schema present, return values need not be explained, and the guard, side effect, and both parameters are covered. The remaining hole is that both parameters are optional with an empty-string default for sitemap_url, and the description never says what happens if it is omitted.

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

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

Schema description coverage is 0%, so the description must compensate, and it mostly does: it explains that site_url is the exact property and falls back to GSC_SITE_URL, and that sitemap_url must be a full URL. It leaves a gap around sitemap_url defaulting to an empty string despite no parameters being marked required.

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

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

States a specific verb and resource ("Remove (unsubmit) a sitemap from Search Console") and clarifies the operation with the parenthetical synonym. It is clearly distinguishable from submit_sitemap and get_sitemaps by the removal verb.

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

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

Gives a concrete usage context via the precondition (requires GSC_ALLOW_DESTRUCTIVE=true), which tells the agent when this call will actually succeed. It does not name alternatives (e.g., use get_sitemaps to verify before removing) or state when not to use it, so it stops short of full routing 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?

Beyond the annotations it discloses real behavior: auto-pagination, a 500,000-row ceiling, a default 100,000 safety cap, that a file is written to GSC_EXPORT_DIR (~/Documents/sam-gsc-exports) and that the return is path plus preview. Minor unresolved tension: readOnlyHint=true while the tool creates a file on disk, which an agent may want clarified, but it does not mutate the remote GSC data.

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

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

A single dense lead sentence carries purpose, mechanism, limits and return value, followed by a compact per-argument list. Nothing is padded and the most decision-relevant facts come first.

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 nine-parameter export tool with an output schema, the description covers destination, caps, defaults and return shape well enough to call it correctly. The only material gap is how to construct the filters argument, which is left to guesswork.

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

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

Schema description coverage is 0%, so the Args block carries the whole load and largely does: env-var default for site_url, a dimension syntax example, YYYY-MM-DD date format, the default/max for max_rows, and the search_type values (web, image, video, news, discover, googleNews) which are not enforced as an enum in the schema. The weak spot is 'filters: Optional AND filters', which never explains the accepted string/array/object shapes the schema allows.

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 plus the output medium: 'Bulk-export Search Analytics rows ... to a CSV file on this computer and return its path plus a preview.' That clearly separates it from the sibling read tools (get_search_analytics, get_advanced_search_analytics) which return rows inline, though no sibling is named explicitly.

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

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

Usage is only implied by the word 'Bulk-export' and the row caps; there is no explicit statement of when to pick this over get_search_analytics / get_advanced_search_analytics or when a CSV export is inappropriate. An agent can infer the split, but must do the inferring itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing what the response contains (a primary page recommendation and a fix) and by explaining the threshold semantics behind the filters.

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 purpose sentence is front-loaded and the Args block is terse with one line per parameter, each earning its place. The Python-docstring framing is slightly mechanical but adds no filler.

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

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

With an output schema present, return values need not be explained, and every input is documented. What remains missing is context around data scope or limitations (e.g. property/date-range constraints, cost of a wide days window), which would round out a moderately complex analytical tool.

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

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

Schema description coverage is 0%, so the description must carry the burden – and it does: all five parameters are documented with meaning and defaults, including the fallback for site_url (GSC_SITE_URL) and the precise interpretation of min_share as a share of a query's impressions. This is exactly the compensation the schema gap requires.

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 first sentence names a specific verb ('Find') and a precise analytical resource ('queries where two or more of your pages compete') and states what the result contains (suggested primary page + fix). This is clearly distinguishable from sibling diagnostics such as find_striking_distance_keywords and find_low_ctr_opportunities.

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

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

Usage is implied by the purpose statement – an agent can infer this is for diagnosing internal keyword overlap – but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling analytics tools. Nothing is misleading, but the routing guidance is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint, so the safety profile is covered. The description adds real behavioral content beyond that: the filtering logic that defines a result (rank top AND low CTR AND sufficient impressions) and the concrete default thresholds that shape output volume. It still doesn't mention pagination/row-cap behavior or property-access prerequisites beyond the GSC_SITE_URL default.

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 purpose is front-loaded in a single dense sentence, followed by a clean Args block with no filler. Minor cost: the diagnostic aside lengthens the opening sentence and the max_position phrasing is imprecise rather than wasteful.

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 an output schema present, return values need not be explained, and annotations cover mutability. All six parameters are accounted for and the selection logic is clear. Remaining gap is minor: no explicit indication of how the defaults interact (e.g., min_impressions gating before or after position filtering) or of authentication expectations for a read-only GSC query.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely meets it: all six parameters are listed with defaults and intent, including a useful note that site_url falls back to GSC_SITE_URL. The one weakness is max_position, described as 'Only rows at or above this position' — ambiguous given that lower numbers are better, so an agent might misread the comparison direction.

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 precise, specific concept: pages ranking in top positions (position <= 5) whose CTR is at or below 2%. The parenthetical diagnoses why (title/meta rewrites or AI Overview/featured-snippet cannibalization), which clearly separates it from siblings like find_striking_distance_keywords or find_keyword_cannibalization.

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

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

Usage context is implied by the diagnosis ('title/meta rewrites, or answers being shown in AI Overviews / featured snippets'), so an agent can infer the intent is to find on-page optimization candidates. However, the description never states when to use this versus get_search_analytics or get_search_by_page_query, and no exclusions are given.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral context: the ranking metric (estimated extra clicks if position 3 reached), default position range, impression threshold, and that rows below min_impressions are ignored. It does not mention authentication or data freshness, but the added context exceeds annotation coverage.

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

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

A single front-loaded sentence defines the tool, followed by a compact Args list with defaults. Every sentence earns its place; no 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?

With an output schema present, the description needn't explain return values, and it covers purpose, ranking logic, and all parameters. It does not mention prerequisites such as GSC access or property permissions, but the openWorld annotation and site_url default provide sufficient context for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden. It documents every one of the 6 parameters with meaning and defaults: site_url falls back to GSC_SITE_URL, days to analyse, position bounds, impression floor, and row limit. This fully compensates for the schema's lack of 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 states a specific concept and action: 'quick wins: queries ranking just off the top spots' ranked by estimated extra clicks. It clearly conveys what the tool returns, though it does not explicitly differentiate itself from siblings like find_low_ctr_opportunities or get_search_analytics.

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

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

Usage is implied by the 'Quick wins' framing and the default position window, but there is no explicit guidance on when to use this tool versus alternatives, nor any stated exclusions. An agent must infer the right context from the name and description alone.

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 this is read-only, idempotent, non-destructive and open-world. The description adds meaningful behavior: a 25,000-row cap, pagination mechanics, sorting applied to returned rows, regex filter support, AND logic for multi-filters, and data_state options.

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 key capability, then uses a clean argument list for a 15-parameter tool. Every line adds operational meaning and there is no redundant prose.

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 15-parameter analytics query tool, the description covers the important calling constraints, defaults, pagination, filtering, sorting, and data freshness options. Since an output schema exists, it does not need to explain return values.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden and does so thoroughly. It documents defaults, date formats, allowed search types, row limits, pagination usage, sort fields and direction semantics, filter dimensions/operators, and the filters override rule.

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 makes clear this is a high-volume search analytics query tool with pagination, sorting, regex and multi-filter AND logic. It does not explicitly name Google Search Console or distinguish itself from the sibling get_search_analytics, but the resource and capabilities are still identifiable.

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

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

It gives operational guidance such as using next_start_row from the previous page and that filters overrides the single-filter args. However, it does not say when to use this tool versus get_search_analytics, export_search_analytics, compare_search_periods, or other analytics siblings.

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?

While annotations cover safety (read-only, idempotent), the description adds valuable behavioral context by detailing the specific data points measured (clicks, positions, etc.), which enhances the agent's understanding of the tool's output scope.

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 structure is excellent, presenting the high-level purpose first, followed by a clear, well-organized list of arguments and their descriptions. Every part of the text is useful.

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 the input schema was not descriptive, the description successfully covered all necessary technical and semantic details required to make the tool callable correctly. It defines defaults and complex input formats thoroughly.

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?

Since schema coverage was 0%, the description provided vital semantic meaning for all parameters. It clarified that `site_url` is an exact property (with defaults) and provided a concrete example and format for `brand_terms` ('acme,acme corp,akme').

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 defines the tool's function as splitting traffic into branded vs non-branded segments. It explicitly lists the metrics returned: share of clicks/impressions, CTR, position, and top queries.

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

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

The tool describes *what* it does but provides no explicit guidance on *when* to use it versus the multitude of available sibling analytics tools. Usage is implied by its specific function rather than stated definitively.

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 useful behavioral context by naming what the output contains (tool inventory by category, auth status, settings) and positioning it as a recovery step on failure.

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

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

Two short sentences with zero waste: content first, then the invocation trigger. The action guidance is front-loaded where an agent will see it 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?

With no parameters, an output schema, and rich annotations, the description only needs to convey purpose and when to call it, which it does. Minor gap: it doesn't hint at output size or whether the listing is exhaustive versus summarized, though the output schema likely covers structure.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter detail is needed or missing.

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

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

States a specific verb and resource ('List every tool by category') plus the extra content returned: auth status and active settings. That clearly distinguishes it from sibling tools that operate on sites, sitemaps, or analytics data.

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

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

Gives explicit trigger conditions: 'Call this FIRST when unsure what the server can do or when something fails.' An agent knows both the proactive and reactive cases for invoking it without needing to inspect the sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and locality profile is fully covered without the description. The description adds no further behavioral context (e.g., that it is static/local and takes no arguments), but it also contradicts nothing.

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

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

A single short sentence with no waste, front-loading the subject. It is arguably too terse to stand alone, but nothing is padded or repeated.

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?

Output schema exists, so return values need not be described, and there are no parameters to explain. For a trivial zero-arg informational tool with full annotations, the description is sufficient, though one clause naming the kind of content returned would close the remaining gap.

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

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

Zero parameters, so there is nothing for the description to document; the baseline of 4 applies. Schema coverage is reported at 100% and the empty properties object confirms no input is expected.

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

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

The description identifies a specific resource — biographical info about the creator of this MCP server — so an agent can tell it apart from the analytics and sitemap siblings. But it is phrased as a bare noun fragment with no verb ("returns", "shows"), making the purpose more implied than stated.

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

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

There is no guidance on when to call this versus near-neighbors like get_capabilities or check_for_updates, both of which are also static metadata tools. An agent must infer that this is for questions about the tool's author, and nothing excludes misuse.

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 this a safe, idempotent read. The description adds a genuinely useful caveat that 'Hourly data can be partial,' a data-quality trait not captured by annotations, plus the ~10-day retention window. It doesn't detail auth or pagination, keeping it a solid 4.

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 purpose and time scope are front-loaded in the first sentence, followed by a compact args block. The parenthetical examples earn their place; there is minimal waste.

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 an output schema present, return values needn't be explained, and the description covers all params plus a data-quality caveat. It's essentially complete for correct invocation, with only the filters format leaving minor ambiguity.

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 0% schema coverage, the description carries the burden and mostly does: it documents all four params, including defaults (GSC_SITE_URL, 3), the 1-10 range for days, the AND-filter semantics for filters, and enumerates search_type values absent from the schema. The filters format (string/array/object) stays vague, slightly limiting an agent on complex filter construction.

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 (get) and resource (hour-by-hour clicks and impressions) with an explicit time scope ('roughly the last 10 days'). The hourly granularity implicitly distinguishes it from aggregate siblings like get_performance_overview, though it doesn't name an alternative directly.

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 concrete use contexts ('great for launches, news spikes and outage checks'), which help an agent decide when this tool fits. It stops short of explicit when-not guidance or naming a sibling to prefer for aggregate trends.

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 this as a read-only, idempotent, non-destructive operation. The description adds important behavioral context beyond annotations: there is no bulk coverage endpoint, so results are sampled, and the limit has a maximum tied to GSC_MAX_BATCH_URLS x 5. This prevents the agent from mistaking the output for exhaustive coverage data.

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 opening sentence is front-loaded with the core purpose, and the Args list is compact and necessary because the schema itself has no parameter descriptions. Every section adds useful information without unnecessary 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?

An output schema exists, so return value details are not needed in the description. The description still provides enough context about sampling behavior, source selection, scope defaults, limits, and filtering for an agent to invoke the 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 0%, so the description carries the full burden of explaining parameters. It documents all seven parameters, including defaults, the source choices, how urls overrides source, sitemap default behavior, the limit cap, the days window, and examples for issue_filter.

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: a coverage report built from live URL Inspection that groups URLs by Google's coverage state with counts and example URLs. It is clear and actionable, but it does not explicitly distinguish this tool from sibling tools such as check_indexing_issues, inspect_url_enhanced, or batch_url_inspection.

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

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

The description explains the sampling mechanism and the three practical sources: top pages, sitemap, or an explicit URL list. It also clarifies defaults and override behavior for source selection, but it does not explicitly say when to use this tool instead of sibling indexing or inspection tools.

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

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

Annotations already declare read-only/idempotent/open-world, so the description wisely adds context the annotations cannot: the data source (URL Inspection), the 2023 deprecation of the Mobile Usability report, and the resulting likelihood of empty verdicts. That is exactly the kind of caveat an agent needs before trusting a null usability result.

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

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

Front-loads the purpose, immediately follows with the critical deprecation caveat, then lists arguments one per line without redundancy. Every sentence earns its place and the structure matches how an agent reads a tool definition.

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?

Rich annotations and an output schema mean the description need not explain return shapes or safety; it focuses instead on the deprecation caveat and full parameter semantics. Nothing material for calling 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?

Schema description coverage is 0%, so the description carries the full burden and succeeds: it explains site_url's default (GSC_SITE_URL), urls (one per line, defaults to top pages), source's allowed values ('top_pages' or 'sitemap') and prerequisite (when urls is empty), limit's default, and issue_filter's substring-matching behavior.

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 and resource ('Mobile signals per URL from URL Inspection') and lists the exact fields returned (crawled-as, fetch state, mobile-usability verdict/issues). It is clearly mobile-specific, but never names the URL-inspection siblings (inspect_url_enhanced, batch_url_inspection, check_url_status) it must be chosen over.

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 clear exclusion: the Mobile Usability report was retired in Dec 2023, so use Lighthouse/PageSpeed for layout checks instead. That is a strong when-not-to-use signal, but it stops short of saying when this tool should be preferred over the other URL-inspection tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value by revealing that site_url falls back to the GSC_SITE_URL environment variable and that days defaults to 28, but it says nothing about data freshness/lag, rate limits, or what happens on an invalid property.

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

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

One summary line up front followed by a compact Args block; every line carries information and nothing is padded.

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?

An output schema exists, so return values need not be explained, and all three optional parameters are documented. However, for a tool sitting among ten-plus analytics siblings, the description never positions it in that family or notes GSC's typical reporting lag, both of which an agent needs to call it in the right situation.

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

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

Schema description coverage is 0% and there are no enums in the schema, so the description must carry the burden — and it does: it explains the environment-variable fallback for site_url, the meaning of days as a lookback window, and the six valid search_type values. It stops short of clarifying the required site_url format (e.g., sc-domain vs URL-prefix properties).

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 first sentence names the exact metrics returned (clicks, impressions, CTR, position) plus the day-by-day trend, so the resource and output shape are clear. It does not differentiate itself from closely related siblings such as get_search_analytics, get_advanced_search_analytics, or compare_search_periods, leaving the agent to infer which to pick.

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

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

There is no statement of when to use this tool versus the many analytics siblings, and no exclusions. The Args block supplies defaults but is purely mechanical parameter listing, not usage 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 establish read-only/idempotent/open-world safety, and the description adds substantial behavior beyond them: env-var default site, automatic domain matching, days ignored when start_date is supplied, the 25,000 row cap, the cheap summary_only path, AND-combined filter semantics, and the all-vs-final data_state distinction. This is more behavioral context than most definitions 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?

Front-loaded with the returned metrics, then a compact args block with no filler. Size is proportionate to 11 undocumented parameters, and every line conveys actionable information.

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

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

With an output schema present, return values need no explanation, and the description covers defaults, formats, alternatives, and data-state caveats for a complex 11-parameter analytics tool. An agent can invoke it correctly from this text alone.

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

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

Schema description coverage is 0%, so the description must carry all 11 parameters – and it does: each one gets a meaning, default, accepted values, and in several cases a format example (YYYY-MM-DD, dimensions list, filter object). The schema alone would be nearly unusable without this text.

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 line states exactly what is returned – top queries/pages/countries/devices/dates with clicks, impressions, CTR and position – which is a specific resource and metric set. It does not use an explicit verb and only partially distinguishes itself from siblings (advanced/export are named only inside the row_limit note), so it falls just short of a 5.

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

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

Row_limit guidance explicitly routes large pulls to get_advanced_search_analytics or export_search_analytics, and summary_only is flagged as the cheapest call. It lacks explicit 'when not to use' guidance relative to get_performance_overview or compare_search_periods, but the alternatives for scale are clearly stated.

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

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

Annotations already declare this a safe, idempotent, read-only, open-world query, so the safety profile is covered. The description adds some genuine behavior: exact-match page_url semantics, a 25000 row ceiling, and the allowed search_type values. It says nothing about rate limits, quota cost, or authentication beyond the GSC_SITE_URL default.

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 purpose sentence is front-loaded and the argument list is terse, with zero filler. The Python-docstring 'Args:' formatting is functional rather than polished, but nothing wastes space.

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 an output schema present, return values need not be described, and the description covers purpose plus all parameter semantics for a five-parameter tool. What remains thin is the surrounding context an agent might want: which property is actually queried when site_url is null, and whether results are paginated or capped in practice.

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 0%, so the description must carry the load, and it does: every one of the five parameters is explained with meaning and default (site_url falls back to GSC_SITE_URL, page_url is an exact match, days defaults to 28, row_limit defaults to 20 with a 25000 cap, search_type enumerates web/image/video/news). The search_type values are especially valuable since the schema defines no enum.

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 line names a specific verb and resource: search queries driving traffic to one specific page. That is clearly distinct from site-level siblings like get_search_analytics. It stops short of naming the alternative tool the way a 5 would, but the scope is 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?

Usage is only implied: 'one specific page' plus the required-ish page_url (exact match) signal a per-page drill-down. There is no explicit statement of when to prefer this over get_search_analytics or get_advanced_search_analytics, and no exclusions or prerequisites.

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 read-only, idempotent, non-destructive, open-world behavior. The description adds useful content detail about permission and verification/ownership information plus the environment-variable default, but does not mention permission requirements, rate limits, or other behavioral constraints.

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 purpose is front-loaded in the first sentence, followed by focused parameter guidance. There is no filler, and the Args section is short and directly useful.

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 tool with rich annotations and an output schema, the description gives enough to call it correctly, including the default and expected identifier format. The main remaining gap is explicit routing guidance among related property tools.

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

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

Schema description coverage is 0%, so the description carries the full burden for site_url. It compensates well by explaining the exact property format, giving examples for URL-prefix and domain properties, pointing to list_properties as the source, and documenting the GSC_SITE_URL default.

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 clear verb/resource intent: retrieving permission level and verification/ownership details for one property. It is specific enough to distinguish it from broader summary or analytics tools, though it does not explicitly contrast with siblings like get_site_summary or get_capabilities.

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

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

Usage is implied by the purpose, and the description helpfully says the site_url should come from list_properties. However, it does not explicitly state when to choose this tool over get_site_summary, get_capabilities, or other property-related siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds some useful context about what information is returned (errors, warnings, content breakdown), but discloses nothing about auth requirements, rate limits, or what happens with an invalid/unknown sitemap_url.

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

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

Front-loaded with the payload summary, followed by a compact Args block. Every line carries information; only minor waste is the 'Args:' formatting of what could be a single sentence.

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?

Output schema exists so return-value documentation is not required, and both parameters are addressed. For a two-param, annotation-rich read tool this is essentially complete; only edge-case behavior (missing/invalid sitemap) is absent.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden — and it does reasonably well: site_url is described as the exact property with a GSC_SITE_URL default, and sitemap_url as the full sitemap URL. It doesn't explain the interaction between the two or the empty-string default for sitemap_url, keeping it from a 5.

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

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

States a specific verb-resource pair ('Details for one sitemap') and enumerates the fields returned (type, processing status, timestamps, errors, warnings, content breakdown). The word 'one' implicitly differentiates it from the plural listing siblings (get_sitemaps, list_sitemaps_enhanced), though no sibling is named.

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

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

Usage is implied: the parameter docs indicate you supply an exact sitemap URL to drill into a single entry. However, there is no explicit when-to-use vs get_sitemaps / list_sitemaps_enhanced guidance, nor any note on fallback behavior when sitemap_url is omitted (its default is an empty string).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that results include error/warning and download metadata, which signals this is a diagnostic read rather than a mutation, but it says nothing about pagination, ordering, or behavior on properties with no sitemaps.

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

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

A single front-loaded sentence delivers the payload contents, and the Args block is minimal. The formatting is slightly awkward (bare 'Args:' with a tab-indented line), but nothing is padded.

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 a rich annotation set and an output schema present, return-value explanation is not needed, so the remaining burden is routing and parameter format. The definition leaves the sibling disambiguation and property-format question unanswered, which are the two gaps most likely to cause a mis-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?

Schema coverage is 0%, so the description must carry the parameter information. It does add real value by noting the argument must be an exact property and that it defaults to GSC_SITE_URL, but it never shows the expected property format (URL vs. sc-domain: prefix), which is the main ambiguity for this field.

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 (submitted sitemaps) and enumerates the returned attributes (status, last download, errors/warnings, URL counts by type), so the agent knows exactly what it gets back. It stops short of differentiating itself from near-identical siblings such as list_sitemaps_enhanced, get_sitemap_details, and manage_sitemaps, leaving the agent to guess which sitemap tool to pick.

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

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

There is no statement of when to use this versus list_sitemaps_enhanced, get_sitemap_details, or manage_sitemaps, despite four sitemap-related siblings in the toolset. The only guidance is the implicit 'all sitemaps' scope, which the agent must infer.

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 confirm read-only status, but the description adds critical behavioral context: the tool performs a comparison between 'this period vs the previous period of the same length'. This explains the logic of the output beyond simple data fetching.

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 structure is highly effective, using a brief preamble followed by a clear, parsable list of Arguments. Every sentence serves to define the tool's identity or parameters.

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 comprehensive regarding the data it returns (headlines, % changes, daily data) and the controls available to the user. It is complete for a summary report, even if the output format is complex.

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?

Given the 0% schema description coverage, the description is perfect. It defines the semantics for all three parameters: providing an exact property identifier, specifying the time window, and listing all valid 'search_type' options.

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 provides a high-level summary of the tool's output ('Headline summary: this period vs the previous period...'), which clearly differentiates it from a raw data retrieval tool like 'get_search_analytics'. It defines the resource (site data) and the core function (comparative summary).

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 definition provides no guidance on when to use this tool relative to alternatives. For example, it does not distinguish when a user should use this summary versus fetching detailed analytics via 'get_search_analytics' or 'get_site_details'.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds useful defaults such as site_url falling back to GSC_SITE_URL and include_raw returning Google's raw response, but does not cover permissions, rate limits, or pagination.

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 front-loads the tool scope in one sentence and then gives a compact Args block with no filler. It is dense but appropriately sized for a multi-facet inspection tool.

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 an output schema present and annotations covering safety behavior, the description supplies enough parameter semantics and scope for correct invocation. The main remaining gap is routing guidance versus similar sibling tools, so it is not completely self-contained.

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

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

Schema description coverage is 0%, but the description documents all four parameters: site_url as exact property with a default, page_url as the full URL that must belong to the property, language_code as optional with an example, and include_raw with its default. This fully compensates for the schema's lack of parameter 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?

Names a specific verb and resource and enumerates inspected facets, making the scope clearer than a generic URL status check. It does not explicitly distinguish itself from siblings such as check_url_status, batch_url_inspection, or get_index_coverage, so sibling differentiation is incomplete.

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

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

No sentence states when to use this tool instead of check_url_status, batch_url_inspection, get_index_coverage, or get_mobile_issues. The label 'Full URL Inspection' implies comprehensive single-URL use, but comparative routing guidance is absent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is fully covered. The description adds that each dimension is returned with an explanation, but does not add other behavioral context such as whether the list is static or dynamic.

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?

It is a single front-loaded sentence that enumerates the key return items without waste. Nothing is repeated unnecessarily and the purpose is 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?

Given a zero-parameter read-only tool with rich annotations and an output schema, the description is largely complete. It could be improved by noting its relationship to list_available_metrics, but nothing needed to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. Baseline 4 applies.

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

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

It states a specific verb ('List') and resource ('Search Analytics dimension') and enumerates the dimensions returned, making the tool's function unambiguous. It does not explicitly distinguish itself from the sibling list_available_metrics, but the domain term 'dimension' does most of the work.

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 usage for discovering available dimensions and their meanings, but it gives no explicit when-to-use guidance, exclusions, or alternative tools. An agent must infer that this is the discovery counterpart to list_available_metrics.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the exact content of the response (four named metrics plus their units), which goes beyond what the annotations say.

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

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

A single sentence with zero filler that front-loads both the action and the enumerated return content. Nothing could be removed without losing information.

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

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

For a zero-parameter static reference tool with a full output schema and complete annotations, the description covers everything an agent needs to decide to call it and understand the result. There is no hidden behavior or complexity left unexplained.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly says nothing about inputs, matching the empty 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 ('List') and resource ('Search Analytics metrics') and even enumerates the exact four values returned with their units, so an agent knows precisely what it gets. It does not explicitly differentiate itself from the sibling list_available_dimensions, which keeps it from a 5.

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

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

There is no explicit when-to-use statement or reference to the analytics tools (get_search_analytics, get_advanced_search_analytics) this list feeds into. Usage is implied only by the tool's self-evident reference nature.

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 structurally. The description adds no behavioral context of its own — nothing about whether the option set is static, environment-dependent, or account-scoped, which matters for an enumeration tool whose values may vary by property.

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?

It is short and front-loads the categories, but it is delivered as a comma-separated fragment with no leading verb, so it reads as a label rather than a sentence explaining the tool. Some listed items ('common search appearances') are ambiguous without framing.

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 an output schema present, the description needn't explain return values, and the category list is an adequate preview of the payload. The only meaningful gap is the missing cue about when in a workflow to call it, which is a usage concern more than a completeness one.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

The description is a noun phrase enumerating content categories (filter operators, search types, device values, data states, example filters) rather than stating a verb+resource action like 'returns the valid values for...'. It gives the agent a reasonable idea of what comes back and is filter-specific enough to separate it from list_available_dimensions / list_available_metrics, but the purpose is implied rather than stated.

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

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

There is no statement of when to call this versus the sibling enumeration tools (list_available_dimensions, list_available_metrics), nor any hint that it should be consulted before building a filtered query. The agent must infer usage entirely from the name.

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

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

Annotations already establish readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds useful context by stating that the result includes the permission level and that this is the entry point for obtaining site_url, though it does not discuss any rate limits or access-failure behavior.

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

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

Two concise sentences, front-loaded with the core purpose and followed immediately by the actionable usage instruction. No wasted language.

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 list tool with an output schema, annotations, and a clear prerequisite, the description provides everything needed to decide when and how to call it. Return-value details are appropriately left to the output schema.

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

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

There are zero parameters, so there are no parameter semantics to explain. Baseline 4 is appropriate for a parameterless tool.

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

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

The description names a specific verb and resource ('List all Google Search Console properties (sites)') and clarifies scope with 'you can access'. This clearly distinguishes it from sibling mutation tools like add_site or delete_site and from detail-oriented tools like get_site_details.

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 to obtain the exact site_url needed by other tools, giving a clear precondition for use. This is strong routing guidance that an agent can act on directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only 'with pending counts' as extra behavioral detail, and nothing about the GSC_SITE_URL fallback behavior at runtime or any rate-limit/quota considerations.

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

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

One front-loaded summary sentence followed by a short args block; no filler. The 'Args:' formatting is slightly redundant with the schema, but the parameter notes themselves carry information the schema lacks.

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?

An output schema exists, so return values need not be explained, and both parameters are meaningfully described. The remaining gap is sibling disambiguation against get_sitemaps and get_sitemap_details, which matters given several overlapping sitemap tools in the toolset.

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 0%, so the description carries the burden and mostly does: site_url is described as an 'Exact property' with a GSC_SITE_URL default, and sitemap_index as an optional index URL whose children are returned. Missing only format examples (e.g., 'sc-domain:' vs 'https://' property forms).

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 ('Detailed sitemap list') plus a scope variant ('children of one sitemap index') and an output characteristic ('pending counts'). It does not, however, distinguish itself from the sibling tools get_sitemaps and get_sitemap_details, which an agent could easily confuse with this 'enhanced' listing.

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 word 'optionally' hints at the two modes, but there is no explicit when-to-use guidance, no statement of when to prefer this over get_sitemaps or get_sitemap_details, and no prerequisites (e.g., auth or site access). The agent must infer routing from the name alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is mostly carried structurally. The description adds nothing about side effects — e.g. that submit notifies Google, that delete unsubmits the sitemap from the property, or any auth/PROPERTY-ownership requirement — and its 'delete' action sits in mild tension with destructiveHint=false (defensible only if delete merely unsubmits).

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

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

Front-loaded one-line summary followed by a tight per-parameter list; everything is scannable. The action values are stated twice (summary line and args), a small redundancy that keeps it from a 5.

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?

An output schema exists, so return values needn't be explained, and the parameter notes cover the conditional shape of the call. What is missing is the routing information an agent actually needs: this tool's four actions duplicate five sibling tools, and the description never says which path to prefer.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does reasonably: it documents the GSC_SITE_URL default for site_url and the conditional requirement of sitemap_url per action, which the schema does not express at all. Remaining gaps are the vague 'Optional index URL for action=list' and no format hints for sitemap_url or the action values beyond a bare enumeration.

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 first sentence states a specific verb+resource (manage sitemaps) and enumerates the four operations, so an agent immediately knows it is a multi-action sitemap CRUD tool. It does not, however, distinguish itself from the many overlapping siblings (get_sitemaps, list_sitemaps_enhanced, get_sitemap_details, submit_sitemap, delete_sitemap), which is the difference between a 4 and a 5.

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

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

Usage is only implied: the args list states that sitemap_url is 'Needed for details, submit and delete', which does route the agent per action. But there is no guidance on when to use this all-in-one tool versus the dedicated siblings that perform the same four operations, and no prerequisites or exclusions are given.

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

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

Annotations already declare non-read-only, non-idempotent, open-world, non-destructive semantics; the description adds the useful context that the current session is terminated and an interactive browser sign-in is launched. It does not say what happens after the browser flow completes (whether tokens are refreshed automatically or the agent must re-poll), which is the main remaining gap.

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

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

A single sentence that front-loads the concrete action and follows with the when-to-use list — no filler, nothing repeated from the schema or annotations.

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

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

An output schema exists, so return values need no explanation, and with zero parameters there is little else to document. The description covers action, scope, and triggers; only the post-flow outcome (does the caller need to retry?) is left implicit.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The '(OAuth only)' qualifier correctly signals there is no credential/account argument to pass.

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 concrete actions — sign out, then reopen the Google sign-in page — for a named credential mechanism (Google OAuth). The parenthetical '(OAuth only)' plus the three scenarios separate it from setup_gsc_access and the read-only reporting 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?

Explicitly enumerates the triggering conditions: first-time login, expired tokens, and switching Google accounts, and restricts scope to OAuth. An agent knows precisely when to choose this tool rather than setup_gsc_access or a data-fetching 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=false, idempotentHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds real value beyond that: only file PATHS are stored (never key contents), and `save` persists paths to config.json so they survive restarts — meaningful side-effect and privacy context.

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?

Opens with the action and its key constraint (no config edits, no restart), then a compact Args block. Every line carries information; nothing is padded or repeated from the schema verbatim without added 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?

Complete enough for an agent to call it: side effects (config.json persistence), security (paths only), and the interactive fallback are all covered, and an output schema exists so return values need no explanation. It stops short of saying whether credentials are validated on the spot or what happens on failure.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does: every one of the five parameters is explained, including that auth_method is auto-detected from the file if omitted, that credential params are absolute paths, and that save defaults to true.

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: configuring/repairing Google Search Console access, done 'in-chat, without editing config files or restarting'. It's clearly a setup/repair tool rather than a data-reading one, though it never names the related sibling `reauthenticate`, which an agent could easily confuse it with.

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

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

Gives explicit usage modes: pass values directly, or call with no arguments when the client supports interactive prompts. That covers the main invocation patterns and implies the 'access is broken or unconfigured' trigger, but it offers no exclusions and does not contrast with `reauthenticate`.

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 non-destructive behavior, so the safety profile is covered. The description adds useful content context that the tool returns the "full step-by-step playbook," but says nothing further about response detail, skill availability, or failure behavior when an id is unknown.

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 purpose sentence is front-loaded and the argument note is short, with only minor docstring boilerplate ("Args:") adding a little noise. Nothing is bloated or redundant.

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

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

With one required parameter, an existing output schema, and rich read-only annotations, the description covers the essentials an agent needs to invoke it. It would be slightly stronger with a note on where skill ids come from beyond the examples, but the remaining gap is small.

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 0%, so the description must carry parameter meaning; it does by identifying skill_id as a skill id sourced from skills_list and giving two concrete examples. That is meaningful compensation for a single-parameter tool, though it does not describe format constraints beyond the examples.

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?

It states a specific verb and resource ("Return the full step-by-step playbook") and scopes it to "one skill," which is enough to separate it from skills_list. Sibling differentiation is implied via the skill_id provenance rather than stated outright for the rest of the toolset, so it stops short of a 5.

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

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

The description makes the lookup flow explicit: the agent learns to get ids from skills_list and then call this tool. There are no stated exclusions or alternatives beyond that, so it is a solid 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, and an output schema exists, so the safety and return-shape burden is not on the description. The description adds only that the items are bundled playbooks with a follow-up read path; it says nothing about ordering, count, or whether the list is static.

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

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

One sentence, front-loaded with the verb and resource, then the follow-up pointer. No filler and nothing repeated from the annotations.

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

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

With zero params and an output schema present, the description needs only to say what is listed and where to go next, which it does. It omits only minor context such as whether the set is fixed or whether every playbook requires additional inputs.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and empty, consistent with the description.

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

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

States a specific verb (List) and resource (bundled SEO playbooks), and enumerates the playbook categories so an agent knows the payload before calling. It also distinguishes itself from skill_read, which retrieves a single playbook.

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?

"Read one with skill_read" explicitly routes the agent to the follow-up tool, making the list-then-read workflow clear. It stops short of stating when this tool should be skipped (e.g., if the playbook name is already known), so it is clear but not exhaustive.

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

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

Annotations already specify that the tool is a non-read-only, open-world, idempotent, non-destructive operation. The description adds useful context such as the default for site_url (GSC_SITE_URL) and an example sitemap URL format, but it does not explain permissions, rate limits, or what resubmission changes behaviorally.

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 short and front-loaded with the core action. The Args section is useful given the schema has no parameter descriptions, and there is no obvious 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?

An output schema exists and the annotations cover safety and idempotency traits. The description adds enough parameter context and default behavior for an agent to invoke the tool, though it could mention permission or auth requirements for a mutation-like submission action.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It documents both parameters: site_url is described as the exact property and defaults to GSC_SITE_URL, while sitemap_url is described as a full URL with a concrete example. It could say more about the empty-string default for sitemap_url, but it substantially compensates for the schema gap.

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

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

The description states a specific verb and resource: 'Submit a new sitemap or resubmit an existing one.' It also distinguishes the two main modes, new versus resubmit. However, it does not explicitly differentiate itself from closely related siblings such as manage_sitemaps or delete_sitemap.

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

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

The description gives implied usage context by saying it is for submitting a new sitemap or resubmitting an existing one. It does not mention when to use this instead of manage_sitemaps, get_sitemaps, or other sitemap-related siblings, nor does it describe exclusions or prerequisites.

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