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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds substantial behavioral context: it resolves 'every known AI/LLM crawler,' distinguishes citation vs. training bots, reports advisory vs. enforceable blocks, discloses vendor quirks (e.g., Applebot following Googlebot rules), and notes provenance of crawler tokens. This far exceeds the safety profile already conveyed by 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 long but front-loads the core purpose in the first sentence, then organizes coverage, differentiators, parameters, returns, and example in a logical, scannable structure. Every sentence adds information, though the bulleted 'Three things' and extensive crawler list make it somewhat verbose; still, it earns its length through specificity.

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, the description is exceptionally complete. It explains nuanced behavior, provides a structured return object, lists all four parameters with defaults, includes a usage example, and even anticipates edge cases like undocumented vendors. The presence of an output schema (the 'Returns' block) further covers return semantics. No notable gap remains for an agent to understand what the tool does and when to invoke it.

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

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

With 100% schema description coverage, parameters are fully documented in the schema. The description's 'Args' section largely duplicates the schema (site, path, include_deprecated, response_format) and adds only minimal color (e.g., 'retired tokens' for include_deprecated). No extra meaning, constraints, or usage nuances are contributed beyond the schema, 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 opens with a specific, active statement: 'Resolve every known AI/LLM crawler against a site's robots.txt and report which may fetch a given path.' This clearly identifies the tool's function and distinguishes it from generic robots.txt checkers, further reinforced by the detailed list of covered crawlers and unique analytical angles (training vs. citation, enforceability, vendor quirks).

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 concrete usage example ('Can ChatGPT and Perplexity crawl example.com?') and implies value over naive robots.txt readers with its 'Three things this gets right' section. However, it does not explicitly name sibling alternatives or state when NOT to use this tool, so it stops short of full 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?

The description goes well beyond the read-only/idempotent annotations by detailing the additional behavioral reports: HTTPS upgrade detection, permanent vs. temporary redirect classification, and identification of non-serving variants. It also clearly documents the returned structure (hop_count, redirect_statuses, findings), adding substantial transparency without contradicting 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 well-structured and front-loaded: the core purpose appears in the first sentence, followed by concise bullet-style sections for additional reports, parameters, return payload, and an example. Every sentence contributes meaningful information with 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 moderate complexity, the description is remarkably complete: it explains what the tool does, what parameters are needed, what behavioral nuances are checked, the exact return structure, and provides a clear example. The provided annotations and schema also contribute, making this a fully self-contained tool description.

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 covers both parameters at 100% with descriptions. The description reinforces the site parameter by explicitly stating that 'www and scheme are ignored' (a practical clarification) and restates the response_format options and default. This adds modest but useful semantic depth 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?

The description clearly identifies the tool's operation: fetching the four host/scheme variants (http/https × apex/www) and checking convergence on a single canonical URL. It uses a specific verb and resource combination that distinguishes it from siblings like redirect_trace and render_check.

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

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

Provides clear context for when to use the tool (when homepage variants may be competing in the index, when checking canonical convergence) and includes a concrete example query. It does not explicitly name alternative tools or state when not to use it, but the use case is well 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 mark the tool as read-only, open-world, and idempotent. The description adds meaningful behavioral context by stating that content is read from <main>/<article> landmarks to avoid inflated counts, and that both English and Spanish stopwords are filtered. It does not address edge cases like missing landmarks, but goes beyond the annotation baseline.

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 efficiently organized: a definitional first paragraph, a behavioral note, then clean 'Args' and 'Returns' sections, and a concrete example. Every sentence contributes, with no fluff or repetition.

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

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

For a 2-parameter tool with an output schema, the description fully covers purpose, key behavior, return structure, and a usage example. The output schema and annotations cover safety and return types, while the description fills in what is not explicitly structured, making the tool self-contained.

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

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

Schema coverage is 100%, and the description's parameter section mostly mirrors the schema ('response_format' defaults and enums). The natural-language example adds illustrative value but does not clarify any new parameter semantics beyond what the schema already 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 opens with 'Measure the page's main content' and itemizes precise metrics (word count, Flesch reading ease, text-to-HTML ratio, thin-content detection). This specific verb+resource clearly distinguishes it from sibling tools like seo_audit or meta_tags_check, which focus on different 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 example 'Is the content on https://example.com/post too thin?' provides a concrete use case, and the landmark-reading note explains a relevant context (ignoring chrome). However, it does not explicitly contrast with alternatives such as heading_structure or link_audit, so when-not-to-use guidance is missing.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description reveals key behavioral details: it weights specific criteria, it detects pages invisible to AI assistants due to JS hydration, and it distinguishes AI search crawlers from training crawlers in robots.txt. It also transparently explains why llms.txt is reported but not scored. This adds substantial context beyond the structured 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 well-structured and information-dense without being verbose. It leads with the core purpose, then presents the weighted criteria, unique capabilities, args, returns, and a clarifying note about llms.txt. Every sentence adds value, and the format is easy to scan. No unnecessary fluff 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?

