SEO GSC Wizard MCP

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

Annotations only declare readOnlyHint=false and destructiveHint=false, which the append semantics are consistent with. The description adds the genuinely non-obvious behavior: rows are APPENDED and never deduplicated, so re-sending the same list stores it twice. That is exactly the kind of side-effect disclosure annotations cannot carry.

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

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

Three sentences, all load-bearing: purpose, workflow relationship, and the append caveat. The purpose and the alternative routing are front-loaded. Minor slack only — the workflow sentence is slightly verbose relative to the rest.

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 mutating batch tool with an output schema present (so return values need no explanation), the description covers purpose, selection, grouping via `label`, and the append/duplicate hazard. It omits the 10,000-item batch cap in `redirects` and any permission/auth expectations, which keeps it short of complete.

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

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

With schema coverage at 75%, the schema already explains each field, and the description adds conceptual meaning by defining A as source and B as target and explaining that `label` keeps several migrations apart on one account. It does not add syntax-level detail beyond that, so it lands just above the baseline rather than at the top.

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 gives a specific verb and resource ('Saves redirect mappings (old URL -> new URL) for a site migration') and pins the scope to the source/target property pair. It clearly separates this write tool from compare_migration (the read) and delete_migration_redirects (the clear), so an agent can distinguish it from siblings without opening the schema.

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

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

It states when to reach for this tool versus alternatives ('use compare_migration for the before/after performance read, and these mappings to record which old URL became which new one') and names the prerequisite cleanup path ('clear a set first with delete_migration_redirects if you are re-uploading'). Nothing about tool selection 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 only cover the safety profile (readOnly=false, destructive=false, openWorld=true); the description adds meaningful behavior beyond them: rejection semantics for unverified properties, idempotent success with alreadyRegistered: true, and URL normalization (case-insensitive scheme/host, trailing slash added). This is exactly the extra context annotations cannot convey.

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

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

Purpose and the key precondition are front-loaded, and each sentence carries distinct information (precondition, non-provisioning, URL formats, idempotency). It is slightly dense, but there is no filler or repetition.

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

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

With an output schema present, return values need not be explained, and the description still notes alreadyRegistered for the idempotent case. The one real gap is the undocumented `tags` parameter, which an agent would have to guess at.

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 thoroughly documents siteUrl (URL prefix vs sc-domain form, case-insensitivity, trailing-slash normalization), but the second parameter `tags` is never mentioned, leaving it undocumented in both schema and 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 (registers) and resource (a GSC property the user already has access to) inside GSC Wizard, and explicitly contrasts it with provisioning ('It is not provisioned by this call'), which cleanly separates it from create_gsc_property. An agent can identify the operation without opening the schema.

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

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

Gives clear preconditions: the property must already appear in Search Console and be VERIFIED for the connected account, and an unverified property is rejected. It also explains idempotent behavior when the property is already registered. It stops short of explicitly naming an alternative tool (e.g., create_gsc_property) for unverified or new properties.

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 write access and open-world behavior, but the description adds substantial non-obvious behavior: tracker auto-creation, domain ownership requirement, the 1,800-URL cap with skipped-and-reported overflow behavior, and initial 'pending' status. This is rich disclosure beyond the annotations, with no contradictions.

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

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

Four tight sentences, front-loaded with the core action and side effect, then constraints, then next-step guidance. Every sentence adds useful information with no redundancy.

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

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

An output schema exists and the description still explains key operational behavior: auto-creation, domain constraint, cap enforcement, overflow reporting, and pending state. Together with annotations, an agent has what it needs 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 coverage is 0%, so the description must compensate for both parameters. It implies that siteUrl identifies the property and that urls must belong to that property's domain, and explains the 1,800-URL limit, but it does not define the exact expected format or source for siteUrl, leaving some ambiguity.

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

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

States a specific verb and resource: adds URLs to the GSC Wizard Indexing Tracker for a property, including tracker auto-creation. It is clearly distinguishable from siblings like list_tracked_urls, remove_tracked_urls, and check_tracked_url_now.

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

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

Provides clear context for using this tool to populate the indexing tracker, and explicitly routes the agent to check_tracked_url_now for immediate inspection or to the hourly cron for later checks. It does not, however, compare against other sibling URL-submission tools such as submit_indexnow_urls or bulk_inspect_urls, or state when not to add URLs.

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 only declare readOnly/openWorld/non-destructive, and the description goes well beyond that: it discloses the two data sources (ClickHouse warehouse vs live Search Console API), each one's cut (10,000 queries / 25,000 page-query rows vs top 25,000 rows by clicks), the 50-page cap with pageCount covering unlisted pages, and the one-shot minImpressions relaxation reported via minImpressionsAutoRelaxed. It stops short of stating auth/permission requirements or expected latency, so it is not a full 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?

Front-loaded correctly — purpose and ranking semantics come first, operational caveats after. But it is a single dense paragraph that partly duplicates schema text (minImpressions default of 10 and the auto-relax rule, the 28-day default window) and buries the warehouse-vs-live-API distinction mid-sentence, making it harder to scan than its content warrants.

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

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

For a tool with an output schema, this is more than complete: it explains the score's meaning, the per-page ordering, ctr as 0-100, the truncated/scanLimit semantics, and the known under-count of totalClicks/totalImpressions relative to page sums. Nothing an agent needs to call it correctly or interpret the result is missing.

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

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

Schema coverage is 67%, and the description fills the important gaps: minImpressions applies to the query's own figure (not the sum of page figures), defaults to 10, and is auto-relaxed to 1 when nothing qualifies; date range is optional with a 28-day settled default. `limit` is never explained in either the description or the schema, which is the one remaining hole.

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

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

Opens with a specific trigger and verb+resource: 'Use this when the user asks whether several of their pages compete for the same query', and immediately defines the output ordering (cannibalization score from Shannon entropy over impressions, highest first, then totalImpressions). It explicitly names the sibling it is not (query_search_analytics), so the agent can disambiguate without opening a schema.

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

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

