OnPage.dev

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 useful behavior (it merges into existing robots.txt and returns the full new file plus a diff), but it leaves the critical ambiguity unresolved: whether rules are actually applied to the live site or merely returned for the caller to apply, which is the one thing an agent most needs to know here.

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

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

Front-loaded with the action and target, then the policy vocabulary, then the return value. No redundant restatement of the title or annotations; every clause carries information.

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

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

With no output schema, the description correctly explains the return payload (full new robots.txt and what changes), and both parameters are documented. The gap is merge semantics: it never says whether existing rules are preserved or overwritten, nor whether the result is applied live, which matters for a tool that edits a site's crawler policy.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description genuinely enriches the enum beyond the schema's terse 'Which AI crawlers to allow' by defining search_only as allowing AI search and user-requested fetches while blocking model training, and noting block_training is an alias. The url parameter's 'any page of the site' semantics come only from the schema.

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

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

The description gives a specific verb pair and resource: write robots.txt rules for AI crawlers and merge them into the site's current robots.txt. The purpose is unmistakable and functionally distinct from sibling tools like test_robots or generate_llms_txt, though no sibling is named explicitly to make the boundary airtight.

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 the enumerated policy modes (allow_all, search_only, block_training, block_all), each paired with a behavioral gloss, which tells the agent what each input means. However, there is no explicit guidance on when to choose this tool over test_robots or generate_llms_txt, and no stated prerequisites.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds a genuine behavioral caveat not in annotations: for localhost/staging-behind-login pages the server-HTML comparison is skipped. It does not describe the return value, though an output schema exists.

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

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

Single sentence, front-loaded with the core action before the parenthetical checklist, and the non-public-page caveat is a clean second sentence. The long inline list of checks is dense but each item is informative; slight bloat keeps it from a 5.

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

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

For a read-only analysis tool with full annotation coverage and an output schema, the description is nearly complete: it explains inputs' provenance, checks performed, and the non-public-page caveat. Nothing critical for correct invocation is missing, though the absence of result-format framing 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 description coverage is 100%, so url, results and the optional no_js probe are already documented with examples. The description only alludes to 'probe result' generically and adds no format, ordering, or per-viewport semantics 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?

States a specific verb (analyse) and resource (the layout probe results) and explicitly positions itself against siblings: it consumes get_layout_probe output and runs 'the same checks as render_page' plus a server-HTML comparison. An agent can distinguish it from render_page/get_layout_probe 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?

It makes clear this operates on get_layout_probe output 'measured in your own browser' and states one exclusion (non-public pages skip the server-HTML comparison). It does not name a competing tool or say when NOT to use this versus render_page, so it stops short of explicit routing.

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 closed-world behavior, but the description adds important operational context: accepted log formats, a 5000-line limit, sitemap-based analysis, and a privacy warning that logs may contain visitor IPs requiring user consent. This is rich disclosure beyond the annotations without contradicting them.

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 and bot list, then flows into output dimensions, input constraints, and privacy guidance. The bot enumeration is long but informative, and every sentence earns its place.

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

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

With no output schema and full schema coverage, the description still explains what the analysis returns (hits per bot, top pages, errors, redirects, crawl budget, never-visited pages from sitemap) plus input limits and privacy requirements. It is complete enough for an agent to call the tool correctly.

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

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

Schema coverage is 100%, so parameter descriptions are already documented. The description still adds value by specifying compatible log formats ('common or combined ... Apache, Nginx, Cloudflare, most hosts'), a line limit not present in the schema, and the purpose of sitemap_urls for finding uncrawled pages.

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: 'Analyse server access log lines to see what Googlebot, Bingbot and AI crawlers ... actually request'. Enumerates the exact bot set and output dimensions, making it immediately distinguishable from siblings like test_robots or ai_crawler_policy.

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?

Clear context for when to use it: supply raw lines in common/combined log format for bot-crawl analysis, with an optional sitemap to find never-visited pages. No alternatives or exclusions are named, 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it discloses what is inspected (robots.txt per bot, llms.txt, 15 content checks, plain-text view), which tells the agent what work is performed and what data comes back. It does not mention that it fetches the live remote page or any latency/rate considerations.

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

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

The main action and scope are front-loaded in the opening clause, and the parenthetical detail on the 15 checks is informative rather than filler. It is a single long sentence with heavy nesting, which costs some readability, but nothing is clearly redundant.

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

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

With no output schema, the description carries the burden of indicating what the tool returns, and it does sketch the return surface (per-bot robots results, llms.txt presence, citability signals, plain-text rendering). For a multi-check diagnostic tool this is close to complete, though it doesn't say how findings are grouped or whether scores are returned.

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

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

There is one parameter with 100% schema description coverage, and the schema already explains the accepted format including bare domains, so the baseline is 3. The description adds nothing about the url parameter beyond what the schema provides.

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

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

The description names a specific verb and resource ('check whether AI crawlers may read a page') and enumerates the concrete sub-checks: per-bot robots.txt, llms.txt existence, 15 citability checks, and plain-text rendering. That composite scope implicitly separates it from narrow siblings like test_robots or validate_llms_txt, but no sibling is named, so the differentiation is left to inference.

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

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

It gives a clear usage trigger with a real user question ('why does ChatGPT not mention my site'), which tells an agent when to reach for it. It stops short of exclusions or alternatives — it never says to use test_robots or ai_crawler_policy when only the crawler policy is in question, even though those siblings overlap.

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=true, and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond that: it lists the specific checks performed (entity presence, @id linking, sameAs targets loading, homepage consistency) and states it returns the graph, issues with stable codes, and a suggested JSON-LD block with TODOs. This is highly informative about the output and process.

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

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

It is essentially one long sentence detailing the checks, followed by a second sentence on return values. It is front-loaded with the core purpose, but the enumeration is dense and could be slightly more structured for readability. However, every clause adds value.

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 a rich output schema, the description is complete: it covers what is checked, how it relates to AI knowledge graphs, and what is returned (graph, issues, suggested block). No critical information is missing for an agent to call it correctly.

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

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

Schema description coverage is 100% and the single 'url' parameter is well-documented in the schema. The description doesn't add format details for the parameter, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Check how a page's structured data describes who and what it is about') and then enumerates exactly what is examined: entities, @id linking, author/publisher as entities, sameAs profile targets, and Organization matching. This is highly specific and clearly distinguishes it from siblings like validate_schema (validation) or generate_schema (creation).

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 doesn't explicitly say when to use this tool versus alternatives like validate_schema or generate_schema. The 'the way AI knowledge graphs read it' framing implies an AI-visibility use case, but no when-to-use or when-not-to-use guidance is provided.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world). The description adds real behavioral detail: it discloses the eight checks returned and flags keyword density stuffing above 3%, which is a concrete threshold not present in any annotation.

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

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