The description is comprehensive for a tool with this complexity. It explains the scoring dimensions, the return structure (geo, rendering, crawler_access, etc.), and the rationale behind not scoring llms.txt. The presence of an output schema is complemented by a clear summary of the returned fields. It also provides an example that ties the tool to a realistic query. All essential context is 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 input schema provides 100% coverage of parameters, including descriptions for url and response_format (with enum values and default). The description repeats the parameter list but adds minimal new semantics beyond the schema. It shows an example call but does not clarify details like URL scheme defaulting, which the schema already covers. Since the schema carries the parameter documentation, a 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 clearly states the tool's purpose: scoring how readily an AI answer engine can fetch, parse, and cite a page. It specifies the resource (a URL) and the action (scoring readiness), and it distinguishes itself from classic SEO tools by highlighting two unique capabilities. This makes it easy to understand what the tool does and how it differs from siblings.

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

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

The description provides a clear use case via an example ('Is https://example.com/guide ready to be cited by ChatGPT?') and explains what it catches that classic SEO tools do not. However, it does not explicitly name alternative sibling tools or state when NOT to use this tool in favor of a more specific one like ai_crawler_access. The guidance is implied rather than explicitly contrasted with 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?

Annotations already declare read-only and idempotent behavior, so the bar is lower. The description adds meaning by detailing evaluation criteria (empty headings, skipped levels, question phrasing), the returned score/grade/findings, and the output format options, going beyond the safety hints.

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

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

The description is well-organized with clear sections (explanation, Args, Returns, Example) and is appropriately sized for an agent-facing tool. It loses a point because the Returns block largely duplicates the output schema, adding minor redundancy, and the example could suffice without the full return payload 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?

Given the tool's moderate complexity, the presence of an output schema, and rich annotations (read-only, idempotent, open-world), the description is complete. It explains what the tool does, what inputs it expects, what it returns, and offers a concrete invocation example, leaving no critical gap for agent selection or 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%, so baseline is 3. The description's Args section mostly restates the schema's parameter names, types, defaults, and formats without adding new meaning. The example invocation does demonstrate argument binding, but does not elevate the semantic value 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?

The description opens with 'Extract the full h1–h6 outline and evaluate it' and enumerates specific checks (h1 count, level skips, empty tags, question headings), clearly distinguishing it from generic content or meta audit tools. The verb+resource combination is specific and actionable.

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 does not name sibling alternatives or state when-not to use, but it provides clear context by noting the question-heading signal is useful for featured snippets and AI citations. This implies an SEO/visibility use case without explicit exclusions, which fits the 'clear context, no exclusions' level.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds valuable behavioral context by disclosing that with check_reciprocity=true it fetches each alternate URL, and explains the practical motivation (non-reciprocal hreflang is silently ignored by Google). It also outlines the return structure, making the tool's behavior fully transparent.

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 well-structured and efficient. It leads with the core purpose, follows with an optional advanced behavior, and then lists Args, Returns, and an Example in a scannable format. Every sentence adds information, and nothing is redundant or 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 the tool's moderate complexity, the description covers all essential aspects: what is validated, the optional reciprocity fetch, all three parameters, the expected return shape, and a usage example. The output schema is present, so the Returns summary suffices. Annotations cover safety and semantics, making this description contextually complete.

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

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

Schema description coverage is 100%, so parameters are already well-documented in structured form. The description adds extra value by explaining check_reciprocity's purpose and consequence ('verify alternates link back'), clarifying the default for response_format, and providing an example that shows how to invoke the tool with meaningful arguments. This goes slightly beyond the schema but not dramatically, hence a 4.

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 opens with a specific, actionable verb 'Validate' and precisely names the resource: a page's `<link rel='alternate' hreflang>` annotations. It enumerates concrete checks (BCP-47 validity, self-referencing entry, x-default fallback, duplicates) that clearly distinguish it from sibling SEO tools like meta_tags_check or structured_data_check.

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

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

