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

With no annotations, the description carries the burden of behavioral disclosure. It reveals meaningful traits: response bodies are re-hashed at read time, the custody record exposes gaps between rows stored and rows batch-committed, and the result is a signed Ed25519 receipt. This goes beyond a simple 'returns an evidence pack' statement.

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 well-organized: main purpose first, then contents, then attestation and receipt. Each clause adds relevant information. The second sentence is a fragment, but it still conveys a distinct behavioral guarantee.

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?

There is no output schema, so the description should explain the return value more fully. It mentions a signed receipt and bundle contents, but does not describe the receipt structure, the incident_found=false behavior, or how the custody record is presented. For a complex 4-parameter tool, this leaves 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?

Schema description coverage is 100%, so baseline is 3. The description relates to domain and resource by naming policy-surface types, but it adds no parameter-specific detail beyond what the schema already documents for event_date or include_bodies.

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 output—a per-incident evidence pack about a single domain's policy-surface change—and enumerates the included resources (robots.txt, ai.txt, llms.txt, TDM-Rep). It distinguishes this from likely siblings like web_policy_history by emphasizing 'per-incident' and 'self-contained bundle', though it lacks a direct action verb like 'retrieve' or '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?

The description conveys what the tool returns but does not state when to use it versus alternatives such as web_policy_history. There is no explicit when-to-use or when-not-to-use guidance, and sibling tools are not mentioned.

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