One sentence, front-loaded with the core verb and resource, then the element list, then the return characteristics. Every clause carries information.

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

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

For a two-parameter read tool with full schema coverage and annotations, the description is nearly self-sufficient: it names the checks performed and a notable flagging rule. It could still note the URL format tolerance already in the schema, but otherwise there is little an agent needs that 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 both url and keyword are fully documented with examples. The description adds no syntax, format, or edge-case info beyond what the schema provides. 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?

States a specific verb ('Check'), a specific resource ('how well a page targets one search term'), and enumerates exactly which elements are inspected. This clearly distinguishes it from nearby siblings like check_snippet or scan_page, which do not share this element list.

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

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

The description implies a use case (verifying keyword targeting), but it never states when to choose this over check_snippet, scan_page, or deep_audit. No exclusions or alternatives are named, so routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: it actually fetches and measures the share image (does it load, real pixel dimensions, file type, weight) and returns a score plus fix list. It omits any mention of rate limits or auth for the hosted endpoint.

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 action and platform list, then the return contents. It is dense but every clause carries information. The trailing REST API promotion is slightly tangential but still offers a real alternative path, so only minor trimming is warranted.

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 restated in depth, and annotations cover the safety profile. The description supplies scope (which tags, which platforms), the image-validation depth, and the alternative endpoint — everything an agent needs to select and call it correctly.

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

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

Schema description coverage is 100% ("Full address of the page."), so the single url parameter is fully documented structurally. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: checks every Open Graph and Twitter Card tag plus the share image itself. Enumerates the concrete surfaces (Facebook, LinkedIn, X, WhatsApp, Slack, iMessage) and the image properties verified (loads, pixel size, file type, weight), which clearly separates it from neighbors like check_snippet or validate_schema.

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

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

Gives clear context for when to reach for it: verifying how a page renders when shared. It also names an external alternative (the free REST endpoint GET /api/v1/og?url=...). It does not explicitly contrast with the closest sibling tools (e.g. check_snippet) or state exclusions, 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 cover safety (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds valuable behavioral detail: competitors are scanned one per call requiring repeated invocations, and return contents are enumerated (formula per language, average sentence length, long sentence share, hardest sentences).

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 is good, but the second sentence is long and dense, packing page-type enumeration, competitor sourcing, scanning mechanics, and return values into one run-on. The language-formula list is thorough but verbose.

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

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

Given output schema exists, the description needn't explain return values, yet it still enumerates key outputs. It covers the decision of what to pass for benchmarking and the multi-call competitor flow, making it complete for correct invocation. Minor gap: no explicit note that page type is inferred rather than passed as a parameter.

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 real meaning: it explains that page type drives the target, that keyword provides context, and that competitors come from Ahrefs/Semrush top organic results and are consumed one at a time. This is beyond the schema's flat descriptions.

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

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

States a specific verb (check) and resource (readability of a page) with clear scope: measuring reading ease against a page-type-dependent target and competitor benchmark. Distinguishes itself from siblings like check_focus_keyword or check_snippet by naming the readability metric and the benchmark comparison.

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

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

Clearly explains when deep benchmarking applies: 'for the best benchmark, also pass the keyword and the top results' and that competitors are scanned 'one per call, call again until done.' Missing an explicit statement of when not to use it vs. siblings, but the usage context 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 closed-world, so safety is covered. The description adds genuinely new context: 'No network call' (local, instant, no quota) and what the result contains (pixel width, cut-off, truncated preview), which the agent could not infer from annotations alone.

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

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

Two sentences, zero padding, and the core capability is front-loaded before the usage note. 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?

With no output schema, the description correctly compensates by describing the return content (pixel widths, desktop vs mobile cut-offs, truncated text). The only small gap is that it never notes the description param is optional or whether a title-only check is meaningful.

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% with only two simple string params, so the schema already carries the load. The description restates that the inputs are a title and meta description but adds no format, length, or optionality guidance (e.g. that description is optional). Baseline 3 applies.

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

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

States a specific verb and resource ('Estimate how a title and meta description show in Google') and enumerates the concrete outputs (pixel width vs desktop/mobile cut-off, truncated text). This clearly distinguishes it from siblings like check_focus_keyword, check_ai_visibility, or validate_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 frames the workflow: 'Use it to iterate on title and description variants until they fit.' That tells the agent when this tool belongs in a loop, though it names no alternative tools or exclusion conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds real value beyond them: the 20-URL batch ceiling, the fact that it returns the entire redirect chain, and that results can be verified against expected targets.

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

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

Three short sentences, front-loaded with what the tool does, then use cases, then the verification option. Every sentence carries information and nothing is padded.

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

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

With an output schema present, return-value details are covered elsewhere, and the description still adds batch limits and redirect-chain semantics. Combined with full annotations and 100% parameter coverage, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline would be 3; the description slightly exceeds it by explaining the intent of 'expected' as verifying that each redirect lands where intended. It still leaves the ordering/integer semantics of 'expected' 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?

The description gives a concrete verb+resource (check URLs) and names the exact outputs — final status code, full redirect chain, and final destination — so an agent immediately knows what this returns. It does not explicitly name or contrast any sibling tool (e.g., test_robots or scan_page), so differentiation is implied rather than stated.

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

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

It supplies clear triggering scenarios — site migrations, broken-link sweeps, launch checks — and a concrete example question ('do all old URLs 301 to the right new page?'). It never states when NOT to use it or names an alternative, so it stops short of explicit 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: the data source is real Chrome users (CrUX), values are rated good/needs-improvement/poor, and there is an automatic fallback to site-level data when a page has too little traffic.

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 tightly packed sentences, front-loaded with what is returned, followed by the fallback caveat and the sibling pointer. No filler, and the alternative tool mention comes last where it belongs.

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

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

With no output schema, the description compensates by enumerating the returned metrics, their aggregation level (75th percentile), device breakdown, and rating scale. Combined with the fallback note, an agent has enough to call it and interpret results without a return schema.

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

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

Schema description coverage is 100% and there is only one required parameter, so the schema already carries the parameter semantics. The description implies the URL is a page address but adds no format or constraint detail beyond that, so the baseline 3 applies.

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

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

The description names the exact resource (Core Web Vitals from the Chrome UX Report), lists the specific metrics returned (LCP, INP, CLS, FCP, TTFB), the percentile, and the device split. It also states what it is not (lab checks), clearly separating it from the sibling render_page.

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 routes the agent: this tool is for real-user field data, and 'Use render_page for lab checks of the first screen' names the alternative and the condition that selects it. The fallback-to-site-level behavior also tells the agent what to expect when a URL has limited data.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive), and the description adds important operational context: API-unit costs for Ahrefs reports, a max of 8 pages to limit cost, and the OnPage.dev scan lifecycle (one page per call, results kept 15 minutes, re-call until complete). It does not detail return format, but an output schema exists.

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

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