The description gives clear context for when to use the tool (validating hreflang setup) and includes a concrete example query that illustrates the typical use case. However, it does not explicitly state when *not* to use it or name alternative sibling tools for other SEO checks, so it falls short of the highest bar for explicit 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 read-only, idempotent, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds useful context beyond the annotations: it audits every <img> on the page, counts <picture> sources as modern delivery, and specifies the return payload. It does not contradict 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 front-loaded with the core audit purpose and checklist, followed by clearly labeled Args, Returns, and an Example. It is structured and dense, but the Args and Returns sections are somewhat redundant with the input and output schemas, so it is not maximally concise.

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 moderately complex tool with two documented parameters, a full output schema, and strong annotations, this description is operationally complete. It explains exactly what is checked, the nuance of <picture> sources, the output structure, and provides an invocation example, leaving no critical gap for selection or correct use.

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 thorough descriptions for both url and response_format, including defaults and the https:// default for url, giving 100% coverage. The description's Args section merely restates these in abbreviated form, and the example only maps a natural-language request to a call without adding new parameter semantics.

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

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

The description opens with the specific verb 'Audit' and names the exact resource ('every <img> on the page'), then enumerates the precise SEO checks performed (alt text, dimensions, lazy-loading, modern formats). This clearly distinguishes it from broader sibling tools like seo_audit or render_check.

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

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

The description makes the intended use obvious: it is the tool for a page-level image SEO audit, listing the exact aspects it checks and even giving an example natural-language query mapped to a tool call. It does not explicitly mention when not to use it or point to alternatives, but the context is clear and self-contained.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses a specific behavioral trait: 'retrying with GET when a server rejects HEAD' for broken-link verification, and notes that verification is a sample. This adds meaningful context about the tool's operational behavior without contradicting 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 well-organized: a concise opening sentence, a bullet-like list of arguments, a return structure overview, and a concrete example. Every section earns its place, and the text is scannable without being 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?