Explicit when-to-use ('whether several of their pages compete for the same query'), explicit when-not ('Not for a plain page-by-query table: use query_search_analytics'), and routes a related question to a third tool ('analyze_sampling_impact measures it'). Also states the default date window and that omitting dates is the normal path.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description does add real behavioral context beyond that, but the vast majority of its extra text (bucket fields, deltas sign, percentage units, truncated/scanLimit flags) describes return-value semantics rather than invocation behavior — and return values are already covered by the existing output schema, which lowers the incremental value here.

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?

All the content is useful, but it is delivered as a single dense run-on paragraph of roughly 250 words with no structure, and the minImpressions default/retry explanation partly repeats the schema description verbatim. The usage trigger is front-loaded, which helps, but readers must wade through return-field commentary to find it.

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

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

For a tool with six parameters, two enums, dual data-source paths and an output schema, the description covers data source, truncation behavior, sampling caveats and date defaults well. Remaining gaps are minor, e.g. no note on expected response size or latency for the live-API fallback.

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 67% and one enum in particular, benchmarkSource, carries no schema description at all; the description compensates by spelling out each source (awr, awr2026, awrAio, firstPageSage, sistrix, backlinko, 'all') and the awr2026-vs-awrAio comparison being the AI Overview click tax. It also clarifies minImpressions auto-relax behavior and the date-range default, though it does not add anything for siteUrl.

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 verb-and-resource pair: builds the property's CTR curve by average position in buckets 1-20 and compares each bucket against industry benchmarks. It also explicitly contrasts itself with siblings (find_page_poaching_opportunities for which queries to work on, analyze_sampling_impact for click coverage), so an agent can route without opening a schema.

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

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

Opens with the triggering user question ('whether their CTR is normal for where they rank') and gives an explicit exclusion with the correct alternative named. It further clarifies which measurements this tool does and does not cover by pointing to analyze_sampling_impact.

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

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

Goes far beyond the readOnly/openWorld annotations: discloses the 27-language heuristic pattern matcher and its epistemic limit ("judges how a query LOOKS, not what the searcher meant, so treat single rows as evidence rather than proof"), the ClickHouse-then-live-GSC data path, the ~2-3 day data lag, and the visible-queries-only share caveat with coverage.hiddenClicksShare. Ordering semantics (bucketOrder, examples by impressions) and the aiShaped roll-up are also stated.

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 trigger and the alternative, then the bucket taxonomy, then caveats — a sensible information hierarchy. It is dense and long for a single paragraph, with the return-shape details packed tightly enough to slow scanning, but no sentence is filler.

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

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

Covers everything an agent needs to call and interpret this correctly: trigger, sibling routing, bucket vocabulary, date defaults, data source fallback, lag, coverage caveat, and the heuristic's reliability limits. An output schema exists so return values needn't be explained, yet the description still frames the key fields usefully.

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 already 83%, so the baseline is 3; the description still adds real meaning by defining what each bucket name actually contains ("reply artefacts ("yes", "show me"), pivot follow-ups...") rather than leaving the enum opaque. It also reinforces the optional date-range default (omit both → last 28 settled days), though it does not add anything on searchType or examplesPerBucket beyond the schema.

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

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

Specific verb+resource: classifies query rows by SHAPE (AI Mode / AI Overview fan-out) against the app's Query Analysis report. It immediately distinguishes itself from the sibling get_query_shape_trend and from query_top_queries-style tools by naming the SHAPE lens 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?

Opens with an explicit trigger ("Use this when the user asks whether AI Overviews / AI Mode fan-out shows in a property's queries") and an explicit exclusion with the correct alternative ("Not for change over time: use get_query_shape_trend"). Nothing about when-to-use 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 cover the safety profile (readOnly, non-destructive), but the description adds real behavioral context: data lags ~2-3 days, the warehouse mirrors what the API returned, shares are 0-1 vs missingClicksPercent 0-100, and null signals an inseparable path. Slightly dense but genuinely beyond annotations.

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

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

Front-loaded with the 'use this when' trigger, then mechanism, then field interpretation, then exclusions. Dense but each sentence carries signal; the output-field unpacking borders on verbose for a description when an output schema exists.

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?

Even though an output schema exists, the description makes the return values interpretable (what gap/anonymisedShare/truncatedShare mean, unit scales, dataSource path). Nothing needed to call or interpret the tool is missing.

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

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

With 75% schema coverage the schema documents siteUrl, startDate, endDate, and the searchType enum in detail; the description mostly restates the date-lag/omit-default rule the schema already covers. Its richer text describes output fields (gap, anonymisedShare, truncatedShare) rather than clarifying input parameters.

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 analytical purpose (quantify hidden traffic) with a precise mechanism: compares per-day totals against summed query and page rows, gap being rowless traffic. It explicitly distinguishes itself from the sibling get_site_summary, so an agent can route correctly.

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?