Front-loads purpose well, but the middle sentence is dense and runs together multiple alternatives, costs, and the OnPage.dev lifecycle, making it harder to parse. Content earns its place, but organization could be clearer.

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 when to use it vs. check_ai_visibility, cost/privacy constraints, and the async scan behavior, which are the main things an agent needs. Output schema and annotations fill remaining gaps about returns and safety.

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

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

Schema coverage is 50%. The description explains why to include low-citation pages (so uncited ones return 0) and the 8-page cost cap, which reinforces the schema constraints, but it doesn't explain the per-engine count fields (grok, gemini, etc.) or the source enum beyond naming common sources. Baseline 3 fits given partial schema coverage.

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: comparing cited vs. skipped pages, using citation counts from connected tools. Distinguishes from sibling check_ai_visibility, which it names as the fallback when citation data is missing.

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 branching: if Ahrefs with Brand Radar is connected use its cited pages report; otherwise any AI-visibility source works; without citation data use check_ai_visibility. Also instructs including low/no-citation pages so comparison is possible, and caps the request at 8 pages.

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 closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: issues are reported with stable codes and the exact fields diffed (title, description, H1, canonical, robots, structured data, word count).

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

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

Two sentences, no filler, with the core action and scope front-loaded and the usage trigger placed last. Every clause carries information the 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?

An output schema exists so return values need not be spelled out, yet the description still summarizes what comes back, and it covers inputs, use case, and safety context. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and all three parameters (url, before, after) are documented in the schema itself. The description only restates the before/after relationship already implied by the param names, adding no syntax, format, or constraint details beyond the schema.

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

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

