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

With no annotations provided, the description carries the full behavioral burden and does so well: it declares the tool read-only, says it writes, signs and executes nothing, lists required environment variables, explains that tenant identity comes from configuration, and documents OK, REFUSED and UNAVAILABLE outcomes including failure behavior. It also warns that the TrustGate API must support the view and that a mapping or readout is not a compliance finding.

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 front-loaded with the core purpose and then covers configuration and return statuses, but it repeats 'the records you supply' and packs several operational caveats into a dense block. It is useful but could be tightened and organized more clearly.

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?

For a tool with an output schema, the description appropriately avoids explaining return structures and instead covers authentication prerequisites, version dependency and status semantics. The main gap is the opaque request argument, which an agent would need to understand before invoking the tool.

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 exposes only an opaque request object with 0% description coverage, and the description does not explain what that request should contain. It does add one important constraint, that the tenant is never taken from an argument, but the single parameter remains otherwise undocumented.

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 states a specific purpose: evidence about whether an intervention took effect, drawn from supplied records. It does not explicitly distinguish this from sibling evidence tools such as get_decision_evidence or get_receipt_evidence, so an agent must infer which evidence surface applies.

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?

Usage context is implied by the required environment settings and the read-only framing, but there is no explicit when-to-use guidance versus the many sibling evidence and receipt tools. The note that the tenant comes from configuration rather than an argument is useful, but routing between alternatives remains unstated.

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