Opens with the triggering user question ('how much of a property's traffic is hidden'), and states the negative case: 'Not for the totals themselves: use get_site_summary.' It also gives default behavior for the optional date range (omit to get last 28 settled days).

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 readOnly/openWorld annotations, it discloses real operational behavior: pages are fetched live, the run stops after ~50 seconds, and truncated=true means the URLs in notAudited still need a follow-up call. It also states result ordering (issueCount, then impressions) and the constraint that URLs must belong to the property — none of which the annotations convey.

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

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

Front-loaded with the trigger and purpose, then scope, then pagination/continuation semantics, then the sibling exclusion — a sensible order. The single long enumeration of audited checks is dense but earns its place by telling the agent what the report will contain.

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 described; instead the description covers what the agent can't infer — ordering, truncation, and the continuation pattern. For a live-crawl tool with a time budget, that is the hard part and it is handled.

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 75%, and the description adds meaning the schema does not: URLs must belong to the property, top pages are picked by Search Console impressions, and notAudited can be fed back into `urls` for a continuation run. The maxUrls/minImpressions auto-pick knobs are left to the schema, which documents them adequately.

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?

Specific verb + resource (“runs a technical on-page/SEO audit per URL”) with an enumerated scope of what's checked. It explicitly distinguishes itself from inspect_url, which is the nearest sibling, so an agent can separate the two without consulting either schema.

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

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

Opens with the triggering condition (“Use this when the user asks for a technical or on-page SEO check of specific pages or of the top pages”) and closes with an explicit exclusion plus the named alternative: “Not for whether Google indexed a URL: use inspect_url.” Both when-to-use and when-not-to-use are stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial context beyond them: the dual data source (ClickHouse vs live Search Console API with a 25,000 page-row cap), the meaning of the `truncated` flag, and the instruction to quote totals from `coverage.siteTotals` rather than summed groups. It also discloses data lag (~2-3 days) and the 28-day default window, which materially affect interpretation.

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 trigger and the exclusion, then mechanics, then caveats in a logical order. It is dense but nearly every clause carries decision-relevant information; the only slight excess is restating return fields (clicks, impressions, CTR, position) when an output schema already exists.

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

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

Covers everything an agent needs to call and interpret it: grouping semantics, default window, data lag, source fallback with row caps, truncation signaling, and which totals field to trust. An output schema exists, so the extra return-value detail is bonus rather than a necessity, and nothing material is missing.

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

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

Schema coverage is 50%; the schema documents startDate, endDate, and searchType but leaves depth, limit, and siteUrl bare. The description compensates well for the most semantically ambiguous parameter, spelling out depth 1 -> /folder and depth 2 -> /folder/subfolder, and reinforces the optional-date semantics. It says nothing about `limit` (default 100, max 1000), which is the remaining documented 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?

States a specific verb (aggregates) and resource (page-level performance grouped by subdomain plus first-folder), and immediately scopes it with 'Use this when the user asks how a site section, folder or subdomain performs.' It explicitly excludes single-page use and names query_top_pages as the alternative, so an agent can distinguish it from siblings without opening any schema.

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

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

Provides an explicit trigger ('when the user asks how a site section, folder or subdomain performs') and an explicit anti-trigger ('Not for single pages: use query_top_pages'), plus default behavior when dates are omitted. The when/when-not/alternative triad is fully present.

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 only cover read-only/open-world/destructive flags, and the description adds far more: the 2,000-per-property-per-day cap shared with the UI, mid-run stop behavior, the shape of partial results (skipped URLs with skipReason, stopReason, retryAfterSeconds on Google rate limits or permission refusals), and the ~7s/5-concurrent timing model. This is exactly the operational context annotations cannot express.

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

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

Front-loaded with the primary action and its persistence behavior, then layers quota, failure mode, and timing details in order of usefulness. The closing sentence packing add_tracked_urls, Indexing Tracker, and check_tracked_url_now is dense but each clause earns its place; slightly long overall.

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, yet the description still previews the meaningful return fields (verdict, coverage, canonicals, Search Console link, skipped/stopReason), so an agent knows both how to call it and what to expect. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 50%: 'urls' is documented in the schema (maxItems 25, pointer to add_tracked_urls), while 'siteUrl' has no schema description. The description compensates by framing siteUrl as the property ('per property per day', 'property-level permission refusal'), clarifying its meaning beyond the bare string.

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 ('Runs the Google URL Inspection API against a list of URLs') and immediately distinguishes itself from the single-URL sibling by scope ('list of URLs') and by side effect ('persisting each result to GSC Wizard's inspection history'). It also names the role each related tool plays (get_inspection_quota, add_tracked_urls, check_tracked_url_now), so an agent can place it in the family without opening schemas.

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

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

It gives explicit routing rules: call get_inspection_quota first for headroom, use this tool for sets of up to 25, and switch to add_tracked_urls for larger sets so the Indexing Tracker runs them in the background. That is when-to-use plus the concrete alternative, not just implied context.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds substantial behavior beyond them: the 2,000-inspection daily quota and its exhaustion response, 5-at-a-time batching at ~7s each, rate-limit handling via skipped/retryAfterSeconds, untouched-on-skip semantics, and audit-logging. This is exactly the operational context an agent needs before invoking a quota-consuming write.

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?

Though dense at roughly six sentences, the purpose is front-loaded and each subsequent sentence conveys distinct operational detail (quota, batching, skip semantics), so little is wasted. It is information-rich rather than 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 enumerated, yet the description still flags the canonical fields and null case. Combined with the quota, rate-limit, and audit-logging behavior, an agent has everything needed to call this correctly and interpret partial results.

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 partially does: 'up to 10 tracked URLs' clarifies the urls array bound, and 'per property' hints that siteUrl is the GSC property. But neither parameter's format or accepted values is explained, so the schema remains largely silent.

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+resource: triggering an immediate Google URL Inspection for up to 10 tracked URLs, plus the side effect of updating status, warnings, and history. It scopes to 'tracked URLs in the GSC Wizard Indexing Tracker,' which implicitly separates it from generic inspect_url/bulk_inspect_urls, though those siblings are not 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?

'Use sparingly; the app's hourly cron checks tracked URLs automatically' gives a clear when-to-use constraint and an implicit when-not (don't manually re-run what the cron covers). However, it never names inspect_url or bulk_inspect_urls as alternatives, so the routing between inspection tools 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 only cover safety (readOnly, non-destructive, open-world); the description adds substantial behavior beyond them: how goLiveDate flips the tool into a before/after read, how windowStrategy and windowDays shape the windows, what extra fields appear (windows, recoveryPct, trend buckets), the 25,000-row and 2,000-char regex caps with truncation flags, the ~2-3 day data lag, and the ClickHouse-vs-live-API fallback.

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 front-loaded with purpose, then modes, then conditional behavior, and no sentence is filler given the tool's complexity. The weakness is structural: it is one very dense paragraph with no separation for the goLiveDate branch or the caveats, which makes it harder to scan than it needs to be.

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 14-parameter tool with an output schema, the description covers everything an agent needs to call it correctly: mode prerequisites, date handling and defaults, window semantics, caps and truncation, data freshness, and the visible-queries caveat with a pointer to analyze_sampling_impact. Nothing material is left to inference.

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

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

Schema coverage is 100%, so the schema already documents each field; the description nonetheless adds cross-parameter meaning the schema cannot express, notably that without goLiveDate both sides share one window while with goLiveDate they split before/after, and the exact semantics of each windowStrategy value and yoyBaseline. The per-field prose is mostly a restatement of the schema's own descriptions, which keeps this just under 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?

The opening sentence states a specific verb and resource (before/after Search Console comparison of a site migration) and enumerates the three comparison modes. It also explicitly distinguishes itself from the sibling get_migration_health, so an agent can route between the two without opening either schema.

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

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

It gives an explicit trigger ('use this when the user asks whether a migration, domain move or restructure lost or gained traffic') and an explicit exclusion with the correct alternative ('Not for the health verdict ... use get_migration_health'). The mode-selection rules (cross-property vs two-urls vs regex) and the goLiveDate vs startDate/endDate choice are also spelled out.

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

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

Annotations declare readOnlyHint=false (a write) and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the default visibility scope, how to scope to a property, and the restriction that platform-wide annotations are reserved for system events.

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

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

Three tightly written sentences with zero waste. The purpose is front-loaded, followed by scope details and a restriction, all clearly structured.

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

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

An output schema exists and annotations cover the safety profile, so return values and write safety are handled. The description fills in scoping behavior and the platform-wide restriction, but omits any mention of required parameters or the idempotency key, though those are covered by the schema.

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

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

Schema description coverage is low (43%), so the description should compensate for undocumented parameters. It only mentions siteUrl, which is already described in the schema, and provides no meaning for color, label, category, or description. For a 7-parameter tool, this leaves significant gaps.

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 ('Adds') and resource ('a chart annotation'), making the tool's purpose immediately clear. It does not explicitly differentiate from sibling tools like update_annotation or delete_annotation, but the create action 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?

It explains the default scope ('account', visible only to the user) and instructs when to pass siteUrl versus omit it. It also states a when-not condition: platform-wide annotations cannot be created via this tool, which is a clear exclusion.

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 only cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description goes well beyond by disclosing that group names are unique per site, that non-compiling regex is rejected, that valid-but-unsupported or ReDoS-skipped patterns are silently accepted as no-match, and that this is surfaced via `ruleWarnings`. That is exactly the behavioral context an agent needs and cannot get from annotations.

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

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

Four sentences, front-loaded with purpose before drill-down into rules and validation behavior. The final regex caveat is longer than average but is high-value operational detail rather than padding; nothing reads as 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 so return values needn't be covered, and the description still flags `ruleWarnings` for the agent. Combined with the regex semantics and uniqueness constraint, this is nearly complete for a create tool; only the remaining input parameters (siteUrl, color, description) are unaddressed.

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 it does well on `rules` – explaining the { type, value } shape, the four match types, and regex edge cases – plus the name-uniqueness constraint. However, siteUrl, color, and description are never addressed, leaving half the parameters documented only by their bare JSON types.

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

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

Opens with a specific verb+resource ("Creates a content group partition on a property") and immediately scopes what a group is. The verb 'Creates' cleanly distinguishes it from the sibling update_content_group, delete_content_group, and list_content_groups without needing to name 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?

The description implies usage through the rules-matching explanation, but never states when to reach for this tool versus update_content_group or when a content group is the right construct. No explicit when/when-not guidance or named alternatives; usage must be inferred.

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

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false) but the description adds genuinely non-obvious behavior: auto-verification contingent on parent-domain ownership, inheritance of the parent property's Google account, and the fact that new properties are created hidden and consume no plan slot until shown. It stops short of describing batch failure behavior or partial-success semantics for the multi-URL case.

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 action, then constraints, then the alternative. Dense and mostly waste-free, though the dashboard/plan-slot sentence and the set_dashboard_visibility pointer add length that could be tightened.

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

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