States a specific verb (compare) and resource (two versions of a page's HTML, e.g. before/after a code change) and scopes the output (SEO score, issues fixed/introduced, field-level changes). The 'two versions of the same page' framing distinguishes it from the sibling compare_pages, which implies comparing distinct pages.

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

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

Gives a concrete usage scenario ('use it in code review to catch SEO regressions before they ship'), which tells the agent when this tool belongs in a workflow. It stops short of explicitly contrasting with compare_pages or rescan_and_compare, so the choice between near-neighbors 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?

Discloses non-obvious runtime behavior well beyond the annotations: one page scanned per call, results retained for 15 minutes, and required re-invocation with identical arguments until complete. This is exactly the kind of stateful/caching detail that is consistent with (and enriches) the idempotentHint=false annotation.

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

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

Front-loaded with the core comparison purpose and reasonably sized for a feature-rich tool, but the long enumerated list of outputs is dense and slightly run-on. Nearly every phrase carries information, so little should be cut.

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

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

Given the output schema exists and return values need not be explained, the description covers everything an agent needs: what is compared, the 1-page-per-call cadence, the 15-minute retention window, and the repeat-call protocol. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% and all three parameters are documented in the schema, so the baseline is 3. The description only restates that competitors are 'up to 3' and that keyword is for keyword-use comparison, adding no syntax or format detail beyond the schema.

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

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

States a specific verb (compare) and resource (a page vs up to 3 competitor pages ranking for the same search), and enumerates the concrete comparison dimensions. This is clearly distinguished from siblings like compare_html and compare_ai_citations by scoping the comparison to ranking competitors.

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 use context (competitor pages ranking for the same search) and an unusual but important usage rule: because it scans one page per call, multiple new pages require repeated calls with the same arguments. It does not name explicit alternatives or when-not-to-use conditions, 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?

Adds substantial behavior beyond the annotations: the scan is asynchronous and cached ("one page per call, kept 15 minutes; call again with the same arguments until complete"), which explains the non-idempotent polling pattern the annotations only hint at. It also discloses that passing url narrows output to what the existing page is missing. This is exactly the operational context an agent needs before invoking.

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 dense throughout, with the polling instruction parenthetically embedded where it is needed. It spends a long clause enumerating return values that an output schema already covers, which is mild redundancy, but no sentence is filler.

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

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

For a 4-parameter tool with an output schema, the description covers prerequisites (competitor URLs), async completion semantics, and the two optional-parameter branches. Nothing an agent needs to call it correctly is missing; the output enumeration is redundant but harmless.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: url means "improving an existing page" and changes the result to only missing items, and audit_id must come from a finished site audit and unlocks internal-link suggestions. The competitors count (1 to 3) is restated rather than expanded.

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 artifact ("Build a writing brief") scoped to a search term derived from ranking pages. It clearly distinguishes this from sibling audit/check tools by naming its inputs (competitor URLs) and its output class (subtopics, questions, target length, structured data). An agent can identify this tool without opening the schema.

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

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

Gives concrete workflow guidance: where to source competitor URLs (own search tool, Ahrefs, Semrush, or the user, 1-3) and the conditional use of url (improving an existing page). It cross-references start_site_audit for audit_id. It lacks explicit when-not-to-use guidance versus brief-adjacent siblings, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds value beyond that by disclosing that results are organized by section, that scoping sections shortens the answer, and that every issue carries a stable code trackable across scans — useful output-behavior context.

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

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

Front-loaded with the scope statement, then the section enumeration, then the sections-scoping hint and the stable-code note. The long middle enumeration earns its place by previewing the section taxonomy, though the single run-on sentence is dense.

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

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

With an output schema present, the description needn't explain returns, and it correctly focuses on scope, section behavior, and issue-code stability. The one meaningful omission is sibling routing, but for a read-only audit tool with full schema and annotation coverage the definition is otherwise 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 description coverage is 100%, so the schema already documents url and sections (including the 'Default: all' behavior). The description's human-readable section names loosely map to the enum values but add no syntax or format detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb and resource ('deep audit of a page') and enumerates exactly what is measured by section, so an agent knows the scope of the audit. However, it never distinguishes itself from the sibling scan_page, which sounds like the same operation, leaving the agent to guess which is the deeper 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 only guidance is parameter-level: 'Pick sections to keep the answer short, or leave them out for all.' There is no when-to-use, when-not-to-use, or routing against the many siblings (scan_page, scan_html, get_site_audit, check_urls) that an agent must choose between.

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

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

Annotations already flag openWorldHint=true and non-idempotent, and the description explains why: it can hand output to external tools or POST to an https webhook, and it generates per-issue tasks. It adds real context (CSV link usable via IMPORTDATA with no connector) beyond the safety annotations, though it never states reversibility or auth requirements.

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

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

Dense but front-loaded: the purpose leads, then the outputs, then routing guidance, then parameter selection last. The long output enumeration is justified because the agent must know what payloads it is expected to forward, though it borders on over-listing.

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 returns, yet it usefully characterizes the handoff payloads and the external-effect behavior consistent with the annotations. Nothing critical is missing for calling it, aside from any auth or rate-limit caveats for the connected destinations.

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 selection semantics the schema does not: url targets one page, audit_id targets a whole site from start_site_audit, and the webhook accepts Slack/Discord/Teams and is optional. This meaningfully disambiguates which parameter to use.

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 transformation ('turn a page scan or a finished site audit into an action plan') and enumerates the concrete artifacts produced. It is clearly distinguishable from start_site_audit/get_site_audit, which produce the audit rather than the export.

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 instructs the agent to route output through a connected Sheets/Slack/Notion/task-board tool, and to use the webhook only optionally. It gives clear positive conditions but no when-not guidance or sibling alternatives to fall back on.

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 genuinely non-structured behavior: it discloses the return shape (top passages with heading and word count) and a concrete quotable-length rule of 40 to 90 words. That is real added value, though nothing is said about fetch failures, blocked pages, or how many passages are returned.

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

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

Two sentences, zero waste, and the primary purpose is front-loaded before the return-shape and usage details. Nothing is repeated from the title or schema.

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

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

With no output schema, the description usefully compensates by describing what comes back (passages plus heading, word count, quotable-length flag) and how to act on it. Combined with annotations covering the safety profile, an agent has enough to call it correctly, though limits on result count and failure modes 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 description coverage is 100% and both parameters are documented in the schema with examples, so the schema carries the burden. The description adds no parameter-level detail (no URL normalization, no question phrasing guidance) beyond what the schema already states, making the baseline 3 correct.

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 ('Find the passages on a page that best answer a given question') and adds a framing device — 'the way AI answer engines pick text to quote' — that meaningfully sharpens what kind of passages are returned. It stops short of naming or distinguishing itself from nearby siblings like check_snippet or check_ai_visibility, so an agent still has to 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?

The second sentence gives downstream usage ('judge whether the page answers the question well... rewrite the best passage into a direct answer'), which implies context but is about what to do with output rather than when to select this tool over alternatives. No explicit when-not or alternative is named among the ~19 siblings, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral value beyond that: the content is derived from an existing sitemap and home page, and the result is "ready-to-upload", clarifying that it does not publish to the site itself. It stops short of describing fetch failures or how the sections are chosen.

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

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

Two sentences, zero filler. What is produced comes first, the upload instruction second, and the example URL is a compact concrete illustration.

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

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

With no output schema, the description carries the return-value burden and does so by naming the file's sections (site name, summary, grouped main pages). Combined with the annotations covering read-only/idempotent behavior and a fully documented single parameter, an agent has everything needed to select and call it correctly.

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

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

There is a single parameter with 100% schema coverage, so the schema baseline applies. The description goes slightly beyond it by explaining that the url is consumed together with the site's sitemap to produce the output, contextualising why a home-page URL is required.

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

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

The description gives a specific verb ("Build") and resource ("llms.txt"), and even enumerates the produced contents (site name, summary, main pages grouped by section). It is distinct from siblings like generate_schema or generate_schema, though it never explicitly contrasts itself with any of them.

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

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

Usage is implied rather than stated: the tool builds an llms.txt for a site, and the description explains where the artifact belongs (site root). There is no when-to-use trigger, no prerequisite (e.g., site must have a sitemap), and no alternative named.

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 carry readOnly/idempotent/non-destructive/openWorld, so the description's real value is the behavioral detail it adds: output is validated against Google's rich result rules and unreadable values are marked TODO rather than fabricated. That is useful non-obvious behavior for an agent to know, though nothing is said about how validation failures are surfaced.

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 action and constraint, then the type list. The enumeration is long but each entry carries a derivation hint, so little is wasted; a slightly tighter phrasing would earn a 5.

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

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

There is no output schema, so the description must characterize the return, and it does: a JSON-LD block plus validation against rich result rules, with TODO markers for missing values. It stops short of describing the validation result shape, leaving a minor gap for a tool with no 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 100%, so the schema floor is 3, but the description adds real meaning beyond the enum labels: it explains how FAQPage is built from question headings, how Organization pulls sameAs links, how BreadcrumbList derives from the URL, and that 'auto' selects the best fit. That meaningfully enriches the parameter choice.

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 ('Generate a JSON-LD block for a page from its own content') and adds a distinct validating behavior. It clearly separates itself from the validate_schema sibling by being the generator whose output is checked against Google's rich result rules.

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 enumerates the supported types and their derivation sources, which implies when each is appropriate, and explains 'auto' as picking the best fit. However it never says when to choose this tool over the closely related validate_schema sibling, so routing guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds real workflow context beyond that: only issues the page actually has are emitted, WordPress changes require per-change user approval, and git output is a PR on a new branch gated by scan_html. It does not cover auth or rate limits, but for a read-only generator this is strong.

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, but the first sentence is a long run-on enumerating six artifacts and the platform branches are delivered as dense prose that overlaps with the schema's enum descriptions. Every sentence carries information, yet the packaging makes it harder to scan than it needs to be.

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

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

There is no output schema, so the description carries the full burden of describing returns, and it does: it describes the artifact bundle for html, the field-level plan for wordpress, and the framework code plus PR steps for git. An agent has enough to call it correctly and anticipate the response shape.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds meaning the schema does not: it spells out the downstream consequence of each platform value and notes that framework auto-detection only applies with platform git.

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 ('generate ready-to-paste fixes') and enumerates exactly what is produced (title tag, meta description, canonical, OG tags, viewport, JSON-LD), then branches on platform. It is clearly distinguishable from siblings like prioritize_fixes (which ranks, not generates) and generate_schema (single artifact, this builds a bundle).

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

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

Explains the conditions that select each mode (platform html/wordpress/git) and names a downstream step (scan_html before merge, user approval per change). It stops short of saying when to prefer prioritize_fixes or generate_schema 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 readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds genuinely new behavioral context: no daily limit (rate limits), works behind a login or on localhost (auth/network reach), and the sequencing constraint that the script must run after page load. This is exactly the beyond-annotations value the rubric rewards.

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, front-loaded with what is returned, then how to use it, then when to choose it. Every sentence carries distinct information with no redundancy.

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

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

With no output schema, the description correctly explains what is returned (a script), the required execution step, the per-viewport loop, and the downstream handoff to analyze_layout. Nothing an agent needs to call and use it is missing.

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

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

The tool takes no parameters (0 count, empty properties), so there is nothing for the description to clarify and the baseline of 4 applies. No misleading parameter claims are made.

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 a JavaScript measurement script) plus its exact output, and positions it relative to siblings by naming analyze_layout as the consumer of the results. An agent can distinguish it from render_page, screen_reader_view, or analyze_layout without opening any schema.

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

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

