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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it makes one live HTTP request per bot, and the cost grows with the bot set (default 15), which is exactly the kind of operational detail an agent needs before calling an open-world 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?

Two sentences, no filler. The core purpose and the bot list come first, followed by the read-only and one-request-per-bot caveats — everything is front-loaded and every clause carries information.

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

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

For a 3-parameter, no-output-schema tool the description covers what an agent needs: the per-bot robots.txt verdict and the echoed HTTP status are described, so return values are not a mystery. It stops short of describing result shape per bot or error behavior for unreachable/blocked URLs, which keeps it from a 5.

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

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

Schema coverage is 100%, so the schema already documents url, bots and http, including the full known-bot list and the default. The description only echoes the http semantics ('live HTTP status when the page is fetched with each bot's user-agent string') without adding format or constraint detail, so the baseline of 3 applies.

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

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

States a concrete verb and resource ('Check whether AI crawlers ... may access a URL') and enumerates the specific bots plus the two outputs (robots.txt decision, live HTTP status). It is clear what the tool does, though it never names the closest sibling see_as_bot, so an agent must infer the boundary itself.

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

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

Usage is implied by the description: use it when you need to know whether AI crawlers are allowed on a page. There is no explicit when-not guidance, no mention of generate_robots_txt or see_as_bot as alternatives, and no prerequisites stated (e.g. URL must be public, which only appears in the schema).

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety bar is low. The description still adds real value: it discloses the default posture (welcoming AI crawlers) and that nothing is applied to a live site or fetched, which is the key mental model for an agent deciding whether to persist the output.

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 short sentences, purpose front-loaded, with the scope-of-effect caveat immediately after. No filler and nothing that could be cut without losing meaning.

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?

Zero required parameters and a simple text-generation contract make this a low-complexity tool that the description covers well, including the crucial fact that no network mutation happens. Only gap is that the returned artifact's shape (raw robots.txt text vs. structured) is left implicit, though that is nearly self-evident.

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

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

Schema description coverage is 100% with examples for both arrays, so the schema carries the parameter burden. The description only restates 'optional disallowed paths and bots to close' and omits the sitemap parameter entirely, adding no syntax or default behavior beyond the schema.

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

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

States a specific verb and resource ('Generate a robots.txt') plus the distinguishing policy stance ('welcomes AI crawlers') and the optional knobs. Echoes the title's verb but adds scope that separates it from the sibling tools see_as_bot and check_ai_access, which inspect rather than generate.

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?

Implies the use case (produce a permissive robots.txt with carve-outs), and 'pure text generation; makes no network requests' hints this is not the checking path. But it never names see_as_bot or check_ai_access or states when an agent should pick those instead.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is lowered. The description adds genuinely new context: that the URL mode performs an outbound fetch of /robots.txt, and that results are structured findings with stable codes, line numbers and severity — useful for planning downstream handling.

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

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

Front-loaded with the purpose, then a tight list of finding categories, then input modes, then output shape. Three sentences, no filler, every element 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?

No output schema exists, so the description carries the return-value burden and does so ('Findings carry stable codes, line numbers and a severity'). Combined with the fetch semantics and dual input modes, an agent has everything needed for a read-only lint call.

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

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

Schema description coverage is 100% and both parameters already document the URL-fetch and inline-text behavior, so the description adds only a paraphrase of the same distinction. Baseline 3 applies since the schema does 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?

States a specific verb and resource ('Lint a robots.txt') and enumerates the concrete defect classes it detects, which also separates it from generate_robots_txt (authoring) and check_ai_access (AI-specific probing). An agent can pick this tool without opening the schema.

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

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

The two entry modes are made explicit ('Give the site's URL (fetches its /robots.txt) or the file's text'), which frames the usage context well. However, no sibling is named and there are no stated exclusions, so routing versus generate_robots_txt or check_ai_access is left to inference.

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

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

Annotations already cover read-only/idempotent/open-world, yet the description adds real behavior: it fetches only robots.txt and sitemap files and never the pages, follows a sitemap index one level, falls back from robots.txt-declared sitemap to /sitemap.xml, and skips .gz sitemaps. Missing only what happens when robots.txt or the sitemap is absent/blocked (error vs empty result).

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

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

One dense paragraph, front-loaded with the purpose and sitemap discovery order before the constraints. Every clause carries information (discovery fallback, index depth, host/limit bounds, .gz skip, fetch scope); nothing is padding.

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

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

No output schema exists, and the description gives the return shape at a high level ('per bot which URLs robots.txt blocks'), plus discovery and limit semantics. Enough to call correctly; a sentence on behavior when no sitemap is found would close the remaining gap.

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

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

Schema coverage is 100% and the schema already documents bots (including the known-token list), limit (max 200, default 25), and the http(s) url constraint. The description re-states 'up to 200 URLs' and adds the same-host restriction, but contributes almost nothing the schema does not already say, so the baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Check robots.txt for many pages of one site at once', with the URL source and the output shape ('reports per bot which URLs robots.txt blocks'). This clearly separates it from lint_robots_txt (rule validation) and check_ai_access (single-page check) without needing the schema.

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

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

'for many pages of one site at once' and 'Same host only, up to 200 URLs' give clear conditions for use and the boundary where the tool stops being appropriate. It never explicitly names the sibling to use instead for a single-URL check, so no full alternative routing, but the bulk-vs-single distinction is inferable.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description does not need to restate safety. Instead it adds behavior the annotations cannot convey: a five-redirect cap, the exact spoofed user-agent mechanism, block/challenge detection, and the important limitation that results are not proof of what the real crawler receives.

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

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

Two sentences, zero filler, front-loaded with the mechanism and immediately followed by the report list and the caveat. Every clause carries information an agent needs to predict the output.

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

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

With no output schema, the description steps in to name every returned field (status, final URL, content type, size, title, block-likelihood) plus the redirect cap and the interpretive limitation. For a two-parameter read-only fetch, nothing an agent needs before calling 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% — both url and bot are documented in the schema, including the enumerated list of known bot tokens. The description adds no syntax or format detail beyond that, so the schema does all the parameter work and the baseline of 3 applies.

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

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

States a specific verb and resource — fetch one URL with a given bot user-agent — and enumerates what is reported (status, final URL, content type, size, title, block heuristics). That is highly distinctive, but it never names the sibling tools it could be confused with, so sibling differentiation is left to inference.

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

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

The closing caveat 'Does not prove what the real bot gets (operators verify IP ranges)' is a real usage boundary that a caller should know. However, it offers no positive when-to-use statement and no explicit comparison to check_ai_access or generate_robots_txt, so routing between siblings remains 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 cover read-only, idempotent, open-world and non-destructive, but the description adds real behavioral facts on top: it reads operators' public lists, never connects to the target IP, and 'verified null means it could not be decided'. That last point is essential tri-state semantics that no structured field conveys.

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, purpose front-loaded, with no filler. The second sentence ('Without bot, checks every bot that has such a method') is slightly awkward in phrasing, keeping it from a perfect score.

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

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

With no output schema, the description carries the return-value burden and does explain the null case, but it never states the shape of a successful result (e.g. the fields returned alongside 'verified'). Otherwise it covers method, scope and safety adequately for a 2-parameter tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying that omitting 'bot' checks every bot 'that has such a method' – a nuance beyond the schema's plain 'Omit to check all'. It also implicitly frames the result as a 'verified' tri-state value.

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

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

States a specific verb and resource (verify whether an IP really belongs to a crawler) and names the two documented verification methods (published IP-range list, forward-confirmed reverse DNS). It does not explicitly contrast itself with the siblings (see_as_bot, check_ai_access, generate_robots_txt), though the operation is distinct enough to be inferred.

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 server-log spoofing example ('claiming to be Googlebot') gives a concrete when-to-use context, and 'Without bot, checks every bot' clarifies the default scope. There are no explicit when-not-to-use conditions or named alternatives, 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.