For a 3-parameter mutation tool with a full schema and an output schema, everything an agent needs to invoke correctly is present: prerequisites, domain constraint, verification behavior, visibility state, plan-slot implications, and the alternative sibling. Return values are legitimately omitted because an output schema exists.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: parentSiteUrl is 'an existing GSC Wizard property whose Google account has access' and the new properties inherit it, plus the domain/subdomain constraint and the auto-verify implication. The max-50 and URI format are restated from the schema, so it is not a full 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 and resource ('Creates one or more URL-prefix properties in Google Search Console') and names the underlying API operation (sites.add). It also explicitly distinguishes itself from the sibling add_site, which handles already-existing properties, so an agent can route between them without opening a schema.

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

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

Gives explicit when-to-use ('folder-level properties ... that do not yet exist in Search Console') and when-not ('For properties that already exist in GSC, use add_site instead'). It even points to set_dashboard_visibility as the follow-up needed to expose hidden properties, which is a real workflow cue.

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 only say readOnly=false, destructive=false, openWorld=false. The description adds genuinely non-obvious behavior: normalization to lowercase, per-account uniqueness, idempotent collision handling (returns the existing client instead of failing), and the owner email-confirmation gate on first grant. That is exactly the extra context annotations cannot convey.

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

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

Four sentences, front-loaded with the action, then side effects, then edge-case return behavior. No filler; each clause adds a fact the agent would otherwise have to discover by trial.

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

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

Covers the mutation's side effects, the prerequisite for downstream use (owner confirmation), duplicate handling, and the normalization rule. With an output schema present, no return-format explanation is needed, so nothing material is missing.

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

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

Schema coverage is 0%, so the description must carry meaning, and it does: quantifies email as unique-per-account and lowercased, and frames name as optional metadata attached to the contact. It does not mention length constraints, but those are in the schema and are low-stakes.

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

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

States a specific verb and resource ('Adds a client contact ... email address, plus an optional name') and immediately positions it against the sibling it complements (manage_report_access). An agent can distinguish it from list_report_clients and manage_report_access without opening any schema.

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

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

Explicitly states what this tool does NOT do ('Adding a client does NOT email them and does not give them access to anything on its own') and names the sibling that performs the granting step. The when-to-use boundary is unambiguous.

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, destructiveHint=false, and openWorldHint=false, so the write/safety profile is covered. The description adds genuine behavioral context beyond that: the saved preset has no side effect on querying and simply surfaces in the property's preset list. It does not mention auth requirements or duplicate handling, which the schema partially covers via clientRequestId.

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

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