Gives clear operational context: run it per viewport after page load, pass results to analyze_layout, and 'Use this when you have a browser' with the payoff of no daily limit and login/localhost support. The when-not case (no browser) is implied rather than routed to a named alternative, so it falls short of 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 readOnly, non-destructive, open-world, and non-idempotent, and the description is consistent with them while adding genuinely new behavior: each call advances the crawl by scanning the next pages, callers must loop until completion, and audits expire after one hour. It does not cover what happens on an expired or invalid audit_id, keeping it below the top mark.

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

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

Three short sentences, front-loaded with the prerequisite and the polling loop, then the retention constraint. Every sentence carries information an agent needs and none is redundant.

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

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

An output schema exists, so return values need no explanation, and the description covers the loop, status transition, and TTL. The remaining gap is failure handling for an expired or unknown audit_id, which an agent would otherwise have to discover at call time.

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?

Only one parameter exists and schema description coverage is 100%, with the schema itself already noting the id comes from start_site_audit. The description adds no further syntax, format, or validation detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Continue a site audit'), names the originating tool start_site_audit, and makes the differencing clear versus the sibling that begins an audit. An agent can distinguish this polling tool from start_site_audit without opening either schema.

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

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

Gives clear context ('started with start_site_audit') and an explicit operational instruction to keep calling until status is complete, which routes the agent correctly among siblings. It stops short of explicit when-not guidance or error/expiry conditions, so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral detail: it returns the latest snapshot, the last-checked time, and every change found so far, newest first. It does not describe error behavior or output formatting, but those are minor gaps 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?

The description is a single, front-loaded sentence that packs the tool's purpose, the prerequisite creation tool, and the returned content without any wasted words. It is appropriately sized for a simple read tool.

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

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

For a one-parameter read-only tool with no output schema and full annotation coverage, the description gives a good sense of what is returned (snapshot, last checked, change history). It stops short of detailing invalid-ID behavior or result ordering beyond 'newest first', but that is a minor omission for this complexity level.

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 for watch_id is 0%, so the description must compensate. It implies that watch_id is the identifier of a watch created by watch_page, which gives the agent a source for the value, but it does not explain the parameter's format, provenance explicitly, or any constraints. This is minimally adequate but not rich.

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 (read) and resource (a watch created with watch_page), and distinguishes it from the sibling that creates watches (watch_page) as well as the deletion sibling (unwatch) by implication. An agent can immediately tell this is the fetch/inspect operation for an existing watch.

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

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

It clearly establishes the prerequisite that the watch must have been created with watch_page, which tells the agent when this tool is applicable. It does not explicitly state when not to use it or name alternatives like unwatch, so it falls one step 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 readOnly, idempotent, open-world, non-destructive, but the description adds genuinely new operating context: scanning is one page per call and must be repeated with identical arguments until done, and competitor data requires an externally connected Ahrefs/Semrush SERP tool. It does not explain the repeated-call relationship to idempotency, so not a 5.

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

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

It is front-loaded with the core action and every sentence carries information (mode selection, prerequisites, output meaning). However it is a dense run-on paragraph with several nested clauses, which costs readability that a short bulleted mode list would have provided.

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 available, return values need not be described, and the description covers the multi-mode behavior, external tool prerequisite, and batching constraint. The one gap is that all four parameters are optional and the description never states the minimum viable call (url plus keyword), leaving an agent unsure what combination is valid.

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 semantics: competitors should be 5-8 ranked URLs obtained from a SERP tool, queries are Search Console rows used to find pages competing for the same query, and the meaning changes when competitors are omitted. It expands on the schema rather than repeating it.

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

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

The opening sentence states a specific verb and resource: evaluating whether a page matches searcher intent for a keyword based on what actually ranks. That is materially distinct from sibling tools like check_focus_keyword, check_snippet or compare_pages, and the agent can tell them apart without opening schemas.

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

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

The description clearly routes between three modes: pass competitors (needs a connected SERP tool), pass no competitors (keyword wording plus your page only), or pass Search Console queries for a site-wide check. It does not name sibling alternatives or state when this tool should be preferred over check_focus_keyword/compare_pages, so it falls short of a 5.

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

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

Annotations already establish read-only/idempotent/non-destructive behavior, but the description adds substantive context beyond them: the control-group subtraction to remove seasonality and Google-update noise, the watch-history enrichment, and an explicit data-handling statement that numbers are used for this answer only and not stored.

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

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

Dense but front-loaded, leading with the payoff question before the mechanics. It is a long single block of prose, yet nearly every clause carries actionable information about inputs or method.

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

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

The output schema covers return values, so the description only needs to explain inputs, method and caveats — which it does. Data preparation, detrending rationale, watch_id enrichment and privacy are all addressed, leaving no obvious gap 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?

With 60% schema coverage, the description compensates well: it explains the two-period design behind before/after, the meaning of changed=true/false and the control group, a suggested value for days, and the role of watch_ids in listing per-page changes. It adds real meaning beyond the raw 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 outcome ('Show whether SEO fixes paid off') plus the mechanism (before/after periods from connected tools, control-group detrending). This is clearly distinguishable from siblings like get_watch or rescan_and_compare, which track or re-scan rather than quantify impact.

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 concrete operating instructions: fetch two equal-length periods (28 days suggested) from GSC/GA4/Ahrefs/Semrush, include changed=true pages plus an ideal control group, and pass watch_id to see what changed. It stops short of naming when NOT to use it 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 readOnly/idempotent/openWorld/non-destructive, and the description adds genuinely new behavioral detail: per-URL confidence scoring, flagging of unmatched URLs with suggestions, and concrete output formats. The phrase 'write the redirect rules' is slightly at odds with readOnlyHint, but since the rules are emitted as text rather than applied, this reads as generation, not mutation.

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

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

