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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with these. It adds substantial behavioral context by enumerating exactly what checks are performed (AI crawler access, file detection, structured data, meta signals) and the output contents. This goes beyond the annotations, which only signal safety, not the scope of the audit. No contradiction.

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

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

Two sentences, no redundancy. The first sentence front-loads the core action and return payload; the second provides usage guidance. Every word earns its place, and the structure naturally surfaces the important 'first step' instruction.

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 no output schema exists, the description fully enumerates the output components (score, per-crawler status, AI-specific files, structured data, meta signals, fix list), which is essential for the agent to understand what to expect. The one parameter is well-covered by the schema. The usage context is clear. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema coverage is 100% – the schema fully describes the 'url' parameter. The description only refers to 'a website' without adding format or constraints beyond the schema (e.g., no mention of protocol handling or query string). Baseline 3 is correct when the schema carries the parameter documentation, and the description adds no extra semantic value.

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

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

The description states a specific verb ('Check') and resource ('AI crawlers can access a website'), then enumerates the detailed return values (readiness score, per-crawler status, AI-specific files, structured data, meta signals, fix list). This clearly distinguishes it from sibling validators (validate_robots, validate_schema, etc.) as a comprehensive first-step audit, not a single-aspect 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?

It explicitly tells the agent to 'Use this as the first step in any AI SEO audit', giving clear positional guidance among siblings. It does not explicitly list when NOT to use it (e.g., for deep validation of a single aspect, use validate_robots), but the first-step framing implies that granular validators follow. A minor gap, so a 4 is appropriate.

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 this as read-only and open-world, so the safety profile is covered. The description adds substantial behavioral context: it performs four parallel fetches, specifies the exact user agents, and enumerates what it detects (JS-only shells, cloaking, edge-based bot blocking), which 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?

Two dense sentences, front-loaded with the purpose and followed by the method and output details. Every phrase adds value and there is no filler or repetition of annotation fields.

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

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

With only one parameter, no output schema, and annotations already covering safety, the description is complete: it states what the tool does, how it fetches, and what reports/warnings the agent should expect. Nothing essential for calling and interpreting the tool is missing.

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

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

Schema description coverage is 100% and the single url parameter already has a clear description. The tool description does not add parameter-level details, which matches the baseline expectation when the schema fully documents parameters.

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

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

The description opens with a specific, meaningful comparison ('human browsers vs AI crawlers') and then names the concrete mechanism (four parallel fetches as Chrome, GPTBot, ClaudeBot, PerplexityBot) and outputs (word-overlap %, title/description differences, warnings). This clearly distinguishes it from siblings like check_ai_readiness or validate_robots by focusing on parity detection rather than readiness or validation.

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 intended use case is implied clearly: call this when you need to compare rendering across browsers and AI crawler user agents. However, it never explicitly states when not to use it or which sibling alternative to prefer, leaving the selection decision to the agent based only on sibling names.

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 behavioral context beyond annotations: it performs an external crawl (aligning with openWorldHint), requires an API key, and returns content for the AI client to write to disk rather than writing files itself. It does not detail failure modes or rate limits, but those are minor given the annotations already flag the open-world, non-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?

Three sentences carry the full purpose, process, outputs, client action, and prerequisite with no filler. The main purpose is front-loaded and every clause earns its place.

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

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

For a one-parameter tool with no output schema, the description explains what is produced (llms.txt content and a companion robots.txt snippet), how the client should handle the result, and the auth prerequisite. Minor gaps remain around exact return structure and API-key mechanism, but the core information needed for selection and invocation is present.

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% coverage for the single url parameter, so the baseline is appropriate. The description reinforces that the URL should be a website whose sitemap will be discovered and crawled, but it does not specify URL format, scheme requirements, or how the API key should be supplied. This is adequate but not additive 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 states a specific verb and deliverable: generate a properly formatted llms.txt file. It adds concrete process details (crawls sitemap, groups pages by section, pulls titles and descriptions) and names the companion output of a robots.txt snippet, making it clearly distinct from sibling tools like generate_robots_txt or generate_schema.

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

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

It is clear that this tool is for generating llms.txt for a website, and the prerequisite of an API key is explicit. It does not directly contrast with siblings or state when not to use it, but the primary artifact is unambiguous and the description provides enough context for an agent to know when this tool applies.

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=false annotation, the description discloses meaningful side effects: it fetches the existing robots.txt, writes generated.robotsTxt to /robots.txt, and requires an API key. It also describes the return payload (generated file plus per-bot allow/block breakdown), giving the agent a clear picture of behavior.

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

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

The description is dense but each sentence earns its place: purpose, workflow, presets, side effect, and auth requirement. The important behavioral information is front-loaded and the preset list is structured and scannable.

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

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

For a two-parameter tool with no output schema, the description covers the return value, the side effect, the presets, and the auth requirement. It could be more complete by limiting when to use it vs. sibling tools, but it is adequate for a competent 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value by explaining the meaning of each preset ('allow-all', 'search-only', 'recommended', 'block-all') and their intended use cases. It does not add syntax details for url, but the schema already documents that parameter.

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

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