Three tightly-written sentences, each front-loaded with its point: what is stored, how the two key fields work, and the non-application caveat. No filler or redundancy.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description handles the main behavioral nuance (no implicit application) but is silent on the property/site binding and the idempotency behavior, leaving minor gaps for a 5-param write 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 60% and the description reinforces the two most complex params (`filters` rows as dimension/operator/value and `filterLogic` as AND/OR), plus a useful cross-reference that `filters` matches the shape list_saved_filters returns. It says nothing about `siteUrl`, `name`, or `clientRequestId`, so it only partially compensates for the coverage 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?

States a specific verb and resource ('Stores a filter preset against a property') and immediately clarifies the resource's nature by comparing it to the dashboard's filter panel. It does not name update_saved_filter or delete_saved_filter as siblings, so the create-vs-modify distinction is left implicit. Purpose is clear without needing the schema.

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

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

The description clarifies an important usage fact — that saving a preset does not apply it — which implicitly tells the agent this is a persistence, not a query, operation. However it gives no explicit when-to-use framing or direction toward alternatives (update_saved_filter, list_saved_filters), so usage is only implied.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description discloses the non-obvious failure mode: the returned URL opens for nobody until access is granted, because the viewer is the client portal. It also states the 50-reports-per-account quota, the delete_shared_report cleanup path, and the view-time rendering that keeps the stored payload small.

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 action and payload shape, then the critical three-step warning. The closing 'Do not hand the URL to anyone before access is granted; it will not open' restates the earlier warning almost verbatim and could be trimmed without losing information.

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

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

An output schema exists, so return values need not be spelled out, and the description still explains that the return includes a URL. For an 8-param, nested-schema write tool, the description covers the sequencing and access prerequisites that an agent could not infer from the schema 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 coverage is 88%, so the structured schema already carries most parameter meaning. The description adds real linkage semantics — that `rows` should come from another tool's output and `columns` selects which fields render — which clarifies how the two required arrays relate to each other. It does not touch the optional metadata params (siteUrl, dateRange, dataSourceType), which is acceptable given the schema documents them.

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

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

States a specific verb and resource ('Saves a table of rows as a shareable GSC Wizard report') and implicitly separates itself from list_shared_reports, delete_shared_report, and manage_report_access. An agent knows immediately this creates the artifact rather than listing or granting it.

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

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

