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

Adds substantial behavioral context beyond the annotations: the exact billing cost, the requirement to prepare first, the private Authorization header, and the crucial idempotency nuance that a new requestId means a new billable operation. This usefully qualifies the idempotentHint=true annotation and clarifies cost 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 tight and front-loaded with the core purpose, then adds necessary operational details without redundancy. Every sentence adds value: no network fetch, cost, prerequisite, auth, and idempotency/recovery behavior.

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

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

Covers the essential operational context for a paid, stateful tool: prep requirement, credits, auth, cost, and recovery semantics. Since an output schema exists, return-value details do not need to be in the description. The description is complete enough for an agent to use 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 schema already describes requestId and maxPriceMicroUsd well, and the description reinforces their recovery and billing semantics ('Reuse prepared arguments', 'a new requestId is a new billable operation'). The nested input fields lack schema descriptions, but their meanings are evident from the tool purpose and property names.

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 ('Evaluate'), a precise resource ('supplied robots.txt'), and the dimensions of the evaluation ('for a URL and user agent'). The explicit 'no network fetch' distinguishes it from fetch-oriented siblings like web_readable_fetch and web_redirect_trace.

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 prerequisites: must call agent_utilities_prepare first, needs credits and an Authorization header. It also explains recovery usage ('Reuse prepared arguments for recovery'). It does not explicitly name an alternative to use when a network fetch is needed, but the 'no network fetch' statement strongly implies this tool is only for supplied content.

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