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

With readOnlyHint and openWorldHint annotations already covering safety, the description adds valuable behavioral context: it enumerates the exact bots checked, the handling of blanket disallow, and the sources for noindex/nofollow (header and meta tag). This goes beyond the annotations and does not contradict 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?

The description is two sentences that front-load the primary purpose and follow with critical details. Every phrase earns its place, and there is no unnecessary verbosity.

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

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

Given the tool's complexity (checking multiple bots, headers, meta tags) and no output schema, the description covers the full scope of checks. It lacks an explicit statement about the report format or error behavior, but the 'Report' framing plus the listed checks gives sufficient context for an agent.

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 schema already provides 100% description coverage for the single 'url' parameter, including that robots.txt/llms.txt are checked at the origin. The tool description confirms this behavior but adds no new parameter-level semantics, 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?

The description states a specific verb ('Report') and resource ('effective robots.txt allow/block status for GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot, and the * default') and additional checks (llms.txt, noindex/nofollow via X-Robots-Tag and meta robots). It clearly distinguishes from the sibling 'check_robots' by focusing on AI crawlers and indexability signals.

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

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

The description implies when to use this tool by noting 'critical failures invisible to a plain robots.txt check', which differentiates it from a generic robots check. However, it does not explicitly state 'use this instead of check_robots' or list exclusions, so it stops short of full usage guidance.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful context by listing exactly which headers are inspected (Cache-Control, content-encoding, ETag/Last-Modified) and the HTML document size. It does not detail network fetch behavior or failure modes, but that is partially covered by openWorldHint and the read-only nature.

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 one concise sentence, immediately starting with the action verb 'Inspect' and enumerating specific headers without any verbose or redundant phrasing. Every word contributes to understanding the tool's purpose and scope.

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

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

For a simple, one-parameter read-only tool with clear annotations and a detailed list of what is inspected, the description is fairly complete. It does not specify the return format, but with no output schema and the tool's straightforward nature, this 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?

The schema provides a 100% descriptive coverage for the single 'url' parameter with a clear example ('Page URL to check, e.g. https://example.com'). The description does not add extra parameter semantics beyond what the schema already includes, 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 clearly states a specific verb ('Inspect') and resource ('Cache-Control, content-encoding, ETag/Last-Modified headers and HTML document size'), which precisely defines the tool's function. It also distinguishes itself from sibling audit tools by focusing on caching and delivery headers rather than general SEO or rendering checks.

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

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

The description implies usage for evaluating caching headers and speed optimization opportunities, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives among the sibling tools. The context is present but not clarified with 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 provide readOnlyHint=true, covering safety. The description adds useful behavioral details by defining what constitutes the check (valid certificate and 301 redirect), which goes beyond the generic tool name. It does not mention response format or edge cases, but given the annotation coverage, this is adequate.

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, well-structured sentence that delivers all necessary information without any fluff. It is concise and front-loaded with the core behavior.

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

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

For a simple tool with one parameter and no output schema, the description adequately explains the check. The return value is not explicitly stated, but in the context of sibling check tools, 'verify' implies a pass/fail result, making it reasonably complete.

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

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

The input schema fully describes the url parameter with an example and constraints, so schema coverage is 100%. The description does not add extra semantics beyond what the schema already provides, matching the baseline of 3.

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?

Description clearly states the tool's function with a specific verb ('verify') and two concrete checks: serving https:// with a valid certificate and http:// 301 redirecting to https://. This strongly differentiates it from sibling tools like check_url_structure or check_caching.

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

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

The context for use is clear: when you need to confirm HTTPS enforcement and proper redirect behavior. It does not explicitly mention exclusions or alternatives, but the specialized scope is evident from the description and sibling names, so it meets the 'clear context, no exclusions' bar.

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

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

Annotations declare readOnlyHint=true, and the description adds valuable behavioral context: matching is plural/stem-tolerant, flags both thin usage and stuffing, returns emoji statuses, and accepts both array and string input. This goes beyond the schema and annotations, though it doesn't cover side effects (which are minimal for a read-only tool).

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 paragraph with clear, information-dense content. Every sentence adds value: placement locations, matching behavior, input flexibility, and output format. Slightly dense but efficient, no wasted words.

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

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

The tool has 3 parameters, no output schema, but the description compensates by listing what elements are checked, how input is handled, and the return format. It's complete enough for an agent to select and invoke correctly, though it doesn't describe the exact output structure (e.g., JSON shape) which would be helpful if no output schema exists.

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

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