Gives an explicit prerequisite (rows from query_top_queries or get_content_group_performance), names the exact follow-up tools (create_report_client, then manage_report_access), and warns what happens if the order is skipped. Also flags the account-owner email confirmation requirement for first-time recipients.

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 only declare generic safety hints (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds genuinely new behavioral facts: per-property name uniqueness, idempotent semantics, the alreadyExisted: true return, and that there is never anything to retry. That is exactly the mutation-behavior context an agent needs beyond the annotations.

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

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

Four tight sentences, front-loaded with the action, then idempotency semantics, then the alternative-tool pointer, then storage/matching behavior. Every sentence earns its place with no filler.

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

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

An output schema exists, so return values need not be re-explained, and the description still usefully names alreadyExisted. Combined with annotations and the alternative-tool routing, it is nearly complete; the only gap is that siteUrl semantics and the keyword/name limits are unaddressed.

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 partially does, mapping name (unique per property), keywords (stored as text, matched against GSC queries), and implying the property via siteUrl. It adds no format or constraint detail (URL shape, max 1000 keywords, max 200 chars) for siteUrl or the limits.

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 (creates), resource (topic cluster), and scope (on a property, grouping keywords under a name), so the agent knows exactly what is produced. It also explicitly names the sibling update_topic_cluster, distinguishing it from the update path.

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 when-to-use routing ("Use update_topic_cluster to change an existing cluster's keywords") and the precise condition under which the call is a no-op (name already exists returns alreadyExisted: true). Nothing about tool selection 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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds meaningful context beyond that: an ownership-based authorization constraint and the un-deletable platform-scoped class, which an agent would not otherwise know.

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

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

Two tight sentences with zero filler: the action comes first, followed immediately by the constraint that limits it. Nothing is padded or repeated from the title.

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

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

An output schema exists, so return values need no explanation, and the destructive nature plus authorization boundary are covered. It could go slightly further on failure behavior (e.g., deleting a non-owned or nonexistent id), but for a single-parameter delete this is nearly complete.

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

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

One parameter with 0% schema description coverage, so the schema supplies only the type and UUID format. The description's 'by id' adds little beyond restating the field name and does not explain where the id comes from or what happens on a mismatched id. Baseline 3 given a single, self-evident identifier.

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 ('Deletes a chart annotation by id'), which is unambiguous against the annotation siblings (create_annotation, update_annotation, list_annotations). It does not explicitly contrast itself with those siblings, but the operation's nature makes the differentiation obvious.

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 an explicit precondition and exclusion: only user-owned annotations can be removed, and platform-scoped annotations cannot be deleted via this tool. It stops short of naming an alternative path for platform-scoped deletions or clarifying when deletion is preferable to updating.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered structurally. The description adds the authorization requirement (ownership or full-access share), which is exactly the kind of permission context the annotations cannot express. It stops short of stating irreversibility or side effects on related 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?

Two sentences, zero filler: the action and key are front-loaded, and the permission constraint follows immediately. 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 one-parameter destructive delete with a rich annotation set and an existing output schema, the description covers action, key, and authorization. Return-value behavior is handled by the output schema, so nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the burden for a single parameter. 'By id' clarifies that groupId is the content group identifier, but adds no format (UUID) or lookup guidance beyond the self-evident parameter name. Minimal but not absent compensation.

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 ('Deletes a content group') plus the lookup key ('by id'), so an agent knows exactly what the operation targets. It does not name a sibling to contrast with (e.g., delete_topic_cluster, delete_saved_filter), but the resource noun alone disambiguates it within the delete_* family.

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

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

Provides a concrete precondition for use: the owning property must be one you own or one shared with full access. That is real gating context rather than implied usage, but the description names no alternative (update_content_group, list_content_groups) and gives no when-not guidance.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description goes further: it discloses that deletion is permanent, that an unnarrowed delete would also wipe unrelated migrations, and that confirmDeleteAll: true is a hard prerequisite for that path. This is exactly the collateral-damage and safety-guard context annotations cannot convey.

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

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

Three sentences, front-loaded with the destructive nature and scope, then the narrowing/guard rule, then the recommended preview step. Every sentence carries decision-relevant information with no padding.

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

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

An output schema exists so return values need no explanation. The description covers purpose, scope, all four parameters' roles, the destructive guard, and the safe workflow, which is everything an agent needs to invoke this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains the coupling between the filter params and confirmDeleteAll, and why the guard exists (unrelated migrations would be destroyed). It does not add format or syntax detail beyond that.

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 ('Permanently deletes saved redirect mappings') and is immediately distinguishable from the sibling add_migration_redirects and the read-only list_migration_redirects. No ambiguity about what operation is performed.

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

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

Explicitly routes the agent: narrow with `label` and/or the A/B property pair, pass confirmDeleteAll: true only for a full-account wipe, and preview with list_migration_redirects using the same filters first. Names both the required guard condition and the recommended alternative 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that: presets belong to the property, and deletion requires ownership or full property access, explicitly noting read-only access is insufficient.

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

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

Two tight sentences, action and key front-loaded, with the permission constraint following. The aside 'as in the GSC Wizard app' is slightly extraneous but does not harm comprehension.

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. For a destructive single-param delete, the description supplies the permission model and scope, leaving only minor gaps (where to obtain the filterId).

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?

One parameter (filterId, uuid) with 0% schema description coverage, so the description must compensate. It only says 'by id' without clarifying format, source (e.g., from list_saved_filters), or whether the id is a preset id versus a property id — minimal added meaning.

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

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

States a specific verb (deletes) and resource (saved filter preset) with the identifying key (by id). It is unambiguous against siblings such as delete_site, delete_annotation, and update_saved_filter.

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 the operation's context (removing a saved preset) and states a precondition, but never says when to delete versus update_saved_filter or list_saved_filters first. Usage is inferable rather than explicit.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the bar is lower, yet the description adds exactly the context the rubric calls for: what gets destroyed (all client grants), the blast radius (breaks the shared link for anyone who holds it), and an auth requirement (owner-only deletion). This goes well beyond the structured flags.

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

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

Three sentences, front-loaded with the irreversible action, followed by the ownership constraint and the id-sourcing hint. No sentence is redundant and each adds distinct information.

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

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

For a destructive single-parameter tool, the description covers permanence, cascade scope, ownership precondition, and id discovery, while an output schema and annotations handle the return value and safety profile. Nothing an agent needs to call it correctly is missing.

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

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

With a single reportId at 0% schema coverage, the description must carry the parameter burden. It usefully explains where to source the id (list_shared_reports), but says nothing about the expected format (uuid) or edge cases like non-existent or non-owned ids.

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 verb and resource ('Permanently deletes a saved shareable report') and immediately extends the scope to the cascading effect ('every client grant on it'). This clearly distinguishes it from create_shared_report and list_shared_reports in the sibling set.

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?

Names the alternative that supplies the required identifier ('Find the id with list_shared_reports') and states a real precondition ('Only reports owned by the authenticated user can be deleted'). It lacks an explicit when-not-to-use note, but the routing and eligibility constraint give solid guidance.

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

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

Annotations already declare destructiveHint=true and openWorldHint=false, but the description goes further by enumerating exactly what is destroyed by the cascade (topic clusters, content groups, saved filters, inspections, annotations) and clarifying the external-system boundary. That is precisely the disclosure an agent needs before invoking an irreversible mutation.

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

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

Three short sentences, front-loaded with the action, followed by blast radius and then the scope caveat and guard. No filler, and each sentence carries distinct decision-relevant 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 annotations plus the description cover safety and cascade scope. The remaining gap is that it never states whether the deletion is permanent/reversible or what authorization the caller needs, which matters for a destructive 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 50%: confirm is documented in the schema, but siteUrl is not, and the description only implies it via 'property' without giving format (URL vs. sc-domain: style identifier). Baseline 3 is appropriate since the description adds scope meaning but not parameter syntax.

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?

Specific verb+resource ('Unregisters a property from GSC Wizard') with an explicit scope boundary that separates it from the Google Search Console product itself. Among a large family of delete_* siblings, the cascade clause makes clear this is the property-level delete rather than an entity-level one.

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 a clear when-not condition ('Does NOT remove the property from Google Search Console itself') and the confirm=true guard against accidental deletes. It stops short of naming an alternative for softer operations (e.g. update_site to modify, or remove_tracked_urls to stop tracking a URL), so the agent must infer those.

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, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds an authorization precondition (property must be owned or shared with full access). However, it never states the scope of destruction — e.g. whether pages or groupings inside the cluster are removed — or that the action is irreversible.

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

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

Two tight sentences with no filler; the core action leads and the access constraint follows. Every clause carries information.

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

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

An output schema exists, so return values need no explanation, and annotations cover the destructive profile. The remaining gap is destruction scope and id provenance, but for a single-parameter delete this is close to complete.

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

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

Schema description coverage is 0% for the single required clusterId parameter. The phrase "by id" merely restates what the schema already declares (a uuid-typed identifier) and adds no format detail, no source for obtaining the id (e.g. list_topic_clusters), and no scoping context.

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

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

States a specific verb+resource ("Deletes a topic cluster by id") that cleanly separates it from the many non-topic-cluster delete siblings. It does not explicitly differentiate against update_topic_cluster/list_topic_clusters, but the resource naming makes the intent unambiguous.

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

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

The description gives no when-to-use, when-not-to-use, or alternative guidance. It does not mention update_topic_cluster as the non-destructive alternative, nor when a delete is appropriate versus leaving the cluster in place. The ownership clause is a precondition, 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 only cover the safety profile (readOnly, non-destructive, open world); the description goes far beyond by disclosing the statistical method (Modified Z-score with MAD, day-of-week baselines, MAD fallback on low-traffic properties), severity grading, output ordering (oldest first), zero-imputation for missing days, the 21-calendar-day minimum, lowVolume capping, episode grouping rules, and the ClickHouse-vs-live-API data source.

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 usage trigger and the sibling exclusion, then ordered from method to output shape to edge cases — a sensible structure for a complex tool. A few clauses repeat schema content (ctr as 0-100 percentages, the lowVolume cap), which is the only reason it is not 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?

For a five-parameter statistical tool with an output schema, the description covers everything an agent needs to call it correctly and interpret results: metric caveats, missing-day handling, volume-driven outlier suppression, episode/nextStep guidance, and coverage reporting. Nothing material is left to inference.

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 80%, so the baseline is 3; the description adds real meaning on top by explaining metric-specific interpretation (for position, 'down' is better; outcome is the good-or-bad reading) and the interplay between minImpressions, lowVolume, and severity capping. It does not elaborate on what sensitivity values imply beyond the schema's own threshold note, which keeps 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 and resource — flags statistically anomalous days in a property's Search Console metric series — and immediately names the sibling it is not (detect_change_points). An agent can distinguish anomaly detection from change-point detection without opening either schema.

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

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

Opens with an explicit trigger ('when the user asks whether something broke or spiked on a specific day') and an explicit exclusion ('Not for level shifts or gradual trends: use detect_change_points'). It also routes follow-up cases via episodes/nextStep back to detect_change_points, so both selection and hand-off are covered.

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 readOnly/openWorld annotations it discloses data-source fallback (ClickHouse when available, else live Search Console API), the 14-day spacing rule for separate breaks, zero-fill semantics for missing rows, and the changePercent-is-0-from-zero-baseline convention that would otherwise be misread. The shape taxonomy (step/gradual/ambiguous) and instruction never to describe a gradual break as a one-day event is exactly the kind of interpretive guardrail annotations cannot carry.

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-loading is strong: intent, exclusions, then output semantics. But it is a single dense block that drifts into explaining return fields (beforeMean, segmentAfter, coverage, emptyBecause) that the output schema already documents, so several sentences are duplicative rather than additive.

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

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

Covers what an agent needs to call and interpret the tool: window behavior, source fallback, zero-baseline handling, and the gradual-vs-ambiguous caveat. Slight over-completeness given the output schema exists, but no critical gap remains.

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

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

Schema coverage is 83%, so the schema already defines days, metric, startDate/endDate and sensitivity in detail. The description adds no parameter-specific syntax or defaults beyond implying the 14-day minimum via break spacing; it spends its parameter budget on output interpretation instead.

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 ('detect change points' in clicks/impressions that moved to a sustained level) and immediately names the sibling it is not ('Not for one-off spikes: use detect_anomalies; for totals use get_site_summary'). An agent can route on the first sentence alone.

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

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

Gives an explicit triggering user intent ('when the user asks when a property's clicks or impressions moved to a new sustained level'), two named alternatives with the conditions that select them, plus a fallback path when no step exists (read trendSummary, emptyBecause, strongestShiftReason).

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 only declare read-only/non-destructive; the description adds substantial behavior: default minImpression auto-relax to 10 with the minImpressionsAutoRelaxed flag, severity rules requiring both share and absolute loss, lowConfidence Poisson threshold, deterministic pattern-classification order, warehouse vs live-API scan caps, recentIsUpperBound semantics, windowNormalization, and truncated counts. This is exactly the kind of context annotations cannot carry.

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 correctly: the selection cue and date-role explanation come first. It is long and dense, though, and some implementation detail (the exact Poisson formula, warehouse row caps) is heavier than an agent needs for selection, so a little trimming would help.

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 an 11-parameter tool that switches between a warehouse and the live API and has an output schema, the description covers the traps that would cause wrong calls or wrong interpretation: upper-bound rows, unresolved keys, per-day normalization, and truncation. Nothing material to correct invocation is missing.

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

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

Schema coverage is already 82%, so the baseline is 3; the description still adds real meaning beyond the schema — which date pair is recent vs baseline, that a passed minImpressions is never auto-relaxed, that minBaselineClicks decliners land in belowClickFloor, and that sortBy ordering is largest-loss or most-negative-percentage first. Remaining gaps are minor (siteUrl and searchType behavior are left to the schema).

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

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

Opens with a specific verb+resource+user intent ('which pages or queries are losing clicks') and immediately names the baseline-vs-recent comparison model. It explicitly distinguishes itself from get_decay_overview (period matrix) and get_ranking_changes (position movers), so the agent can select it without opening any schema.

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

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

Gives explicit when-to-use ('when the user asks which pages or queries are losing clicks'), explicit when-not-to-use, and names two concrete alternatives with the conditions that select each. It also flags the query-dimension sampling caveat and points to analyze_sampling_impact.

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

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

With readOnlyHint/destructiveHint already covering safety, the description still discloses the non-obvious mechanics: own-CTR-at-target-position calculation, the full fallback benchmark ladder and its trigger conditions, the 25,000-query scan cap with truncation semantics, the auto-relax retry behavior for minImpressions, warehouse-vs-live-API sourcing, and the ~2-3 day data lag. Nothing here contradicts the annotations.

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

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

The purpose is front-loaded in sentence one, and nearly every sentence adds decision-relevant detail (fallback conditions, scan cap, auto-relax) rather than restating the name. It is a single ~350-word block, though, and would be easier to scan if the fallback/scan/date-range material were broken out.

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 10 parameters, a low schema coverage, and an output schema, the description supplies everything an agent needs to invoke correctly: range semantics, defaults, fallback selection, truncation risk, and date-lag handling. Return-value explanations (targetCtr, ctrSource, scanNote) partly duplicate the output schema but don't leave gaps.

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

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

Schema description coverage is only 40%, so the description has to carry weight — and it does: it explains minImpressions' default, auto-relax retry, and floor role, expands each fallbackBenchmark enum value, and gives meaning to minPosition/maxPosition/targetPosition. It never mentions `limit`, leaving one parameter undocumented in both places.

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 — finds queries ranking just outside the top (between minPosition and maxPosition) and estimates click upside of moving them to a target position. The opening sentence is framed as a user question, and the explicit contrast with score_opportunities makes it distinguishable from siblings without opening either schema.

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

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

Gives an explicit trigger ("Use this when the user asks which queries could gain the most clicks by moving up") and an explicit exclusion with the alternative named ("Not for an impression-weighted score across positions 3-30: use score_opportunities"). The when and the when-not are both 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 readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: the modeling approach, minimum history thresholds with the partial-period dropping rule, zero-filling of missing days/periods, the constant-history flat-forecast edge case with forecastNote, and the warehouse-vs-live-API data source. These are exactly the behaviors an agent cannot get from structured fields.

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

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

Front-loaded correctly: use case, exclusion, then mechanics, so an agent can decide before reading the modeling internals. It is dense and near the useful limit — the trendline-algorithm enumeration and R-squared asides add credibility but are more than an agent needs to invoke the 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?

For a 12-parameter forecasting tool with an output schema, the description covers the remaining unknowns: history minimums and data-window math, partial-period handling, zero-fill semantics, degenerate-history behavior, and degraded-mode data source. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema coverage is 92%, so the baseline is 3; the description earns one more by explaining cross-parameter behavior the schema doesn't: growthRate/cvr/aov optionally combine for revenue, metric choice propagates into the *Sessions output fields, and history requirements differ per granularity. Much of the detail (defaults, enums) is redundant with the schema, which keeps 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 and resource ("Projects future Search Console clicks (or impressions) for a property") and names the scope (coming weeks/months). It also explicitly separates itself from the closest sibling, detect_change_points, so an agent can route without opening a schema.

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

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

Opens with an explicit when-to-use trigger ("user asks how much search traffic to expect in coming weeks or months") and immediately gives a when-not plus the named alternative ("Not for explaining a past change: use detect_change_points"). Both halves of the routing decision are stated, not inferred.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so safety is covered; the description adds real behavioral context beyond that: single round trip, shared auth and property resolution, server-side parallel reads, and a ClickHouse warehouse serving path. It stops short of stating latency expectations, failure modes, or cost on large properties.

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?

Dense but front-loaded: the trigger, the scope, the differentiator, and the exclusion all arrive before the format detail. The long parenthetical enumeration of sub-analyses is the only place it could be trimmed, but it doubles as scope disclosure.

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 explanation is unnecessary, and the description still covers the decisions an agent must make: when to use it, when not to, and which format to request for which downstream behavior. Nothing material is missing for a 4-parameter, non-nested 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 coverage is 75%, and the description carries the key gap itself: it explains all three format values (compact with `drill` pointers, self-contained html default, full json) even though the schema's format enum has no description. It also gestures at the sitemap inclusion and analysis breadth, though `days` is left entirely to the schema.

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

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

States a specific verb and resource ('runs the whole analysis suite in one call' for a 'full SEO report or health check for one property') and enumerates the sub-analyses included. It explicitly distinguishes itself from the sibling get_site_summary, so an agent can pick it without opening either schema.

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

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

Gives an explicit trigger ('when the user wants a full SEO report or health check for one property') and an explicit exclusion with the alternative named ('Not for one headline number: use get_site_summary'). It also routes by output need via the format values.

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, destructiveHint=false and openWorldHint=false, so the description adds value with non-obvious behavior: the googleAccounts ordering (connectedAt ascending) and that the first entry is the primary/default account. It stops short of stating failure modes, such as what is returned when no Google account is connected or a token has expired.

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 trigger condition, followed by the payload, a diagnostic use case, and the sibling exclusion, then the ordering caveat. Every sentence carries distinct information; nothing restates the title or annotations.

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

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

An output schema exists, so return shape needn't be spelled out, yet the description still names the three returned components and their ordering. For a zero-parameter, read-only info tool this covers everything an agent needs to select and call it.

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 no parameters, so there is nothing for the description to disambiguate and the baseline is 4. The return-ordering note is the closest thing to a semantic hint and is already covered above.

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 (get/returns) plus the exact payload: authenticated user, connected Google accounts with email + scopes, and subscription status. It also explicitly separates itself from list_sites, so the agent can distinguish it from the property-listing siblings without opening a schema.

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

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

Gives both triggers ('when the user asks which Google accounts, scopes or plan') and a second diagnostic use case ('first call to confirm the MCP server is wired up'). It also names the exclusion and the correct alternative: 'Not for the property list: use list_sites.'

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 safe-read profile (readOnlyHint, destructiveHint=false), but the description adds genuinely new behavioral facts: the sort order (inbound links desc, then URL A-Z) and the 'notConfigured: true' state when no Bing API key exists for the property. The remaining row-level field listing is largely duplicative of the output schema, keeping it just 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?

Front-loaded with the usage trigger, then issue types, then ordering, then exclusions — a sensible priority order with no filler sentences. Slightly dense in the middle enumeration, but every clause carries information.

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

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

With an output schema and annotations already present, the description only needs to add what structure can't express: the use case, the sort order, and the notConfigured failure mode. All three are covered; the only minor hole is siteUrl formatting, which is a parameter-level rather than completeness-level 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?

Schema coverage is only 50% and the undocumented parameter is siteUrl — the required one. The description says issues are returned 'for a property' but never specifies the expected URL format (bare domain vs. full URL vs. Bing site identifier), so an agent must guess. The 'limit' semantics are fully handled by the schema, which is why this sits at the baseline rather than lower.

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 ('which of their URLs Bing has trouble crawling') and enumerates the exact issue classes returned (4xx/5xx, redirects, robots.txt blocks, DNS/timeout, malware) plus the fields attached to each row. It is clearly distinguishable from get_bing_crawl_stats and inspect_url, which are named outright.

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?

Opens with an explicit trigger ('Use this when the user asks which of their URLs Bing has trouble crawling') and adds two exclusions with the correct alternatives: daily crawl totals go to get_bing_crawl_stats, single-URL Google view goes to inspect_url. No inference required.

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

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

Goes well past readOnlyHint/openWorldHint annotations by disclosing row ordering (date, oldest first), the missing-vs-zero semantics for unreported days, and the notConfigured:true failure mode when no Bing Webmaster API key exists for the property — none of which the annotations or schema convey.

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

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

Four sentences, front-loaded with the trigger, then scope, then return shape, then the exclusion. Every sentence carries either routing or data-shape information; nothing is restated from the schema.

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