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

With no annotations present, the description carries the full burden of behavioral disclosure. It explicitly discloses the tool's non-mutating nature—no order creation, no payment request, no transaction authorization—and notes that inputs are caller-declared rather than independently verified. However, it does not disclose what the evaluation returns or whether there are any rate limits or authentication requirements.

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?

Three short sentences deliver the tool's purpose, scope, and side-effect profile with no filler. The safety disclaimer is front-loaded and the description is economically structured.

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 tool has a nested input schema, three top-level parameters, no output schema, and no annotations, so the description must do more than it does. It fails to describe what the preview returns, how the evaluation is presented, or how an agent should interpret the result. This is a significant completeness gap for a tool an agent must invoke and react to.

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 only 33%, so the description should compensate for undocumented parameters. It adds the high-level semantic that both transaction and evidence inputs are caller-declared, but it does not explain individual fields such as buyer_reference or transaction. The schema's nested enums and the evidence value list carry most of the parameter meaning, making this adequate but not thorough.

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 uses a specific verb and resource: 'Run the free GovOmniAI Transaction Assurance shadow preview.' It clearly states the tool's job—evaluating caller-declared transaction risk and evidence sufficiency—and works to distinguish itself from a real transaction by naming what it does NOT do. This prevents confusion with any execution-style transaction tools.

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 establishes clear usage context: it is a 'free shadow preview' that 'creates no order, requests no payment, and authorizes no transaction,' signaling this is a safe, non-committal evaluation step. It does not explicitly name alternatives or state exact when-not-to-use conditions, but the context is strong enough for an agent to infer appropriate use.

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