OnPage.dev

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds that the tool requires a url and that each mode produces a distinct kind of output, which is useful context but not rich behavioral disclosure (no scope, cost, or failure behavior).

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

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

Five short sentences, zero padding, and the core purpose plus the mode-keyed requirements are front-loaded. The telegraphic style ("Needs url.") is efficient, though slightly choppy.

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 input schema is fully documented, so return values and param details needn't be re-explained. The description covers the mode split and the url precondition, which is enough for an agent to call the tool correctly, though it omits guidance on the tree/detail parameters.

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

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

Schema description coverage is 100%, so the schema already documents url, mode, tree, detail, and memory_key. The description restates the mode enum values and the url requirement without adding syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a concrete capability (accessibility checking) and names its two concrete outputs, WCAG 2.1 AA checks and screen-reader rendering. It doesn't compare itself to siblings like scan_page, but the purpose is unambiguous 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 gives real selection guidance for the mode parameter (wcag vs screen_reader) and a precondition ("Needs url"). However, it never says when to reach for this tool versus alternatives such as scan_page or technical, so usage is implied rather than framed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description adds real behavioral substance on top, namely what each mode actually inspects (crawler access, firewall blocks, challenges, cloaking, competitor naming) and where the data originates (Brand Radar, citation counts, ahrefs/semrush). It does not mention rate limits, cost, or auth requirements, which is the remaining gap.

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

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

Front-loaded purpose sentence followed by a tight mode-by-mode breakdown; the 'mode = behavior. Needs X.' pattern is scannable and every clause carries information. The mode blocks are run-on but justified by the four-way branching and the differing input requirements.

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 10-parameter, four-mode tool with an output schema present (so return values need not be described), the description covers the mode semantics and per-mode required inputs well. It leaves out the secondary parameters (detail, source, competitors, memory_key) and any note that no parameter is strictly required, which an agent choosing a mode would benefit from.

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 70% schema coverage the schema does part of the work, but the description maps parameters to modes (url for check/bots, site+brand+responses for gaps, pages for citations) and spells out the nested response fields (question, response, links, search_queries, engine, volume) that the schema leaves bare. It omits any explanation of detail, source, memory_key or competitors, which are common-trap parameters here.

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 concrete outcome ('whether AI assistants can read, quote and recommend a site') and then enumerates four named modes (check, bots, gaps, citations) with the specific artifact each produces. An agent can immediately distinguish this from siblings like robots_txt, llms_txt or scan_page, which cover only fragments of this scope.

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

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

Usage is effectively driven by mode selection, and the description states exactly what each mode needs ('Needs url', 'Needs site, brand, responses[...]', 'Needs pages[...]'), so the agent knows which inputs select which behavior. It stops short of naming when-not-to-use or pointing at alternative siblings, so it is clear context without explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the mode-conditional invocation behavior but does not disclose anything further about cost, external calls, or output characteristics beyond what annotations and the output schema provide.

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

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

One framing sentence followed by three compact mode clauses, each pairing a mode with what it returns and what it needs. Front-loaded and every clause earns its place; no filler.

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

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

With an output schema present, return values need not be restated, and the mode/parameter mapping gives the agent everything required to invoke correctly. Minor gap: no guidance on default mode behavior despite the schema noting 'Default questions', which the description could have confirmed.

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%, but the schema lists zero required parameters while the description supplies the conditional requirement logic per mode ('Needs url, topic, questions', 'Needs url, question', 'Needs url, question, competitors'). That is genuine semantic value the schema does not encode, and it also explains what each mode returns.

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 purpose: whether a page answers the questions people ask AI and Google, framed around an answer-readiness evaluation. It clearly separates this from generic scan/audit siblings, though the verb is somewhat implicit rather than a clean 'evaluate X against Y'.

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

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

It explicitly tells the agent how to select a mode (questions vs passages vs format) and which parameters each mode requires. This is real invocation guidance. It stops short of naming when to prefer a sibling tool or when not to use this one, so it is not a full 5.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description still adds real behavior: outreach produces drafts that require user approval before use, and disavow is guarded by a caution about manual actions or negative SEO. It does not clarify that generated redirect/disavow files are not applied automatically to the site, which is the one trait worth surfacing.

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 purpose followed by a compact mode-by-mode breakdown; each clause carries required inputs or a caution. The prose is dense and readable, though the array-literal notation is terse and slightly harder to scan than a structured list.

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 16-parameter, four-mode tool with an output schema present, the description supplies the mode routing, per-mode required inputs, and the disavow caution. Nothing an agent needs to select and invoke the tool is missing, and return values are covered by the output schema.

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

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

Schema coverage is 94%, so the baseline is 3, but the description goes further by mapping modes to their required payloads (rows{target_url, source_url, anchor, domain_rating, dofollow, http_code}, prospects{page, type, your_url, dead_url, anchor, contact}, rows{url_from, domain, is_spam, ...}, reason). The schema declares all params optional at top level, so this per-mode requirement mapping is genuine added value.

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 transformation ('Turn backlink data ... into links won back, won or cleaned up') and the mode list names the four concrete jobs. It does not explicitly distinguish itself from the 'opportunities' sibling or find_opportunities, leaving a small ambiguity, but the verb+resource is clear.

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

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

The description gives explicit when-to-use guidance per mode: broken for lost links/404s, opportunities for competitor links and unlinked mentions, outreach for email drafts, disavow 'only after a manual action or clear negative SEO'. It also states the required inputs for each mode, which is exactly the routing information an agent needs.

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

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description's added value is in behavior: it discloses that focus performs '8 checks' and that cannibalization lays competing pages 'side by side on every signal, with the plan.' That is meaningful procedural context beyond the annotations, though return shape is left to the output schema.

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

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

Dense and front-loaded: the core purpose leads, then each mode with its own inputs. The phrasing is compressed to the point of being slightly telegraphic ('with the plan'), but nothing is 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?

With an output schema present, the description need not describe returns, and it covers the two decision points an agent must resolve: which mode and which inputs. The remaining parameters (rows, competing_urls, detail, memory_key) are fully documented in the schema, so the definition is adequate for correct invocation.

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

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