The description names a specific deliverable ('AI-crawler-aware robots.txt') and a concrete workflow (fetch, merge, write), which differentiates it from sibling validation/generation tools. The opening sentence states exactly what the tool produces for a website.

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 generate a ready-to-save robots.txt with an AI-crawler policy, and it enumerates preset policies for different site stances. It does not explicitly say 'use validate_robots instead for validation', but this is not necessary for correct selection given the sibling names.

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

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

Beyond annotations, the description discloses meaningful behavioral traits: it detects site metadata, produces multiple schema types plus starter templates, returns ready-to-paste script blocks, and requires an API key. This aligns with readOnlyHint=false and openWorldHint=true while adding concrete expectations about the tool's 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 four sentences, each carrying distinct information: the core action, the detected metadata, the output format, and the API key requirement. There is no filler or redundancy, and the most important information is front-loaded.

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

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

For a one-parameter tool with no output schema, the description covers the essential calling context: what it detects, what schemas it produces, how output is returned, and the required API key. It does not explain API key acquisition or error behavior, but the agent has enough 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?

The input schema already fully describes the single 'url' parameter as 'The website to generate schema for,' giving 100% schema description coverage. The description reinforces that the URL points to the target website but adds no parameter-level detail, so the 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 uses a specific verb ('Generate') and resource ('JSON-LD structured data for a website'), then enumerates concrete output types including Organization, WebSite, Article, BreadcrumbList, and FAQPage. This clearly differentiates it from siblings such as validate_schema or generate_robots_txt.

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: generating JSON-LD schema for a website, and it notes the API key prerequisite. It does not explicitly name alternative tools or state when not to use it, but the artifact type and sibling names make the intended use reasonably unambiguous.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the description correctly reinforces 'Read-only' rather than contradicting it. It adds valuable context beyond annotations: it reads previously collected LLM Monitor data, does not trigger new runs, and requires an API key. This exceeds the minimum bar for behavioral disclosure.

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 longer than the examples but every sentence carries functional weight: purpose, invocation modes, behavioral scope, and auth requirement. It is front-loaded with the core purpose and avoids filler, though it could be slightly tightened without losing information.

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

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

For a read-only tool with one optional parameter and no output schema, the description covers the essential operational context: what data is read, what the two call patterns return, and the API key requirement. It does not mention pagination, error cases, or exact formatting of the project id, but these are minor for this simple 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?

Although schema description coverage is 100%, the description meaningfully enriches the sole parameter. It explains the omission behavior (list all monitored brands) and the provided behavior (full trend, per-provider breakdown, competitor comparison, average position, example answers) — details far beyond the schema's one-line parameter description.

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

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

The description states a highly specific verb and resource: seeing whether AI assistants mention a brand and how that share-of-voice trends versus competitors. It also clearly distinguishes the two modes of operation (list all vs. detail one), making it easy to tell apart from the unrelated 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 gives concrete instructions on when to call with no argument versus with a brand name/project id, and clarifies that it does not trigger new runs. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are thematically distinct enough that no routing ambiguity arises.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds behavioral context beyond that by explaining that a URL is fetched and audited, while raw text is audited directly, and by listing the specific issues detected. 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?

Two sentences with no filler. The first sentence states the action and scope, the second lists detection categories and input requirements. Every sentence earns its place.

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

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

The description covers input modes, audit scope, and specialized AI-bot coverage, which is enough for an agent to invoke the tool correctly. The only minor gap is the lack of an explicit output format, but no output schema exists and the description still conveys that results are audit findings and a coverage summary.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating the either/or relationship between url and text, and by clarifying that url means 'fetch and audit' while text means raw input, which goes beyond the schema property 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 uses a specific verb ('Audit'), names the resource ('robots.txt'), and enumerates concrete checks such as syntax errors, empty user-agent groups, orphan Allow/Disallow lines, and AI-bot coverage. This clearly distinguishes it from siblings like validate_schema and check_ai_readiness.

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: use this tool when you need to audit a robots.txt file, and it explains the two input modes ('Provide EITHER url ... OR text'). It does not explicitly name alternative tools or when not to use them, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral detail: it extracts every script block, runs each through a rules engine covering 20+ types, and reports required-field errors, warnings, and type-specific gotchas. 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 two sentences with no redundancy. It front-loads the primary purpose, then details the scope, process, and output in a compact format. Every sentence earns its place.

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

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

For a single-parameter, read-only tool with no output schema, the description is complete. It explains what is validated, how (extraction and rules engine), and what is reported (errors, warnings, gotchas). An agent has enough to call it correctly without additional context.

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 only one parameter (url) and 100% schema description coverage, the schema already fully documents the parameter. The description's mention of 'on a URL' adds no new syntax or format details. Per the rubric, the baseline of 3 is appropriate since the schema carries the heavy lifting.

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 (validate) and resource (all JSON-LD structured data on a URL), and lists the covered types (Article, Organization, Product, etc.), which clearly distinguishes it from sibling tools like generate_schema or validate_robots. It leaves no ambiguity about 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 clearly implies when to use this tool: whenever you need to validate JSON-LD structured data on a given URL. However, it does not explicitly mention alternatives or state when not to use it (e.g., for generating schema or validating robots.txt). The context is clear but lacks explicit exclusions.

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