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

No annotations are provided, so the description carries the full burden. It discloses that the tool confirms byte-identical match and points to public key and canonicalisation for offline verification, which is helpful. However, it doesn't state side effects (e.g., whether it's read-only) or error behavior (e.g., what happens if signature mismatches), leaving some transparency gaps.

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 concise, two sentences, and front-loads the core purpose. It includes useful additional context (offline verification) without unnecessary fluff. It could be slightly more structured (e.g., bullet points for parameters), but current format is efficient.

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 complexity (5 params, nested objects) and no output schema, the description provides sufficient context for an agent to call the tool: how to construct the query, what the tool does, and how to verify offline. However, it doesn't describe the return format or error handling, which could be important for agents, but the core usage 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?

Schema coverage is 80%, and the description adds meaning by explaining how parameters are used: passing an airing_id or a record plus signature. It also clarifies that query is free text and airing_id is picked out if present. This adds value beyond the schema, but for parameters like record_type (defaulting to 'airing') it doesn't explain implications, leaving some semantics to 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 verifies a signed record and provides two usage modes: passing an airing_id or passing a cached record with its signature. It distinguishes from siblings by focusing on verification, which is unique among the listed media tools, though it doesn't explicitly name a sibling to differentiate from.

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 explicit instructions on when to use the tool: either with an airing_id or with a previously cached record and signature. It also mentions an offline alternative, which guides the agent on when not to call this service. However, it doesn't explicitly state when this tool is preferred over siblings, but the context of verification is clear.

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