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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains how the tool behaves: it maps a bernstein run to a Trust Record, generates one row per claim, sources fields from the journal, and includes the receipt's own verdict. It also calls out the specific fields it can answer. It does not discuss behavior when no receipt is passed, but for an explanatory tool this is a minor gap.

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 dense sentences with no filler. The core concept is front-loaded, followed by a concise input-output explanation. Every phrase earns its place by clarifying the mapping, the row structure, or the receipt's role.

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?

The description is complete for an explanation tool: it states the mapping being explained, the output granularity, the input, and the claimable fields. Since an output schema exists, return-value details are not required. The main missing piece is explicit guidance on receipt-optional behavior, but the overall context is sufficient 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 only describes 'receipt' as optional string or parsed object. The description adds meaningful semantics: the receipt contains an embedded journal used to fill rows, and its own verdict is included alongside the derived claims. This goes beyond the schema's bare type information.

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 opens with a specific verb and resource: it explains how a bernstein run maps onto a TRACE v0.2 Trust Record, and even specifies the output shape (one row per claim with journal field and deriving rule). This clearly distinguishes it from siblings like verify_receipt or explain_receipt because the focus is on the mapping itself, not on verification or general receipt explanation.

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 implies the usage context: pass a run receipt to fill in rows that the embedded journal can answer. However, it does not explicitly say when to choose this tool over explain_receipt or when not to use it, nor does it name alternatives. The guidance is functional rather than comparative.

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