Purpose is front-loaded in the first clause, followed by inputs, output behavior, and the verification handoff. The single long first sentence is dense but every clause carries information; only minor trimming would be possible.

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 not strictly required, yet the description usefully summarizes the output shape (confidence scores, flagged unmatched URLs, format choices). Combined with annotations, an agent has enough to invoke it correctly, with only the input-precedence rule (list vs site) left implicit.

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

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

Schema coverage is 60%, and the description compensates by explaining that old/new URLs can be supplied either as a list or as a site address whose sitemap will be read. It also ties the 'redirects' format to Cloudflare Pages and Netlify (_redirects), adding meaning beyond the enum label.

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: matches old URLs to new ones and generates 301 redirect rules for migrations/restructures. It is distinguishable from siblings, and it explicitly names check_urls as the post-live verification step, so the agent can route correctly.

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

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

Gives clear context for when to use it (site migration or restructure) and routes the agent to check_urls for post-deployment verification. It lacks an explicit 'when not to use' clause, but the alternative and its condition are stated, which is close to full 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/openWorld, but the description adds substantial non-obvious behavior: pages are scanned by OnPage.dev 3 per call and cached 15 minutes, exceeding that count triggers a re-call with identical arguments, audit_id from a finished audit skips rescanning, and traffic data is not stored. This is exactly the operational context annotations cannot convey.

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

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

Front-loaded with purpose before mechanics, and almost every sentence carries actionable detail (limits, pagination, privacy, prerequisites). It is a dense single block with no visual structure, which costs a point, but there is little waste.

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

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

For a tool with an output schema, prerequisites, batch limits, cache/retry behavior, optional audit reuse, and the no-data fallback are all disclosed. Nothing an agent needs to invoke it correctly or interpret the trade-offs is missing.

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

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

Schema coverage is already 75%, so the baseline is high, but the description adds real meaning beyond the schema: it explains why conversions/revenue change the ranking dimension ('ranked by the money they can bring instead of clicks') and frames clicks_previous as a content-refresh signal. It does not add syntax for source/currency, keeping it just below a 5.

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

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

States a specific verb+resource+scope: 'Rank SEO fixes by how much traffic they can win,' and immediately qualifies the ranking basis (traffic/clicks vs. money via conversions/revenue). An agent can tell this apart from siblings like get_fix_pack or measure_impact because the outcome (prioritized fix ranking) is named precisely.

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 prescribes the pre-call workflow (fetch top pages/queries from connected GSC/GA4/Ahrefs/Semrush), states when to add conversions/revenue (GA4 present -> rank by money), when to pass clicks_previous (catch declining pages), and what happens when no traffic data exists. When-and-how guidance is fully covered.

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

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

Goes well beyond the annotations: it discloses a daily browser-time budget/rate limit, that it returns screenshots, that it also loads with JavaScript off, and specifies the exact fallback path when the budget runs out. The readOnly/openWorld annotations cover safety, and the description layers operational constraints on top.

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 action and viewports, and the budget/fallback caveat is placed last where it belongs. It is dense — a long chain of clauses that could be bulleted — but nearly every clause conveys a distinct check, 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?

For a complex multi-viewport rendering tool, the description covers inputs, breadth of checks, JS-off behavior, and operational limits, and an output schema exists so return structure needn't be restated. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the single url parameter is already documented with a format example, so the description adds no further parameter meaning. Per the calibration rule, baseline 3 is correct when the schema carries the parameter burden.

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

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

States a specific verb (load/render) and resource (a page in a real browser at three named viewports) and enumerates exactly what it inspects. It clearly distinguishes itself from siblings by naming get_layout_probe and analyze_layout as the fallbacks.

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

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

Explicitly states when to use it (checking the first screen at phone/tablet/desktop) and when not to — when the daily browser budget is exhausted or when the agent has its own browser tool — and routes to named alternatives. Every routing condition is spelled out.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false and destructiveHint=false, so safety is covered. The description adds meaningful context the annotations do not: it performs a fresh live scan and depends on a prior scan of the same page existing, and it is intended for repeated invocation. It does not mention cost, rate limits, or latency of a live re-scan.

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

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

Three sentences, front-loaded with the core action and followed by what the comparison returns, then the usage trigger. Every sentence carries distinct information with no repetition or filler.

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

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

With no output schema, the description usefully enumerates the comparison outputs, and annotations cover the safety profile. The one soft spot is that the dependency on a pre-existing scan is only implied by 'the previous scan of that page', not stated as a prerequisite, so an agent could invoke it on a never-scanned URL.

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

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

There is a single parameter with 100% schema description coverage (including a format example and the note that a bare domain works). The description adds no syntax or constraint information beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb+resource (rescan a live page and compare against its previous scan) and enumerates what the comparison yields: score change, issues fixed, new issues, AI readiness change. This clearly separates it from siblings like scan_page (no comparison) and compare_pages (cross-page rather than temporal comparison).

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

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

It gives explicit usage context: 'use this after deploying fixes to confirm they worked' and for catching regressions such as a robots.txt change blocking AI crawlers. It also advises iterating until the score is acceptable. No alternatives are named, but the when-to-use condition is unambiguous.

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

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

