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

With annotations absent, the description carries the full burden. It clearly states 'Read-only' and 'Never executes and never moves money,' covering the most critical behavioral trait. It also discloses the optional live-price fetch behavior. The phrase 'record the result' is a bit ambiguous—it might imply a side effect—but it also states 'read-only' which could be interpreted as no persistent state changes. However, the description does not detail error handling, reversibility, or the nature of the recording, so it's not fully transparent but adequate for key safety aspects.

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 three sentences, each serving a distinct purpose: the action, the optional behavior, and the safety contrast. It's front-loaded with the core function ('Read-only: check a mandate's exit conditions...') and then adds nuance. No unnecessary words, and it is well-structured for quick scanning.

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?

While the description covers the essential usage and safety, it lacks details about the snapshot object's structure, the exit conditions logic, and the output format (especially since there is no output schema). It does not mention prerequisites like wallet existence or error scenarios, making it incomplete for a tool with an optional complex parameter. The description is sufficient for selection but not for full invocation understanding.

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 has 0% description coverage, so the description must clarify parameters. It does: 'snapshot' is explained as a market snapshot and its omission triggers a live CoinGecko price for the condition asset. 'mandateId' is implicitly the identifier of the mandate being checked. This adds semantic meaning beyond the bare schema, though it doesn't specify the snapshot object's internal fields or formats, which would be more detailed.

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 verb 'check' with the resource 'mandate's exit conditions' and the action of recording the result. It also explicitly distinguishes itself from ava_approve_execute by stating 'ava_approve_execute is the only tool that does [execute/move money].' This differentiates it from siblings and leaves no ambiguity about its core function.

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 explicit usage guidance: it explains that omitting the snapshot pulls a live CoinGecko price, indicating when to include or exclude that parameter. It also gives a clear when-not-to-use statement: 'Never executes and never moves money' and points to ava_approve_execute as the alternative for execution. This is direct and actionable.

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