Schema description coverage is 100% (all params have descriptions), so baseline is 3. The description adds meaning by explaining how keywords are used (one report section per keyword), accepts a single string alternative, and describes the matching tolerance—adding value beyond the schema's basic descriptions.

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

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

The description clearly states the tool analyzes where target keywords appear on a page and lists specific elements (title, URL, meta description, H1, H2, first 100 words, image alt text, keyword density). It distinguishes from siblings like seo_full_audit by focusing specifically on keyword placement, not a general SEO 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?

The description indicates when to use this tool: to analyze keyword placement on a single page. It provides details on input formats (array or single string) and matching behavior (plural/stem-tolerant). However, it doesn't explicitly contrast with sibling tools or state when not to use it, though the specialized scope implies usage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only network operation. The description adds context by listing the checks performed, but it does not disclose additional behavioral details like the return format or potential failure modes. Since annotations cover the safety profile, the description's extra behavioral context is modest, warranting a 3 rather than higher.

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 sentence that packs in many specific items, but it's not overly long and each item is relevant. It could be structured as bullet points for easier scanning, but the list format is efficient and avoids unnecessary verbiage.

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 simple input (one URL) and strong annotations, the description fully enumerates the scope of what is checked, giving an agent a complete picture. It does not explain the output format, but since there is no output schema, this is a minor gap. The description is sufficiently complete for the tool's simplicity.

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

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

The input schema has 100% coverage for the single 'url' parameter, including a description and example. The tool description does not add further meaning about parameter usage beyond what the schema already provides, so it aligns with the baseline score for high 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?

The description clearly states what the tool does with a specific verb 'Check' and enumerates the exact on-page elements it verifies (title, meta description, H1, canonical, Open Graph, viewport, lazy-loading, image formats, CLS). This list explicitly distinguishes it from sibling tools like check_url_structure or check_rendering, which target different SEO aspects.

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

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

The description provides clear context for when to use the tool: to verify a set of specific on-page HTML essentials. However, it does not explicitly mention alternatives (e.g., seo_full_audit for a broader audit) or specify when not to use it, so it lacks explicit exclusions but gives enough context for an agent to infer appropriate use.

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

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

Beyond the readOnlyHint annotation, the description discloses a key behavioral trait: it fetches without executing JavaScript. This is non-obvious and adds context about how the check works and what it detects. It also explains the practical implication for search engines/AI, which is valuable behavioral 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?

The description is a single sentence that is concise and front-loaded with the main action ('Fetch a page without executing JavaScript'). Every phrase adds value, with no redundant or filler content.

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

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

For a simple tool with one parameter and no output schema, the description covers the essential purpose and behavior. It could optionally describe the return format, but that is not necessary for understanding what the tool does. The context about Google/AI interpretability adds completeness.

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

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

The input schema already has 100% coverage with a clear description for the single 'url' parameter. The tool description does not add additional parameter-specific semantics, so the baseline score of 3 is appropriate given the schema's completeness.

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

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

The description uses a specific verb ('fetch', 'detect') and resource ('server-rendered HTML vs client-side JS shell'), clearly distinguishing it from sibling audit tools that check different aspects like URL structure or HTTPS. It unambiguously states what the tool does.

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

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

The description implies the tool is for checking rendering behavior and why it matters ('hard for Google/AI to interpret'), giving clear context for when to use it. However, it does not explicitly mention alternatives or exclusion criteria, though none of the sibling tools directly overlap with this specific rendering check.

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

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

Annotations only declare readOnlyHint and openWorldHint. The description adds concrete behavioral details: fetching /robots.txt, checking for HTML/redirects, sitemap reference, and site-wide block. This goes beyond the annotations and gives the agent a clear picture of the operation.

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, well-structured sentence that front-loads the action ('Fetch') and lists all checks without redundancy. Every phrase adds 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 single-parameter tool with no output schema and read-only annotations, the description is quite complete. It covers what is fetched and the validation logic, though it doesn't describe the return format, which is a minor gap.

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

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

The input schema already provides 100% coverage with the description 'Any URL on the site — the origin's /robots.txt is checked'. The tool description adds no further parameter detail, so baseline score of 3 is appropriate.

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

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

The description states a specific verb 'Fetch' and resource '/robots.txt', with explicit verification criteria (existence, not HTML/redirect, sitemap reference, no site-wide block). This clearly distinguishes it from sibling tools like check_sitemap and check_ai_crawlers.

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 implies the tool is for validating robots.txt, but it does not explicitly state when to use it versus alternatives like check_sitemap. However, the purpose is unambiguous enough that an agent would know when to invoke it.

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

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