Annotations already declare read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description still adds real value by disclosing what the call returns ('same score, fixes and AI readiness as scan_page') and clarifying that url is only a resolution aid rather than a fetch target; it does not mention rate limits or the 900 KB ceiling (that lives in 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 sentences, each carrying distinct load: what to scan, what comes back, and the deployment-time use case. The primary differentiator (unpublished HTML) is front-loaded.

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

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

With no output schema, the description usefully summarizes the return payload by reference to scan_page, and it covers the input contract. It does not cover failure modes or size limits, 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 100%, so both parameters are already documented, including that url drives relative links and the canonical check. The description's 'Pass the full HTML document' and 'url is optional' largely restate that, adding little beyond the schema baseline.

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

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

States a specific verb and resource ('Scan raw HTML that is not published yet') and immediately distinguishes the input class from its sibling scan_page by naming unpublished sources such as local builds, templates and editor drafts.

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

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

Gives a concrete usage context ('Use this in coding assistants to check SEO before deploying') and implicitly routes published pages to scan_page by referencing it as the equivalent tool. It never states an explicit exclusion or when-not-to-use, 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, open-world, so safety is covered. The description adds genuinely useful behavior: it discloses that client-side apps are rendered in a real browser (implying a heavier, more complete scan) and enumerates what the run produces (score, prioritized issues with why/how, AI readiness, key facts). Auth, rate limits, and failure modes are not mentioned.

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 action, followed by returns, a notable behavior note, and the routing hint. Sentences are purposeful, though the output enumeration is somewhat list-like and could be tightened.

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

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

There is no output schema, so the description must describe returns, and it does so concretely (score, issues, AI readiness, key facts). Combined with the browser-rendering note, an agent has enough to call it correctly, though performance/cost expectations for the browser render are left implicit.

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

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

With a single parameter at 100% schema coverage, the schema already fully documents the url. The description adds only the implicit 'public' constraint, which is marginal param-level value; baseline 3 applies when the schema carries the load.

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 one public web page') with a clear scope (SEO and AI visibility), and the 'one public web page' framing helps separate it from scan_html. It does not name sibling tools (scan_html, deep_audit, check_ai_visibility) directly, so differentiation rests on the scope phrase rather than explicit routing.

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

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

Gives an explicit entry-point heuristic: 'Use this first for any question about how a page performs in Google or AI search.' That is strong when-to-use guidance, but it offers no when-not-to-use or named alternatives for narrower checks (OG tags, schema, readability).

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 structurally. Beyond that, the description adds a genuine behavioral trait: the browser render is shared with render_page, so calling both costs one render, plus the option to supply a tree instead of a url. It does not discuss limits, rate constraints, or failure behavior when a page cannot be rendered.

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 dense sentences, front-loaded with the core action ('Show a page the way a screen reader announces it'), and the operand list plus the render_page/tree notes are all actionable. It is on the long side, but nearly every clause carries distinct 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, the return shape need not be restated, and the description nonetheless frames what the analysis surfaces (the accessibility problems it flags). The render-sharing relationship, the alternative tree input, and the scope of the inspection are all covered, leaving nothing an agent needs to invoke it correctly.

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

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

Schema coverage is 100%, so both url and tree are already documented, giving a baseline of 3. The description goes further by clarifying the intended use of tree: only when you have your own browser tool, and it should be that tool's accessibility snapshot. That conditional guidance is meaningfully more than the schema text alone.

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

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

The description gives a specific verb (show), a specific resource (a page as announced by a screen reader), and enumerates the exact artifacts returned: landmarks, heading outline, and reading order of named links/buttons/images/form fields. It also names what it detects (unnamed controls, vague link text, unlabeled fields, missing main, skipped headings, hidden text), which clearly separates it from siblings like analyze_layout or render_page.

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

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

It explains the relationship to render_page (shared render, so calling both costs one render) and gives an explicit alternative input path: pass your own browser's accessibility snapshot as tree. That is solid context for choosing between the two parameters, but it never states a when-not-to-use condition or a scenario where a sibling tool is the better choice.

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

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

Adds substantial context beyond annotations: the published page is public to anyone with the link, excluded from search indexing, and expires after 90 days, plus the fallback behavior when no prior scan exists. These are exactly the side effects an agent needs, and they are consistent with readOnlyHint=false and openWorldHint=true.

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

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

Three sentences, front-loaded with what the tool does, followed by the use case and then the caveats (public, unindexed, 90-day expiry). No filler; each sentence carries distinct information.

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

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

An output schema exists, so return values need not be described. The description covers the key non-schema facts: provenance of the 'before' state, visibility, indexability, and lifetime. An agent has everything needed to call this correctly.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents the url field including the bare-domain case. The description adds no further parameter-level meaning, so the baseline 3 applies.

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

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

States specific verbs (scan again, publish) and the concrete artifact produced (a shareable proof page on onpage.dev with before/after scores and fixed/open issues). This is clearly distinguishable from siblings like scan_page, rescan_and_compare, or get_fix_pack, which produce non-shared outputs.

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 triggering context: 'Useful after fixing a client's site: send them the link,' and explains the before/after sourcing rule (previous scan as 'before', otherwise current result). It does not name an alternative tool or state when not to use it, so it falls short of a 5.

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

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

Annotations cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent), and the description adds the async/progressive behavior that annotations cannot: it returns an audit_id plus first progress, and each subsequent call scans the next few pages. The 25-page cap and sitemap-fallback source selection are useful extra context.

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

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

Front-loads what it does, then the multi-call workflow, then the outputs. Dense but every sentence carries information; the final clause on suggest_internal_links is a minor add-on but ties the audit to a downstream 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?

An output schema exists so return structure needn't be explained, yet the description still summarizes the finished audit contents (issues by code, broken pages, duplicate titles/descriptions, orphan pages). The workflow loop is fully specified; only the absence of exclusion criteria versus sibling audit tools leaves a small 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 description coverage is 100%, so both parameters are already documented (url format, max_pages default 10 / max 25). The description adds source-resolution behavior tied to url (sitemap vs home page links) but no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Start an SEO audit of a whole site') with scope (up to 25 pages) and source resolution (sitemap or home page links). It clearly distinguishes itself from get_site_audit, which it names as the polling counterpart, and from the page-level siblings like scan_page.

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

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

Gives explicit workflow guidance: call this first, then call get_site_audit with the returned id until status is complete. It also notes the audit powers suggest_internal_links. It does not state when to prefer this over deep_audit or a single scan_page, so no 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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real context: the two-phase key provisioning behavior, the fact that a key and host file are returned on the first call, and the same-host constraint. No mention of rate limits or per-call outcomes, keeping it from a 5.

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

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

Front-loaded with purpose and benefit, then the workflow, then the constraint, then the Google alternative. Every sentence carries information an agent needs; nothing is filler.

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

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

No output schema exists, and the description compensates by explaining that the first keyless call returns a key and site file, and that subsequent calls need the key. Combined with the host constraint and the Google routing, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents both 'key' and 'urls' including the leave-out-to-get-a-new-one semantics and the same-host constraint. The description largely restates rather than extends that meaning, so the baseline of 3 is correct.

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 (submit changed URLs) and resource (IndexNow), names the downstream engines (Bing, Yandex, Naver, Seznam, Yep) and the benefit (recrawl within minutes vs days). It also distinguishes itself from the Google path by naming the sibling alternative (URL Inspection in Search Console).

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

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

Explicit when-to-use ('Call it after a fix is live'), including the two-step first-run workflow (call without key, ship the returned file, then call again with the key), the same-host constraint, and a clear exclusion routing Google users to a different tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: pages already linking to the target are excluded, orphan pages are flagged, and a completed audit is 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?

Three tight sentences, front-loaded with the core action, then the target variants, then exclusions and when-to-use. No filler and nothing redundant.

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

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

An output schema exists, so return values need not be explained. Given the annotations and full schema coverage, the description supplies everything an agent needs: the precondition (completed audit), the two target modes, and the exclusion/flagging behavior.

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

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