The description covers the tool's purpose, parameters, return structure, and a usage example, all within a moderate length. Combined with the detailed input schema and output schema, it provides sufficient context for an agent to select and invoke the tool correctly, even for complex queries.

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 describes all four parameters with types, defaults, and descriptions, achieving 100% coverage. The description's Args section largely duplicates this, only adding an example mapping. Thus the description adds minimal value beyond the schema, meriting the baseline score.

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 with a specific verb and resource ('Audit a page's outbound links') and enumerates the exact link characteristics analyzed (internal/external split, rel attributes, anchor text issues, external domain distribution). This distinguishes it from the broader sibling tools like seo_audit and content_analysis.

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, including a concrete example for broken-link checking. However, it does not explicitly mention alternatives or when not to use it, so it falls short of full explicit 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 indicate readOnly, idempotent, openWorld, and non-destructive behavior. The description adds significant behavioral context, including that the tool 'always reports' adoption status and important caveats about llms.txt not being a standard, plus detection of llms-full.txt. 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 well-organized and front-loaded with a clear purpose statement. The 'Important context' paragraph, Args, Returns, and Example sections are clearly structured. It is longer than a minimal description, but every section adds value and the formatting aids scannability.

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 purpose, validation criteria, important caveats, parameters, return fields, and an example invocation. This is thorough especially with annotations present. It lacks only minor details like error-handling behavior, but overall it is complete enough for an AI agent to use 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 both parameters are already fully documented. The description's Args section merely restates the schema information without adding new semantic details. Thus, 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 clearly states the tool's function: 'Check whether a site publishes /llms.txt and validate it against the llmstxt.org proposal' and also mentions detection of /llms-full.txt. It includes specific details on what is validated (H1, blockquote, H2 lists) and directly answers the tool's purpose: 'Use this tool to answer "do they publish one, and is it well-formed?"' This distinguishes it from sibling tools.

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

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

The description provides explicit when-to-use guidance: 'Use this tool to answer "do they publish one, and is it well-formed?"' and an explicit when-not: 'not as evidence that a site is or is not AI-optimised.' It does not name alternative tools, but the context makes the intended usage clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral detail by specifying what it inspects (e.g., X-Robots-Tag header) and what it flags (length problems, duplicates, non-indexability). 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 well-structured with distinct sections: intro, Args, Returns, and Example. It is sufficiently detailed without redundancy; each section adds value, including the return fields and a concrete usage example.

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 (2 params, output schema with many fields), the description covers purpose, inputs, outputs, and example usage. It is complete for correct invocation, though alternative guidance is missing (covered under usage_guidelines).

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 parameters are fully described in the schema. The description's Args section adds little beyond the schema, but the example clarifies usage. Baseline 3 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 it inspects a page's head tags and lists specific tags (title, meta description, canonical, robots directives, etc.) and flags issues. It is specific about the resource and actions, but it does not explicitly differentiate from sibling tools like seo_audit or render_check.

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 an example usage but does not state when to use this tool versus alternatives. It implies usage for checking meta tags, but lacks explicit when/when-not guidance or alternative tool recommendations.

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 idempotentHint=true, so the description adds value by detailing the analysis behavior: it flags loops, temporary redirects, non-HTTPS endpoints, and reports hop-by-hop status codes. The Returns section also discloses the exact payload shape, which is beyond annotation coverage. No contradictions 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 structured with an opening behavioral sentence, an Args block, a Returns block, and an example. The Args and Returns blocks largely duplicate what is already in the input and output schemas, making the description longer than necessary. However, the example is helpful, and the structure is clear. Overall, it would benefit from trimming 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 has only two parameters and an output schema exists, the description provides sufficient context: it explains the purpose, the analysis flags, and gives an example. It doesn't cover errors or alternative tool selection, but that is not crucial for this low-complexity tool. The description is largely complete for an agent 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?

The input schema already provides thorough descriptions for both parameters, giving 100% coverage. The description's Args section merely restates the names and types without adding new meaning. Since schema coverage is high, the description does not need to compensate, and it doesn't add meaningful parameter semantics 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?

The description uses a specific verb ('Follow') and resource ('a URL's redirect chain'), clearly stating it reports each status code and target. It also lists specific issues it flags (long chains, loops, temporary redirects), which distinguishes it from sibling tools like seo_audit or link_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 provides clear context for use: it helps identify redirect-related issues such as long chains wasting crawl budget and improper temporary redirects. The example query 'Where does http://example.com/old-page end up?' illustrates a direct use case. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full 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?

With annotations already covering read-only/idempotent behavior, the description adds meaningful behavioral details: it detects unhydrated SPA shells, reports word counts, flags script-heavy documents, and returns a specific structured object. It does not disclose potential limitations (e.g., whether JavaScript is executed) but overall exceeded 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 well-structured and front-loaded with the core purpose. Each subsequent sentence adds contextual value: AI visibility rationale, detection details, parameters, return format, and a concrete example. Nothing is redundant or irrelevant.

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

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

The description is highly complete given the tool's complexity. It explains why the tool matters, what it detects, what arguments it takes, what it returns, and shows a realistic example. With annotations and output schema available, no major gaps remain.

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 both parameters already described. The description's 'Args' section essentially repeats the schema without adding new semantics, though the example call helps contextualize usage. Baseline 3 is appropriate given the 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 a specific purpose: determining whether content exists in server HTML or requires JavaScript. It lists concrete detection capabilities (SPA shells, word count, script bytes) and explicitly distinguishes itself from classic SEO, emphasizing AI visibility. This differentiates it from sibling tools like seo_audit and ai_crawler_access.

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

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

The description gives strong contextual guidance on when to use it: when evaluating AI assistant visibility, especially for client-rendered pages. It contrasts with classic SEO and provides an explicit example question, but does not name alternative sibling tools for comparison. The 'when-not' is implied rather than explicitly stated.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds substantial behavioral context: RFC 9309 compliance, handling of unparseable lines, and Google's interpretation of 5xx as 'disallow everything.' It also clarifies that only the origin of a URL is used. No contradictions 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 tightly structured with clear sections: overview, args, returns, example, and alternative tool. Every sentence provides value, including the RFC reference, the deindexing flags, and the return structure. 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?

For a read-only analysis tool, this description covers behavior, parameters, return fields, an example, and a pointer to an overlapping sibling. It also includes important SEO context (deindexing risks) and complies with RFC 9309. The Returns line enumerates top-level fields, so agents understand the output shape without a formal 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% — both `site` and `response_format` are fully described in the input schema, including examples and defaults. The description restates these parameters and adds an example, but does not materially expand beyond the schema's own documentation, 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 opens with a specific verb+resource: 'Fetch and parse a site's robots.txt per RFC 9309.' It enumerates exact outputs (user-agent groups, Allow/Disallow rules, sitemaps, unparseable lines) and flags two critical failure modes. It also distinguishes itself from sibling `ai_crawler_access` by explicitly directing AI-crawler queries to that alternative.

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

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

Provides a concrete example ('What does example.com's robots.txt allow?') and an explicit alternative tool for AI-crawler specifics, establishing clear when-to-use and when-not-to-use boundaries. The mention of deindexing flags also signals relevant SEO audit scenarios, giving strong contextual guidance.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds meaningful behavior: it fetches the page once, caps the score on noindex/robots blocks, returns specific errors for unreachable/non-HTML/HTTP-error URLs, and mentions that include_geo adds requests and check_broken_links is slower. These details give the agent a realistic model of side effects and failure modes.

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 well-organized and front-loaded: a one-sentence functional summary, followed by usage guidance, args, returns, an example, a critical note, and error conditions. Each section earns its place and no redundant fluff exists; it is appropriately sized for a complex audit 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?

Given the tool's complexity (seven audit sections, four parameters, output schema), the description is remarkably complete: it covers inputs, outputs, edge-case behavior (noindex/robots), error conditions, and example invocation. The existence of an output schema reduces the need to detail return values, and the description still provides a compact return structure overview.

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 input schema already documents all four parameters with defaults and descriptions. The description's Args section mostly restates this information with slightly shorter wording. It adds only a small increment via the usage example and confirms the default output format, but does not materially deepen parameter understanding 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?

The description clearly states the tool's function with a specific verb ('audit') and resource ('a page'), enumerating the seven weighted sections (meta tags, heading structure, content quality, etc.). It also distinguishes itself from the sibling single-purpose tools by positioning this as the comprehensive starting point for SEO questions.

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

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

It explicitly says 'This is the tool to start with for any "how is this page doing for SEO?" question' and directs users to 'drill into the single-purpose tools afterwards for detail,' naming the alternative pattern. This gives clear when-to-use guidance and references the sibling tools without needing to enumerate them.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral context: discovery via robots.txt and fallback paths, handling of gzipped/indexed sitemaps, and specific validation checks including URL count and lastmod validity. 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 about 150 words but efficiently uses three structured segments: discovery, validation, and invocation with example. Every sentence contributes details about the tool's behavior or expected use, avoiding redundancy with schema or annotations.

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

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

For a tool of this complexity with rich schema annotations and an output schema, the description covers discovery logic, validation rules, parameters, return payload, and an example. It leaves no gaps about edge cases like sitemap indexes or gzipped sitemaps.

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 baseline is 3. The description repeats the schema parameter descriptions and adds an example mapping 'example.com' to the site parameter, but does not introduce new semantic information 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?

The description uses specific verbs 'Discover, fetch and validate' with the resource 'XML sitemap', and distinguishes it clearly from sibling tools like robots_txt_check by focusing on sitemaps. It also enumerates specific validation checks, making the purpose unmistakable.

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 does not explicitly name alternative tools or when not to use it, but the example 'Check the sitemap for example.com' demonstrates a clear invocation. The description implies usage by stating what it does and how discovery works, but lacks explicit comparisons to siblings like link_audit or robots_txt_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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: the optional HEAD request to verify og:image, the detection of relative og:image URLs, and the return fields. This goes 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?

The description is well-structured and front-loaded with the purpose. It uses concise bullet-like sections for args and returns, includes an example, and every sentence contributes to understanding the tool. 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 moderate complexity, the description covers the core functionality (tag validation, image check, relative URL flag), the input parameters, and the return object. The presence of an output schema and annotations reduces the burden, and the example clarifies the use case. It is complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% (all 3 parameters have descriptions, defaults, and enums). The description merely repeats the parameter names and defaults in a more compact form, adding no new semantic meaning beyond what the schema already provides. The example usage is a minor addition but not enough to raise the score above the baseline.

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

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

The description uses a specific verb ('Validate') and identifies the resource (social preview tags for link-preview cards on X, LinkedIn, Facebook, Slack, WhatsApp, Discord). It lists the exact tag families (og:*, twitter:*) and distinguishes itself from sibling tools like meta_tags_check by focusing specifically on social preview behavior.

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

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

The description gives a concrete example ('Why does my link preview look broken on LinkedIn?') that clearly signals when to use the tool. It does not explicitly mention alternatives or exclusions, so it falls short of a 5, but the context is strong and 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?

The description adds meaningful behavior beyond the readOnlyHint annotation: it explains that unparseable JSON-LD is invisible to search engines, that it checks missing required and recommended properties, and that it returns a score/grade. No contradictions 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 well-structured with an action-focused first paragraph, a concise list of covered types, and a clear args/returns/example breakdown. It is appropriately sized and every section earns its place, though the type list is long but valuable.

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 2-param schema, rich output schema, and safe annotations, the description is complete for selection and invocation. It provides the full return structure, example usage, and supported types, leaving no critical gaps.

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

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

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description's Args section largely restates the schema (e.g., 'url (string): the page to check') without adding extra meaning beyond what the schema already 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 clearly states it extracts and validates JSON-LD, microdata, and RDFa, and reports @type found, parse errors, and Google rich-result requirements. This specific verb+resource combination distinguishes it from sibling tools like render_check or seo_audit, which cover different 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 example ('Does https://example.com/product have valid Product schema?') gives a concrete use case, and the list of covered types implies when the tool applies. It does not explicitly name alternatives or exclusions, but the purpose is so specific that usage context is clear.

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