The description adds meaningful behavior beyond the readOnlyHint and openWorldHint annotations: it samples up to 10 <loc> URLs and verifies they return 200 without redirects, and it checks lastmod freshness. These are concrete actions that inform the agent about network calls and validations. However, it does not disclose details like potential timeouts or rate limits, so it stops short of a perfect score.

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 sentence that packs all key actions efficiently. It is front-loaded with the fetch action and preserves clarity by using a list-like structure. No wasted words.

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

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

Despite lacking an output schema, the description outlines all the checks performed: fetching the sitemap, counting entries, flagging specific URLs, sampling for HTTP status, and checking lastmod. This gives the agent a solid understanding of the tool's behavior. The only missing piece is a description of the output format, which would be helpful but is not critical given the detailed action list.

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 schema description for the 'url' parameter already fully explains its semantics: 'Any URL on the site — the origin's /sitemap.xml is checked'. With 100% schema coverage, the description adds no extra parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly identifies the tool's primary action ('Fetch /sitemap.xml') and enumerates specific checks (count entries, flag admin/cart/checkout/internal-search URLs, sample 10 URLs for HTTP 200 without redirects, check lastmod presence/freshness). This is a specific verb+resource combination that distinguishes it from sibling tools like crawl_audit or check_url_structure.

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

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

The description provides a clear context for when to use the tool: to audit a site's sitemap.xml. It does not explicitly state when not to use it or name alternative tools, but the scope is unambiguous given the sibling list. This aligns with 'clear context, no exclusions' rather than explicit alternatives.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds valuable behavioral detail: tolerates arrays and @graph, flags malformed JSON-LD, checks specific schema properties, and provides a ready-to-paste Organization example when none exists. No contradiction with annotations.

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

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

The description is concise at three sentences, front-loaded with the primary action, and every additional detail (tolerated structures, specific checks, fallback behavior) earns its place. No redundant or filler content.

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

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

The description covers the tool's core behavior, including what it validates and how it handles malformed or missing JSON-LD. Given the simple parameter schema and lack of output schema, it is sufficiently complete, though a brief note on return format would make it fully comprehensive.

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

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

The input schema has full coverage (100%) for the single 'url' parameter, and the description does not add additional parameter-level semantics. The baseline of 3 applies because the schema already documents the parameter adequately.

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

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

The description uses a specific verb ('Extract and validate') and resource ('schema.org JSON-LD on a page'), and enumerates specific entity types checked (Organization, SoftwareApplication, FAQPage, BreadcrumbList). This clearly distinguishes it from sibling SEO tools like check_https or run_lighthouse.

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

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

The description provides clear context for when to use the tool: when a page's structured data needs to be validated or extracted. It does not explicitly mention alternatives or exclusions, but the detailed scope of checks makes the use case evident in the context of sibling tools.

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

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

Annotations already indicate readOnlyHint=true, and the description adds the valuable behavioral detail that no requests are made (offline). It also enumerates the specific heuristics used, giving more transparency about what the analysis checks.

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

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

The description is two sentences: the first states the action and criteria, the second notes the offline behavior. It is tightly written with no redundant words or filler.

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

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

Given the low complexity (one parameter, no output schema) and the presence of the offline disclaimer, the description is sufficient. It could possibly mention what kind of result is returned, but this is not essential for a simple analysis tool.

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

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

The schema covers the single parameter 'urls' completely (100% coverage), so the description doesn't need to add much. It mentions 'one or more URLs' which aligns with the schema, but adds no new semantic detail beyond what is already provided.

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

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

The description clearly states the tool analyzes URLs against clean-URL best practices, listing specific criteria (length, lowercase, hyphens, etc.). It distinguishes itself from sibling tools by focusing solely on URL structure rather than rendering, crawling, or other SEO aspects.

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

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

The description makes it clear when to use this tool (for checking URL structure) and highlights that it is offline, implying it can be used without making requests to the site. However, it does not explicitly name alternatives or describe when not to use it, so it falls slightly 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?

The description adds significant behavioral context beyond the readOnlyHint and openWorldHint annotations: it discloses a polite delay, that each page is fetched once and shared across checks, the '>50% of pages' heuristic for site-wide issues, and fallback to internal links. It does not mention baseline updates for compare_to_baseline (a side effect), but that is covered in the schema, and the description does not contradict annotations.

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

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