Schema description coverage is 100%, so the schema already documents topic, audit_id, and target_url in detail. The description's note about new pages and topics largely mirrors the schema text rather than adding syntax or format guidance, so baseline 3 applies.

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

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

States a specific verb and resource ('suggest which existing pages should link to a target page') plus the payload ('with anchor text') and the required precondition ('based on a completed site audit'). This is clearly distinguishable from siblings like check_urls or get_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?

Explicitly says when to use it: 'publishing new content or fixing pages that get no internal links.' It also clarifies the two target modes (audited page vs. new page). It does not name an alternative tool, but no sibling competes directly for this job.

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/non-destructive, and the description goes well beyond that by disclosing the evaluation algorithm (most specific user-agent group, longest matching rule, Allow wins ties, * and $ wildcards) and the nature of the result (allowed/blocked per crawler plus the deciding rule). The optional override of the live file is also made explicit.

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 dense sentences, front-loaded with the core action, then the matching rules, then the optional override. No redundant or filler text.

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

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

An output schema exists, so return values needn't be specified; annotations cover the safety profile; and the description covers the evaluation semantics and the live-vs-proposed mode. An agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so the schema already documents url, robots_txt and user_agents (including the default crawler set). The description restates the live-vs-proposed distinction but adds no syntax, format or constraint detail beyond what the schema provides.

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

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

States a specific verb and resource ('Test a URL against the site's live robots.txt') and quantifies scope ('one or more crawlers'), plus the exact matching semantics used. This is clearly distinguishable from siblings like ai_crawler_policy or check_ai_visibility, which concern policy/visibility rather than robots.txt rule evaluation.

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 use context: evaluate a URL against the live file, or against a proposed robots.txt instead of the live one. It does not, however, name an alternative tool or state when-not to use this one (e.g., versus the ai_crawler_policy sibling), so routing is left partly to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the concrete consequence the annotations only hint at: the watch's history is deleted, not just the watch itself. That is meaningful added context for a destructive call. It does not state whether the history deletion is permanent or what error occurs for an unknown watch_id, so it stops short of a 5.

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

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

A single front-loaded sentence with no filler; the destructive side effect is stated in the same clause rather than buried.

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

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

For a one-parameter tool with no output schema and annotations covering safety and idempotency, the description covers purpose, origin of the id, and the key side effect. Missing only edge-case behavior such as invalid or already-removed watch_ids.

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

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

Schema coverage is 0% for the single watch_id parameter, so the schema adds nothing. The description partially compensates by indicating the id refers to a watch created via watch_page, but gives no format, source, or example of the identifier.

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

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

States a specific verb (stop) and resource (a watch) and ties it explicitly to the sibling that creates watches (watch_page), so the agent can place it in the watch lifecycle. It does not explicitly distinguish from get_watch, though the 'stop' verb makes the read/write split inferable.

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

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

Usage is implied by 'a watch created with watch_page' — call this to tear down an existing watch. There is no explicit when-not-to-use guidance (e.g., that a watch_id must already exist or that the watch is already stopped), so the agent must infer the precondition.

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?

Although annotations already declare it read-only, open-world, idempotent and non-destructive, the description adds non-obvious behavior: it fetches linked pages to check they load and separately probes for llms-full.txt. That discloses real network side effects beyond the annotation set.

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

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

Front-loaded with the purpose and criteria, followed by action guidance and the alternative. Dense but every clause carries information; the inline list of format checks is long but directly useful for interpreting results.

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

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

An output schema exists so return values need no explanation, and annotations cover the safety profile. What remains — validation criteria, draft mode, and the sibling fallback — is fully covered, leaving nothing an agent needs to call it correctly.

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

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

Schema coverage is 100%, so the params are documented, but the description adds genuine meaning by explaining the draft-validation scenario for 'text' rather than merely restating that it replaces the live file. The url param's example is left to the schema.

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

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

States a specific verb (validate) and resource (llms.txt), and enumerates the exact rules checked (text serving, single H1, > summary, ## sections, size, link liveness). It names the sibling generate_llms_txt as the fallback, so an agent can distinguish it from its neighbors without opening schemas.

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

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

Gives explicit when-to-use guidance for the optional text parameter ('Pass text to validate a draft before uploading it') and a clear alternative path ('If the site has none, use generate_llms_txt'). Both the draft workflow and the missing-file case are routed unambiguously.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral content by enumerating exactly what gets checked and which input shapes are accepted, though it says nothing about error/report format or strictness levels.

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 dense sentences, front-loaded with the purpose and condition, then the accepted input forms. No filler and nothing that fails to earn 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?

An output schema exists, so return values need not be described. For a single-parameter, annotation-covered validator, the description supplies everything an agent needs to call it correctly: the trigger condition, the checks performed, and the accepted input shapes.

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% with a single 'jsonld' param, giving a baseline of 3. The description goes beyond the schema by specifying that the input may be a single object, an array, a @graph, or a full <script type="application/ld+json"> block, which clarifies what the text string may actually contain.

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

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

Specific verb ('Validate') plus resource ('JSON-LD') with explicit scope: syntax, @context/@type, absolute URLs, ISO dates, and Google's required/recommended fields. An agent can distinguish this from the sibling generate_schema without opening any schema.

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

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

The temporal condition 'before you publish it' clearly frames when to reach for this tool. However, it never names the alternative (generate_schema) or states when-not to use it, so routing between the two siblings 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?

Going well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description discloses the rescan cadence (~once a day), the private watch_id and RSS feed return values, optional webhook posting, that no account is needed, and a 90-day expiry. These are exactly the behavioral facts an agent cannot derive from structured fields.

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

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

Front-loaded with the primary purpose and then dense with lifecycle and return-value facts; every clause carries information. The monitoring list is long but purposeful, so it is only slightly verbose rather than wasteful.

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

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

An output schema exists, so return values need not be re-explained, and the description still covers what the agent needs: no auth required, what changes are tracked, watch lifetime, and which sibling tools manage the resulting watch. Nothing essential is missing 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 the schema already documents both url and webhook_url fully. The description reinforces webhook behavior but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Start watching a page') and enumerates exactly what is monitored (page down/redirect, new noindex, AI crawler blocking, canonical/title changes, score drops, errors). It is clearly a create-a-watch operation, distinct from siblings like get_watch and unwatch.

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 names the companion tools and their purpose ('Use get_watch to read the history and unwatch to stop'), giving the agent a clear lifecycle workflow. It does not state explicit when-not-to-use conditions or contrasts against adjacent monitoring siblings, so it falls short of a 5.

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