Schema coverage is 100%, so 3 is the baseline, but the description adds real meaning the schema does not carry: the schema lists zero required parameters, while the description states which inputs each mode actually needs (url+keyword for focus, keyword+target_url for cannibalization). That per-mode parameter requirement is genuinely additive.

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

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

The description names the subject (how pages target a keyword) and splits it into two concrete modes with distinct outputs: 'focus = One page against one keyword: 8 checks' and 'cannibalization = Your pages competing for one keyword.' This is more specific than the title alone, though it never differentiates itself from adjacent siblings like track_rankings or content, so it falls just short of 5.

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

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

The 'Pick with mode:' phrasing gives explicit selection criteria between the two modes and states the required inputs for each ('Needs url, keyword' vs 'Needs keyword, target_url'). It stops short of naming when to prefer this over a sibling tool, so it is clear context without exclusions.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint). The description adds the meaningful behavioral detail that outbound mode returns archived copies and redirect/canonical chains, which is useful beyond the annotations, but it omits rate limits, failure handling, or what happens with dead links.

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 compact sentences, front-loaded with the resource, then structured mode-by-mode with the required input for each. Zero wasted words.

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 mode descriptions cover the core use cases. Minor gap: the interplay of 'expected' with the returned canonical/final URLs is not described, though that is arguably schema-level detail.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description adds routing context for mode/urls/url, but for detail, expected, and memory_key it adds nothing the schema doesn't already state.

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

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

The description states a specific resource (URLs/links) and enumerates the two modes with their distinct outputs, letting an agent distinguish the tool from siblings like internal_links or backlinks. However, 'Status of URLs and links' is a slightly vague opener before the mode breakdown clarifies the actual function.

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

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

The description explicitly ties each mode to its required input ('urls = ... Needs urls', 'outbound = ... Needs url'), which routes the agent between the two behaviors effectively. It does not name sibling alternatives for edge cases like internal link analysis, but the mode guidance is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds mode-dependent behavior and per-mode input requirements, which goes beyond the annotations, though it says nothing about permissions, rate limits, or what the comparison returns.

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

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

Front-loaded with the core purpose, then a tight one-line-per-mode breakdown. Every clause carries information; there is no filler.

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

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

With an output schema present the description need not explain return values, and annotations cover the safety profile. The mode/parameter mapping makes the 12-parameter tool navigable, though optional params like paths, detail, keyword, and memory_key are left to 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 coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema by grouping parameters per mode (url+competitors for pages, before+after for html, preview_url+production_url for preview), which the flat schema does not express.

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

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

States a specific verb and resource ("Compare pages side by side") and then enumerates the three modes with a concrete description of each comparison. An agent can tell exactly what the tool does and how the three variants differ 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?

Explicitly maps each mode to a scenario (pages = you vs competitors, html = before/after versions, preview = deploy preview vs production) and names the parameters each mode requires. It stops short of naming when not to use the tool or alternatives among siblings, but the mode-routing guidance is strong.

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, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds little beyond that — it hints at side effects (webhook Monday reminder, memory_key recording the call, draft 'before approval') but never states permissions, rate limits, or reversibility, so with annotations carrying the burden a 3 is appropriate.

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

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

The opening states the tool's job and then the mode list is dense and front-loaded, with each mode entry pairing a verb with its required inputs. It is longer than average but nearly every clause carries routing or required-parameter information, so little is wasted.

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

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

With an output schema present, return values need not be explained, and annotations cover safety. For a 17-parameter, six-mode dispatcher the description supplies the critical mode-to-required-parameter mapping, though it leaves some parameters (detail, start, weeks, per_week, audit_id, ideas) mapped only via the schema, which is acceptable given 100% schema coverage.

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

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

Schema coverage is 100%, so the schema alone would justify a baseline 3. The description earns above baseline by stating which parameters each mode requires ('Needs keyword, competitors', 'Needs rows[{query, page, clicks, impressions, position, url}]', 'Needs urls', 'Needs html') — information the schema cannot convey, since required is empty and every parameter is optional there.

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

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