The description is a single, dense paragraph that front-loads the action ('Crawl a site...') and uses a colon-separated list for the aggregates. It is efficient and every clause contributes value, though the length makes it slightly less scannable than a shorter alternative.

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 five parameters and a complex crawl-and-audit workflow, the description covers the core behaviors: crawl seeding, delay, page-sharing, and the specific aggregate checks. It does not enumerate the return structure in detail, but the output schema explains format options, and the description provides enough for an agent to understand the tool's scope.

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 fully documents all five parameters. The description adds conceptual meaning by explaining the crawl context ('sitemap-index aware', 'falls back to following internal links') and the role of max_pages ('audit up to max_pages pages with a polite delay'), which goes beyond the schema's field-level descriptions.

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

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

The description clearly states the tool's function: 'Crawl a site... and audit up to max_pages pages' and lists specific aggregated checks such as broken internal links, redirect chains, duplicate titles, and orphan sitemap URLs. This concrete enumeration distinguishes it from sibling tools like check_sitemap or seo_full_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?

The description implies when to use this tool by describing the crawl strategy (seeded from sitemap.xml, falls back to internal links) and the aggregation of site-wide issues across pages. However, it does not explicitly state when this tool should be preferred over alternatives like seo_full_audit or check_url_structure, nor does it mention 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?

Even with readOnlyHint and openWorldHint annotations, the description adds rich behavioral detail: runs via npx, reports specific metrics with thresholds, explains the INP/TBT fallback, mentions top speed opportunities, and discloses timing and Chrome requirement. This goes well beyond the annotations.

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

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

The description is compact yet information-dense: it packs purpose, metric details, fallback behavior, timing, and a prerequisite into four efficient sentences without redundancy. Every sentence contributes 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?

It explains what the tool reports (scores, Core Web Vitals, speed opportunities) and caveats like slowness and Chrome requirement. However, since there is no output schema, it could be more explicit about the return format (e.g., JSON object, text report) or whether artifacts are saved. Still, the essential usage is well covered.

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 schema already covers both parameters with full descriptions (url and form_factor), so baseline is 3. The description does not add parameter-specific details beyond the schema; it focuses on output and behavior rather than parameter nuances.

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

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

The description clearly states it runs Google Lighthouse for performance and SEO categories, naming specific Core Web Vitals metrics. However, it does not explicitly differentiate from sibling tools like seo_full_audit that also cover SEO, so it lacks explicit sibling distinction.

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

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

The description provides useful context by noting it is 'Slow (~1-2 min)' and 'requires Chrome installed', which implies when it is appropriate to use. It does not explicitly name alternatives or when-not-to-use, but the context gives clear practical guidance.

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

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

Annotations already provide readOnlyHint and openWorldHint, but the description adds substantial behavioral detail: output formats (Markdown with ✅/⚠️/❌, JSON with severity and pas/warn/fail counts, HTML written to disk), baseline diff behavior via compare_to_baseline, and the explicit exclusion of Lighthouse. It also discloses that HTML output writes a file, which is a side effect beyond the read-only audit itself. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place. The first clause front-loads the purpose, the long checklist sentence is organized by category, and the remaining sentences cover output modes, baseline comparison, and exclusion. No filler or redundancy.

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

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

Given the tool's complexity and the absence of an output schema, the description is thorough: it explains all output formats, baseline diffing, file-writing behavior, and the Lighthouse exclusion. It could add notes about URL accessibility/errors or explicitly state which sibling checks are included (e.g., whether keyword placement/URL structure are covered), but it is complete enough for an agent to select and invoke 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?

The input schema covers 100% of parameters with detailed descriptions, including the output enum, defaults, and output_path specifics. The description summarizes some of this (e.g., 'structured JSON with output: json', 'shareable HTML file with output: html') but does not add meaning beyond what the schema already 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?

The description uses a specific verb ('Run') and resource ('full technical SEO checklist on a URL'), enumerating concrete checks (rendering, HTTPS, page essentials, cache, structured data, etc.). It clearly distinguishes itself from the sibling individual checker tools by being the comprehensive 'full' audit, and it explicitly names run_lighthouse as a separate tool for Lighthouse.

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 tells the agent when to use this tool: when a full technical SEO audit is requested. It also provides an explicit exclusion and alternative: 'Does not include Lighthouse (use run_lighthouse separately — it is slower).' The sibling list of targeted check_* tools implies that for single-aspect checks, the individual tools are more appropriate, giving clear usage context.

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