The description names a concrete deliverable ('What to write and how, in the site's own voice') and then enumerates six distinct modes — brief, topics, intent, voice, calendar, draft — each with its own output. This distinguishes it sharply from siblings like text_quality, answer_readiness, and check_keyword, which an agent can rule out 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?

'Pick with mode:' plus per-mode needs (brief needs keyword, competitors; topics needs rows[...]; voice needs urls; draft needs html) tells the agent exactly how to route within the tool. What is missing is any when-not-to-use or explicit cross-reference to sibling tools, which is why this falls short of a 5.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so mutation status and open-world behavior are covered structurally. The description adds meaningful state-chaining context ('returns feed_id', data mode consumes feed_id/dataset, build produces a blueprint) but says nothing about whether re-running feed mode overwrites prior output, what sources must be connected first, or what the returned dashboard actually contains.

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 mode-first structure is front-loaded and the per-mode clauses are telegraphic with no filler sentences. It is dense to the point of clipped grammar, but every phrase carries a required-input or output fact, so nothing is wasted.

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

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

For a 15-parameter, nested-object, multi-mode tool with an output schema, the description supplies what the structured fields cannot: which mode to pick and which inputs each mode demands. Remaining gaps (how the three modes interact across a session, what the feed/dashboard delivers in practice) are modest given the output schema and high schema coverage.

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

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

Schema coverage is 93%, so the baseline is 3, and the description clears that bar by mapping parameters to modes (feed needs url, data needs feed_id and dataset, build needs feed_id) - a cross-parameter dependency the flat schema with no required fields cannot convey. It adds nothing about the many remaining optional parameters (from/to, pages, replace, sources, bigquery, memory_key), which the schema mostly documents on its own.

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 leads with a concrete verb+resource ('daily SEO data feed for key pages and a live dashboard in the chat') and then decomposes the tool into three named modes with distinct deliverables, which is well beyond a restatement of the name. It never distinguishes itself from plausible siblings like watch or site_audit, so an agent still has to guess whether this is the right entry point within the suite.

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?

'Pick with mode: feed = ... data = ... build = ...' is explicit routing guidance and is reinforced by naming the required inputs for each branch, which the schema cannot express since zero parameters are marked required. There are no when-not conditions or pointers to alternative sibling tools for overlapping tasks such as tracking or auditing.

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

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

The description says 'Fixes applied at the edge on the user's own Cloudflare', which describes a mutating deployment to the user's Cloudflare account, while annotations declare readOnlyHint=true and destructiveHint=false. A write action presented as read-only is the exact contradiction pattern to flag. It also omits the auth/permission requirements such a deployment would need.

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 what the tool is, then mode-by-mode detail and prerequisites in three tight sentences; every clause carries information. The telegraphic 'Pick with mode:' / 'Needs audit_id.' style is slightly clipped but wastes nothing.

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

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

An output schema exists, so return values need not be explained, and the two modes plus their prerequisites are covered. However, for an openWorld tool that touches the user's own Cloudflare, the description never states the authorization/setup prerequisite, what exactly is deployed, or whether it can be undone, leaving meaningful 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 coverage is 100%, so the baseline is 3, and the schema already documents url, mode, detail, audit_id, site_name and memory_key. The description does add one piece of meaning beyond the schema: the conditional requirement that rules needs audit_id and prerender needs url, which the flat schema does not express.

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 resource (a Worker running on the user's own Cloudflare, CMS-agnostic) and splits it into two named modes, rules and prerender, with a one-line definition of each. An agent can tell what the tool produces, though no sibling tool is named to differentiate it from the many other fix/asset generators in the suite.

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 mode-selection guidance and the prerequisite for each mode: 'rules ... Needs audit_id' and 'prerender ... Needs url'. That is actionable when-to-use context, but it never says when to prefer edge_worker over siblings such as llms_txt, robots_txt, or get_fix_pack, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds a useful signal ('Needs url') that compensates for the schema showing zero required parameters, but it discloses nothing about cost, rate limits or output behavior.

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

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

Three compact sentences with the conceptual framing front-loaded, then the mode split. Every sentence carries information; no filler or repetition.

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

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

For a read-only analysis tool with an output schema and a fully described input schema, the description covers the essentials: purpose, mode selection and the url requirement. Return-value details are correctly omitted since the 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 coverage is 100%, so the baseline is 3, but the description goes beyond the terse schema text ('Default graph') by explaining what each mode actually yields. It still says nothing about 'detail' or 'memory_key', which the schema already names.

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?

Frames the resource clearly ('How Google understands who is behind a site') and then specifies that it operates in two named modes, graph (Organization/sameAs/logo/founder) and trust (Author/about/contact/policy). An agent can tell what the tool returns, though it never uses a crisp verb like 'analyze' or 'extract' and doesn't name a sibling.

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

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

'Pick with mode: graph = ... trust = ...' gives explicit guidance for choosing between the two internal modes, which is genuinely useful. However it offers no when-to-use versus alternatives like 'schema' or 'content', and no when-not guidance, so tool-level 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 readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuine non-structured context: it returns remediation content ('with the fix', 'the cleanup plan and reconsideration draft') rather than raw report data, which an agent could not infer from 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?

Front-loads the purpose, then uses a compact mode = meaning / needs-X pattern that is easy to scan. Dense but every clause carries information; the trailing 'bing' clause is slightly terse about what data it consumes but not wasteful.

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

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

For a 10-parameter, multi-mode tool with an output schema present, the description covers all three modes and their required inputs, and the return shape is handled by the output schema. Minor gaps remain (site, detail, memory_key are left to the schema), but nothing critical 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 70%, and the description adds mode-conditional parameter requirements that the schema does not encode since all 10 params are optional: rows[{url, coverageState, verdict, indexingState, robotsTxtState, pageFetchState}] for index_status, action for manual_action. This is real added meaning over the flat optional 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 ('Explain what Google Search Console and Bing Webmaster Tools report, and what to do') and breaks the tool into three named modes with their outputs. An agent can distinguish it from diagnostic siblings like site_audit or technical, though no sibling is named explicitly.

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

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

Gives a clear mode-selection rule (index_status / manual_action / bing) and states the input each mode needs (rows[...], action, bing query data), which is effectively the when-to-use guidance. It does not state when to prefer a sibling tool or when this tool is inappropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds mode-specific output goals ('a refresh queue', 'Explain a drop page by page') and input constraints, but no extra behavioral context such as auth requirements or return format beyond what the schema and output schema provide.

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

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

The description is long but front-loads the core purpose and then devotes each sentence to a mode, so little is wasted. It would be more scannable as a bulleted list rather than a single dense paragraph, but the information density is appropriate for nine modes.

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

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

With an output schema present and all parameters documented, the description is nearly complete for mode selection and required row fields. It does not explain how auxiliary parameters (urls, drop_date, fix_log_id, etc.) pair with specific modes, leaving some integration detail 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 parameters like ads, gsc, mode, and others are already documented. However, the description adds crucial meaning by mapping each mode to the exact fields required inside the generic rows array (e.g., ctr_gaps needs position, page, query, clicks, impressions, ctr), which the schema alone does not specify.

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 ('turn rows into fastest wins') and resource (Search Console/GA4/Ahrefs rows), and enumerates nine distinct modes with their distinct outputs. An agent can distinguish this from siblings like prioritize_fixes or check_keyword without opening other tools.

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

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

The description gives explicit mode-selection criteria ('ctr_gaps = Page 1 results with a click-through rate far below normal', etc.) and states the required row shape for each mode. It lacks any when-not-to-use guidance or naming of external sibling alternatives, but the internal routing is very clear.

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

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

Beyond the annotations (which only say not-read-only, open-world, non-idempotent, non-destructive), the description discloses real behavior: fixes are re-checked every 6 hours and code is restored on regression, the webhook receives restore code when a fix is undone, verify checks live pages at 4 pages per call, and format=annotations emits GA4 Admin API annotations. Auth/permission requirements are not covered, keeping it at 4.

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

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

Front-loaded purpose followed by two clearly labeled mode branches; nothing reads as filler and the per-branch prerequisite lists are compact. The bracketed "fixes[{url, field, new, old, via, ref}]" shorthand is terse but functional rather than elegant.

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 11 parameters at 91% schema coverage and an output schema present, the description does the work that matters: mode selection, branch prerequisites, verification cadence, and webhook notification behavior. Only authentication/authorization context and the relationship to sibling monitoring tools are absent.

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

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

Schema coverage is 91%, so the baseline is 3, but the description adds mode-scoped meaning the flat schema does not convey: which parameters belong to the log branch (fixes subfields url/field/new/old/via/ref) versus the report branch (fix_log_id), plus the 6-hour check semantics tied to the logged values. Minor tension exists between the schema's "Add to an existing log" phrasing for fix_log_id and the description presenting it as required for report mode.

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 ("Record shipped fixes, keep them live and report on them") and the mode branch spells out both operations, so the agent knows exactly what the tool does. It does not, however, name or contrast any sibling (e.g. watch, tracking, site_memory), so it falls short of the 5-level sibling differentiation bar.

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?

"Pick with mode: log = ... report = ..." gives explicit branch conditions, and the "Needs fixes[...]" / "Needs fix_log_id" clauses state which inputs each branch requires. There is no when-not guidance and no named alternative tool, so it stops short of 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false. The description adds real context beyond that for the wordpress mode: fixes, drafts and post updates are sent to the plugin with one-click approval and undo, which reassures about reversibility. It does not disclose auth requirements, rate limits, or whether repeated non-idempotent calls duplicate sends, so it is useful but partial.

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 mode list is dense but consistently structured ('mode = output. Needs x.'), and the deliverable is front-loaded. The opening clause 'Fixes ready to ship' is marketing filler, and cramming four modes plus platform lists into one paragraph makes it harder to scan than bullets would.

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

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

With an output schema present, return values need not be described. For a 12-parameter, 4-mode tool the description covers the mode taxonomy and required inputs well; the main omission is any signal about ordering relative to siblings (e.g. analyze first, then generate fixes).

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 goes further by binding parameters to modes – url is required for fixes/alt_texts/web_vitals and site_key for wordpress. That mode-to-parameter dependency is not expressible in the flat schema and is the single most useful thing added here.

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

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

The description states a concrete deliverable – a 'fix pack' emitted as code, CMS payload, PR, or edge worker – and enumerates the four modes (fixes, alt_texts, web_vitals, wordpress) with the artifact each produces. That is specific verb+resource+output. It does not, however, name or contrast itself against closely related siblings such as prioritize_fixes, plan, accessibility, or web_vitals, so an agent must infer the boundary.

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

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

Usage is implied through mode semantics and the per-mode prerequisites ('Needs url', 'Needs site_key'), which tells an agent which mode requires what input. There is no explicit when-to-use/when-not guidance and no routing to alternatives, e.g. which sibling to call first to decide which fixes are needed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that suggested links can be 'applied by Worker or CMS', but says nothing about return format, cost, or limits beyond what annotations and the output schema provide.

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

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

The content is front-loaded (topic statement first, then mode routing) and every phrase carries a distinct fact. It is terse and slightly telegraphic, but there is no redundant 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 described, and all 9 parameters are fully documented in the schema. The description supplies the mode-selection logic and audit_id prerequisite, leaving only minor gaps such as how the modes interact with the application-oriented params.

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, and the description earns above that by explaining the semantics of the mode enum (what 'suggest' and 'equity' actually return) and reaffirming the audit_id requirement, adding meaning beyond the schema's bare 'Default suggest.'

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

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

The description names the resource (internal links / link equity) and splits it into two concrete modes with their distinct outputs (links to add with anchors vs. Internal PageRank and click depth). This is specific enough for an agent to know what the tool produces, though it does not explicitly name which siblings it overlaps with.

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

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

The mode routing is explicit: 'suggest = Links to add...', 'equity = Internal PageRank and click depth', plus a stated prerequisite ('Needs audit_id') for both. This tells the agent when to pick each mode, but provides no guidance on when not to use the tool or which sibling to prefer instead.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, and the description adds real context: render uses "a real browser" and captures "what crawlers without JavaScript get," while probe delegates execution to the user's browser. That materially explains execution model beyond the structured safety hints.

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

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

Front-loaded purpose sentence followed by a compact per-mode breakdown; every clause carries information. It is telegraphic and slightly dense, but there is no filler to trim.

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 covers mode semantics and required inputs for a 6-parameter tool. The main residual gap is that it does not call out optional params (no_js, detail, memory_key) or differentiate from siblings, though the schema fills those in.

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 goes further by explaining what each mode value actually produces and which params each mode requires. It leaves no_js, detail, and memory_key to the schema, but those are already well documented there.

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 the resource concretely: "What visitors and crawlers see on every screen size," and then describes each mode's distinct output (first-screen rendering vs. a probe script vs. analysis). This lets an agent distinguish the three behaviors. It never positions itself against sibling tools like content or technical, so it stops short of a 5.

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

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

It gives explicit mode-selection guidance ("Pick with mode"), marks render as the default, and names the required inputs per mode ("Needs url," "Needs url, results"). It does not say when to prefer this tool over sibling tools such as content or scan_page, which keeps it below a 5.

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

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

Annotations carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description usefully states that generate derives content from the sitemap and home page and that validate inspects links, but says nothing about network access, rate limits, or that memory_key causes the call to be recorded.

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 terse sentences, front-loaded with the resource and then the mode decision. Every clause carries information; nothing is padded or restated.

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 5-parameter tool with full schema coverage plus an output schema, the description covers the decision an agent must make (which mode, and that a URL is needed) and correctly leaves return values to the output schema. The incomplete handling of the text/detail/memory_key path is a minor 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 100%, so the baseline is 3; the description exceeds it by supplying the conditional requirement the schema does not encode ('Needs url' for both modes) even though no parameter is marked required. It is slightly imprecise, since url may be unnecessary when text is supplied, and it never mentions text, detail, or memory_key.

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

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

Names the resource (the llms.txt file for AI assistants) and splits it into two concrete operations with explicit verbs: generate writes one from the sitemap and home page, validate checks an existing one and its links. It does not, however, distinguish itself from adjacent siblings such as robots_txt or sitemap, which an agent could plausibly confuse it with.

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

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

The 'Pick with mode' framing gives a clear branch rule, and each mode's precondition ('Needs url') tells the agent what must be supplied before calling. No exclusions or alternative-tool routing are given, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds real behavioral context beyond them: reviews mode only produces reply drafts routed to the user's GBP connector 'after approval', unhappy reviews are handled first, and GBP profile data is used only for comparison. No contradiction with the readOnly hint.

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 domain, then three tight mode clauses each stating purpose and required input. Dense but every clause carries routing information. Slightly compressed notation (e.g. 'Needs reviews[{...}]') costs a little readability.

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 multi-mode tool with an output schema (so return values need not be explained), the description covers all three modes and their key inputs and side effects. It leaves secondary parameters (city, grid, terms, detail, contact, memory_key) unexplained, but those are documented in the schema at 92% coverage.

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

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

Schema description coverage is 92%, so the baseline is 3, but the description adds value the schema cannot: it maps which inputs each mode requires (url for check, the reviews[] array for reviews) even though every top-level parameter is formally optional (required: 0). That per-mode requirement linkage is genuine added semantics.

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

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

The description names a concrete domain (local search: site, Business Profile, map) and decomposes it into three clearly labeled modes with distinct outputs, so an agent can tell what the tool produces. The bare name 'local' is weak, but the description compensates. It differentiates internally by mode rather than from siblings like schema or entity, so it stops just short of 5.

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

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

It gives explicit mode selection with defaults and prerequisites ('check... (default). Needs url', 'reviews... Needs reviews[...]', 'demand = ...'). That is strong within-tool routing. It does not name when to avoid the tool or which sibling (schema, entity, track_rankings) to prefer instead, so it is clear context without exclusions.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotent=true, destructive=false), and the description adds real behavioral context beyond them: fix_log_id saves results per fix and produces a rollback plan for fixes that did worse, and memory_key records the call into site_memory. It does not discuss rate limits or failure behavior, but the mutation/persistence semantics are disclosed.

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 purpose and the mode-selection rationale, then compressed into a dense mode-by-mode input list. Every clause carries information, though the packed enumeration reads as terse rather than ideally structured prose.

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

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

With 13 parameters, five modes, 85% schema coverage, an output schema, and annotations, the description supplies the mode-to-input mapping and persistence semantics an agent needs to invoke it correctly. Minor gaps remain around default behavior for unlisted optional parameters.

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 85% (baseline 3), and the description goes further by spelling out the concrete field sets required per mode — e.g. pages[{url, before, after, changed, fix}] for impact and rows[{source, sessions, landing_page, period, conversions, revenue}] for ai_referrals. This meaningfully compensates for the untyped nested object arrays the schema leaves bare.

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 and scope: prove and measure numbers from named sources (Search Console, GA4, Ahrefs, Semrush) plus pasted data. It distinguishes itself from calculation-by-hand and from sibling analytics tools by enumerating the five modes it produces, so an agent can tell what it does without opening the schema.

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

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

Explicitly routes usage ('Use it instead of calculating by hand') and gives per-mode selection guidance with the required input shape for each mode. It does not name a sibling tool to prefer or state when not to use it, so it falls short of full when/when-not/alternative coverage.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so safety is covered. The description adds mode-specific behavioral context the annotations cannot: what each mode produces (redirect map, Worker-based split test, week plan of tickets per role) and the required input shapes, which is genuine added value.

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

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

The mode breakdown is front-loaded right after a one-line purpose statement, and each clause carries distinct information. It is dense shorthand rather than filler, though the compact "=" notation reads a little run-on.

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 16-parameter, multi-mode tool, the description covers the three modes' key inputs and the output schema handles returns. However, it leaves many parameters (hours, weeks, detail, format, old_site/new_site, clicks, memory_key, start_date) unmapped to modes, so an agent must infer which apply when.

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 81% schema coverage the baseline is 3, but the description goes further by mapping parameters to modes (split_test needs urls/field/pattern; sprint needs fixes with its subfields), which the schema alone cannot express since param applicability is mode-dependent.

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

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

The description names the verb ("Plans") and the three concrete resources/use cases (migrations, split tests, team sprints), then breaks each mode down so an agent can tell redirects from split_test from sprint. It is specific and non-tautological, though it does not differentiate from any sibling tool by name.

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

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

It explicitly tells the agent how to select behavior via "Pick with mode" and gives a condition/purpose for each of the three modes, plus the inputs each mode needs. There is no "when not to use" guidance or pointer to alternative sibling tools, keeping it out of the top band.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety burden is light. The description adds real behavioral detail beyond them: passing clicks_previous triggers a refresh fix, and supplying GA4 conversions or revenue switches the ranking objective from clicks to money.

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 usage condition and click-loss tip are front-loaded, but the second sentence largely restates the title and the first sentence's ranking claim without adding information, creating noticeable redundancy in a short description.

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

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

With an output schema present, return values need not be described, and annotations cover safety. The description supplies the data-source preconditions and the two objective-switching behaviors an agent needs, leaving only minor gaps such as scope limits (max 10 pages).

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 baseline is 3. The description adds genuine semantics on top of the schema by explaining the purpose of clicks_previous (diagnosing traffic drops) and of conversions/revenue (re-ranking by monetary return), which the schema fields alone only hint at.

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: ranks SEO fixes by the traffic or revenue they can win. An agent can tell this is a prioritization tool rather than a raw data collector, though it never names the sibling it is distinguished from (e.g. find_opportunities or plan).

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 trigger conditions are given: use when Search Console, GA4, Ahrefs or Semrush data is available, and additionally to explain a traffic drop by passing clicks_previous. It lacks exclusion criteria or named alternatives, but the when-to-use context is concrete.

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=false, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: it enumerates the steps the recrawl performs (indexability check, sitemap lastmod, IndexNow, Search Console) and discloses a practical requirement ('Needs urls') that the schema does not enforce, since zero parameters are marked required.

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 core action is front-loaded in the first sentence, then mode semantics follow in a compact form. 'Needs urls' is repeated for each mode, which is mildly redundant but serves as an emphasis of the shared requirement.

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

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

An output schema exists, so return values need not be explained. For a 6-parameter, 0-required tool the description supplies the missing mode semantics and the practical 'needs urls' constraint, leaving little an agent needs but doesn't have.

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

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

Schema description coverage is 100%, so the baseline is 3. The description earns a bump because the schema's own enum descriptions are terse ('Default recrawl'), whereas the description explains what 'recrawl' and 'indexnow' actually do and flags that 'urls' is effectively needed for both, adding meaning the schema lacks.

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 ('Get changed pages recrawled') and then breaks the tool into its two operating modes, so the agent understands what it does. It doesn't name or contrast against sibling tools like sitemap or a dedicated IndexNow tool, so sibling differentiation is only implicit.

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 tells the agent how to choose a mode: 'recrawl' (default) versus 'indexnow', and describes what each does. This is clear when-to-use guidance for the sub-behaviors, though it gives no when-not-to-use or cross-tool alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the useful behavioral fact that required inputs vary by mode, but says nothing about the robots_txt override, user_agents, or memory_key side effects, leaving that to the schema.

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

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

Three compact sentences, front-loaded with the resource and then the mode decision; every clause carries information an agent needs to select a mode.

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

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

With an output schema present, return values need not be described, and the mode split plus prerequisite params are covered. Coverage of the auxiliary inputs (detail, user_agents, robots_txt, memory_key) is left entirely to the schema, which is acceptable given 100% schema coverage.

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

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

Schema description coverage is 100%, so the schema already documents url, mode, detail, policy, user_agents and the robots_txt override. The description only reinforces which params are needed per mode, which is marginal added meaning over the schema baseline.

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

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

The description states the resource (robots.txt) and splits it into two concrete capabilities, test and ai_policy, each with a one-line outcome. An agent can tell the two modes apart, though it gives no signal about how this differs from the sibling llms_txt tool.

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

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

It explicitly says how to pick: 'Pick with mode: test = ...' and 'ai_policy = ...', and names the prerequisites for each ('Needs url', 'Needs url, policy'). There is no when-not guidance or sibling alternative routing, which keeps it short of a 5.

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

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

Annotations already declare readOnly, non-destructive, openWorld, and non-idempotent, so the safety profile is covered. The description adds mode-specific prerequisites ("Needs url" / "Needs html") and the compare-with-last-scan behavior of rescan, which is real context beyond the structured fields, though it does not mention limits or how the scan is scoped.

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 value proposition, then a compact mode list where every clause carries needed information. No filler sentences; the dense prose is justified by the number of distinct modes.

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

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

With an output schema present and annotations covering safety, the description need not explain return values, and it covers the mode branching well. Its gap is that it never positions this against broad siblings like site_audit or accessibility, leaving the page-vs-site choice 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 baseline is 3, but the schema's mode field says only "Default page" while the description gives each enum value distinct meaning and its required companion parameter. That is meaningful semantic value added on top of the schema, though detail, sections, and memory_key get no extra explanation.

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 ("Scan a page") and enumerates the concrete outputs (0-100 score, prioritized issues with why/how, AI readiness, key facts), which separates it from single-facet siblings like accessibility, content, or technical. An agent can immediately tell this is the broad page-level SEO/AI scan.

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 mode breakdown is explicit when-to-use guidance: page for a live URL, html for unpublished HTML gating a release, deep for per-section measurement, rescan for post-fix comparison. Each mode names its required input, so the agent can pick correctly without inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine behavior beyond that: what each mode actually does (generate produces JSON-LD, validate checks it, product_page inspects an existing ecommerce page for price/stock/merchant fields) and the required input per mode.

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

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

Front-loads the one-line purpose, then uses a compact mode = behavior = requirement structure that is easy to scan. Dense but every fragment carries routing or prerequisite information; only the type enumeration is slightly list-heavy.

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 six-parameter, three-mode tool with an output schema and full annotation coverage, the description covers what each mode does and what each needs, so an agent has enough to call it. It leaves the memory_key side effect and the detail parameter's impact largely to the schema, a minor 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 100%, so the baseline is 3, but the description goes further by tying parameters together across the mode enum: url is needed for generate and product_page, jsonld for validate, and the type enum is spelled out with a note that 'auto' is the default. That cross-parameter conditional logic is not expressible in the flat schema and adds real value.

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 resource (JSON-LD structured data for rich results) and then decomposes the tool into three concrete operations: generate, validate, and product_page. Each mode is described with its own verb and required input, so an agent can tell exactly what the tool produces in each case.

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 gives per-mode selection guidance and prerequisites ('Needs url', 'Needs jsonld') and disambiguates an easy mistake by routing Product writing to 'generate with type Product'. It does not name any sibling alternative or state when not to use the tool, so it stops short of a full when-to-use/when-not treatment.

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, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context about external side effects (creating a Google Sheet, CSV, Slack message, or one task per issue) and the url dependency for link mode, but says nothing about repeat-call behavior, auth needs, or rate limits despite idempotentHint=false.

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 that are front-loaded with the overall purpose before the mode breakdown. Nearly every clause carries information, though 'Send results where the team works' is slightly promotional 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 explained, and the six parameters are fully documented in the schema. The description covers the two operationally important knobs (mode and url) but omits any mention of detail, audit_id, memory_key, or slack_webhook_url beyond what the schema already provides.

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 a baseline of 3 is warranted, but the description goes beyond the terse schema text by explaining what each mode value actually produces and by flagging that link mode additionally requires url. That extra meaning exceeds the schema's 'Default link.'

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

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

The description names a specific verb (send/share) and resource (results/reports) and splits the tool into two named modes with link and export outputs. It is clear what the tool does, though it does not directly contrast itself with sibling analysis tools like dashboard or site_audit.

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 conditional guidance for choosing a mode ('link = A link to the visual report. Needs url', 'export = A Google Sheet, CSV...'), which routes the agent reasonably well. However, there is no explicit when-not-to-use, no prerequisites, and no mention of alternatives among the many sibling tools.

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

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

Annotations already declare the safety profile (readOnlyHint false, destructiveHint false, openWorldHint true), so the description's job is to add workflow context — which it does: start returns an audit_id, continue iterates until complete, import converts external crawl data into an audit_id, and report produces a client-ready page with a link. The multi-step state-chaining and the 25/500 page caps are useful disclosures 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?

The purpose is front-loaded ('Audit a whole site, step by step') and each mode is presented as a compact 'mode = behavior. Needs X.' unit. It is telegraphic and runs together as one block, but nearly every clause earns its place.

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

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

Covers all five modes, their required arguments, and step limits, and an output schema exists so return values need not be described. The compare mode only says 'Needs audit_id' without mentioning the schema's previous_audit_id/competitor_audit_id options, a minor gap for a 13-parameter tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value by mapping which parameter each mode requires (url for start, audit_id for continue/compare/report, pages[{...}] for import) — for a mode-dispatch tool this mapping is the key semantic an agent needs.

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 ('Audit a whole site') and enumerates five distinct modes (start, continue, import, compare, report), so an agent immediately understands this is the whole-site audit orchestrator rather than a single-page scan. It does not explicitly distinguish itself from siblings like scan_page or technical, which keeps it at 4 rather than 5.

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

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

Each mode carries inline usage context: 'call until complete' for continue, 'compare the two sites side by side' for compare, and the required argument per mode. This is strong when-to-use guidance for a mode-dispatch tool, though it offers no explicit exclusions or pointers to alternative siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful behaviour (check samples the sitemap's URLs; generate derives a sitemap from a page list or a finished audit), but it doesn't resolve the tension between 'Write a sitemap' and readOnlyHint=true — it should say the generated sitemap is an artifact returned to the caller rather than a change to the site. No rate limits, no side effects, no auth requirements 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?

Three short clauses, mode selection front-loaded, zero filler. Every sentence carries routing information an agent can act on.

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

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

With an output schema present, return values need not be described, and the mode/parameter contract is fully covered. Minor gaps remain around the detail flag's effect and around how generate relates to site_audit, but for a two-mode tool with 100% schema coverage this is close to sufficient.

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 goes beyond the schema by mapping modes to the parameters they require (url for check, audit_id for generate) — information the schema's terse 'Default check.' does not convey. It still says nothing about detail, memory_key, or the url-vs-sitemap-URL distinction beyond what the schema already contains.

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 mode definitions supply real verbs and resources: 'check = Check the sitemap and a sample of its URLs' and 'generate = Write a sitemap from a page list or audit.' An agent can tell this is a two-mode sitemap tool. However, the tool is not distinguished from nearby siblings such as site_audit, robots_txt, or llms_txt, so it falls short of a 5.

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

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

The description gives explicit mode-selection guidance with the triggering parameter for each branch ('check ... Needs url', 'generate ... Needs audit_id'), which is exactly what an agent needs to route a request. It stops at context though — there is no when-not-to-use and no pointer to an alternative sibling when the sitemap is not the right target.

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

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

The description states that forget mode deletes the memory, which is a destructive operation, but the annotations declare destructiveHint=false. This directly contradicts the tool's own behavioral description. Even though other modes are well explained, the contradiction is serious enough to cap this dimension at 1.

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

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

The description is front-loaded with purpose and usage, then compactly enumerates each mode with its behavior and required inputs. Every clause earns its place despite covering five modes, and there is no filler.

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

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

For a complex eight-parameter, multi-mode tool, the description covers the main modes and their required inputs well, and an output schema exists so return values need not be explained. However, it omits meaning for kind, limit, detail, and share_learning, and the destructiveHint contradiction leaves the agent with an inconsistent behavioral picture.

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

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

The description adds conditional requirements for url, note, and memory_key, and clarifies the default mode. However, it does not explain the kind, limit, detail, or share_learning parameters, and schema description coverage is only moderate. It adds useful mode-linked semantics but leaves several parameters unaddressed.

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

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

The description clearly defines the tool as a site-specific memory that every OnPage.dev tool writes to, distinguishing it from all sibling tools. The multi-mode behavior is stated up front, so an agent immediately understands this is the central persistent memory layer for a site.

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

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

It explicitly says to open it first when working on a site over time, then explains when to use each mode: open for setup and brief, next for next steps, timeline for history, note for recording context, and forget for deletion. Required parameters per mode and the instruction to ask the user before forgetting are also included.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds behavior they don't cover: results are 'measured in pixels the way Google truncates', and social mode imposes a url requirement. It does not discuss return format, but the output schema handles that.

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

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

Front-loaded with the core value (pixel-accurate snippet/sharing preview), then mode selection and requirements. Dense and mostly waste-free, though the mid-sentence mode explanations read a touch run-on.

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 read-only preview tool with a 6-param, fully documented schema and an output schema, the description covers purpose, mode selection, and input requirements well. Return values are delegated to the output schema, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies the mode enum ('search = Title and description as Google shows them; social = Open Graph and X cards'), the title/description-or-url interplay, and that social mode 'Needs url'. This is more than the schema restates.

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: how a page renders as a Google snippet and as a social share card, measured in pixels. The two-mode split (search vs social) makes the scope concrete. It doesn't explicitly differentiate from siblings like 'share' or 'explain_google', so it stops short of a 5.

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

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

Gives clear when-to-use guidance: 'Use it instead of estimating title or description length' names an alternative practice to avoid. It also explains what each mode is for and which inputs each needs. No explicit when-not-to-use, but the alternative framing is strong.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds mode-specific behavior ('IP verification', 'corrected tag set', 'waste crawl budget'), which is useful, but says nothing about rate limits, cost, or how results differ per mode.

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 definition is densely front-loaded: the general purpose opens, then each mode is a compact clause. The mode list reads as a run-on, but no sentence is wasted.

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

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

With 12 params but 0 required, the mode-to-parameter dependency is the critical missing piece from the schema, and the description supplies it. An output schema exists, so return values need not be explained, and the remaining gap is only the absence of sibling routing.

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 documents every parameter and the baseline is 3. The description adds real value beyond that by mapping which parameter each mode requires, which the schema cannot express on its own.

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 enumerates all five modes (hreflang, parameters, duplicates, extract, logs) and says what each finds, so an agent understands the tool's scope. The umbrella phrase 'Technical checks across pages and logs' is generic, and no sibling tool is named for contrast, which keeps it short of a 5.

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

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

'Pick with mode' plus per-mode requirements ('Needs url', 'Needs audit_id', 'Needs urls', 'Needs log') tells the agent exactly how to invoke each branch. There is no explicit when-not-to-use and no routing to siblings like sitemap or scan_page, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered and the bar is lower. The description adds two useful behavioral facts beyond structured data: the ~30-language coverage for spelling and the url prerequisite. It stops there and adds nothing about limits or interpretation of results.

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

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

Short and front-loaded, with the core purpose first and mode selection immediately after. The telegraphic "Needs url" phrasing and terse fragments cost a little polish but no sentence is wasteful.

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

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

For a 6-param read-only tool with rich annotations and an output schema, the description covers purpose, mode selection and the key prerequisite adequately. Missing sibling routing and per-parameter context are minor given the schema and output schema carry the rest.

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

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

Schema description coverage is 100%, so the baseline is 3. The description clarifies the mode enum (readability vs spelling) and reinforces the url requirement, but detail, keyword, memory_key and competitors are left entirely to the schema. Value added over schema is marginal.

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 clear purpose (readability + language correctness) and splits it into two named modes, readability and spelling. An agent can tell this apart from siblings like content or accessibility. It stops short of naming sibling alternatives explicitly, so it is clear but not fully differentiated.

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

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

"Pick with mode" gives explicit selection guidance: readability for fit-to-page and ranking-page fit, spelling for grammar/errors. Each mode's scope and the shared "Needs url" prerequisite are stated. No when-not-to-use or alternative-tool guidance is offered.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the per-mode behavior (what each check inspects) but says nothing about auth needs, rate limits, or cost. Adequate but thin given annotations do most of the work.

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

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

The description is front-loaded with the mode selection and then walks each mode compactly in parallel structure. It is telegraphic but every clause carries routing or input information; nothing is 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?

Modes, their purposes, and their required inputs are covered, and an output schema exists so return values need not be explained. Minor gaps are the undocumented detail/memory_key semantics, but those are covered by the schema descriptions.

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 baseline is 3, but the description adds value the schema cannot express: with zero top-level required params, it clarifies the conditional requirement of url for ga4/consent modes and the required gsc/ga4 array shapes for gsc_vs_ga4. Only detail and memory_key go unmentioned, and those are self-documenting in the schema.

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

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

The lead sentence is a bit abstract ('whether the numbers add up'), but the mode breakdown gives concrete, specific checks: GA4 tags/events/duplicates, cookie banner and Consent Mode v2, and GSC clicks vs GA4 sessions. An agent can tell what each mode does without opening the schema. It does not differentiate itself from adjacent siblings like technical or measure, which keeps it out of 5 territory.

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

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

The description explicitly instructs 'Pick with mode' and maps each mode to its purpose and required inputs, which is real routing guidance among the tool's own modes. However, it never states when to choose this tool over siblings such as technical, measure, or scan_page, so the alternative-selection guidance is incomplete.

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, idempotentHint=false, openWorldHint=true, so the mutation/open-world nature is already flagged. The description adds real value beyond that: it discloses the stateful create-on-first-run behavior (omit tracker_id to create a tracker) and the per-run data-collection workflow.

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 use case and packed into a single dense sentence with no filler. It is a bit run-on and reads like an instruction sequence, but every clause carries operational content.

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 the 'run' path is well covered. However the tool exposes action=run/status/stop, detail, memory_key, fix_log_id, webhook_url and money_keywords, and the description explains none of the status/stop or notification behavior — a notable gap for an 11-parameter tool.

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

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

Schema description coverage is 100%, so the baseline is 3. Most of what the description says about parameters (tracker_id from first run, rows sourced from GSC/Ahrefs/Semrush/GA4) is already echoed in the schema descriptions. It does add the 'last 7 or 28 days' period hint, but that is marginal.

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 (ongoing rank tracking) and describes the concrete data sources it aggregates (Search Console, Ahrefs Rank Tracker, Semrush Position Tracking, GA4). An agent can tell it is a rank-tracking aggregation tool, though it never explicitly names or differentiates from the sibling 'tracking'/'watch' tools.

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

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

'Use for ongoing rank tracking without picking keywords by hand' gives a clear use context, and it explains the first-run bootstrap ('leave it out on the first run to create a tracker'). It stops short of stating when NOT to use it or which sibling to prefer.

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 annotations (readOnlyHint=false, openWorldHint=true), the description discloses that the tool runs automatically, posts to a webhook, and follows schedules (every 1/7/30 days, every 6 hours, weekly). It also describes mode-specific actions and required IDs, which enriches behavioral understanding.

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

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

The description is front-loaded with the core purpose and then organises mode details in a readable sequence. While dense, it avoids filler and is appropriately sized for a 15-parameter multi-mode tool.

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

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

With an output schema and full schema descriptions, the description need not explain return values. It covers the main modes and schedules, but leaves action/ID usage for guard, site_audit, and competitors unspecified, which is a minor 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 100%, so the baseline is 3. The description adds cross-parameter meaning by mapping modes to required parameters (e.g., page needs url, page_status needs watch_id), though it omits such mapping for guard, site_audit, and competitors.

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 the tool's purpose as autonomous monitoring that posts changes to a webhook, and enumerates six modes with specific resources (page, site, robots.txt, etc.). It does not contrast the tool with siblings like site_audit or tracking, so it stops short of the top score.

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

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

It gives clear context for each mode (e.g., page for SEO changes, guard for deploy accidents) and notes action create/status/stop. However, it offers no explicit guidance on when to choose this tool over alternatives such as the site_audit or tracking siblings.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world semantics, and the description adds real value on top: the data source is real Chrome user field data, and trend returns weekly history segmented before/after a change date. It does not mention quotas, latency, or auth, which is a minor gap given the annotation coverage.

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

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

Three tight sentences that front-load the resource, then the mode decision rule; no filler or repetition of the title. Every clause carries either scope or a selection condition.

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

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

With a full schema, an output schema covering return values, and annotations covering the safety profile, the description supplies the missing decision logic (which mode, what each needs). It stops short of clarifying optionality of change_date within trend or what 'brief' detail omits, but nothing critical for correct invocation is absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely enhances the mode enum by explaining what each value returns, and ties url/change_date to the mode that requires them. It leaves detail and memory_key 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?

Names a specific resource — Core Web Vitals field data from real Chrome users — and splits it into two clearly labeled modes (now = latest field data, trend = weekly history). An agent can tell what it returns, though there is no explicit differentiation from nearby siblings like measure or technical.

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?

'Pick with mode: now = ... trend = ...' gives a direct selection rule for the two modes, and each mode states its prerequisite ('Needs url'). No alternative-tool routing or exclusion guidance against the other 30+ siblings is offered, which keeps it short of a 5.

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