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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by explaining the tool returns an ES256-signed receipt and performs specific checks, supplementing the annotation-provided safety profile without contradicting it.

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 two sentences with no filler. The first sentence front-loads the core purpose and checks; the second delivers a critical safety caveat. Every clause carries informational weight, and the structure is highly 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?

For a read-only evaluation tool with rich annotations, the description covers purpose, specific checks, output decision, evidence, signed receipt, and safety constraints. The lack of parameter guidance hinders full completeness, but overall it provides enough context for correct selection and 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 description provides no explanation of the 'proposal' or 'transaction_history' parameters, and schema description coverage is 0%. While 'scenario' vaguely implies the inputs, the description does not clarify expected structure, required nested fields, or how the inputs map to the stated checks, leaving a significant gap that the schema alone cannot fill.

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 explicitly states 'Evaluate a purpose-built synthetic B2B payment scenario' and enumerates specific checks (duplicate invoices, changed payment destinations, vendor-history anomalies, signed decision evidence). It clearly identifies the output as PROCEED/REVIEW/STOP with evidence and an ES256-signed receipt, making the tool's purpose unmistakable even without siblings.

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 context: 'Evaluation only' and a directive to never send real or confidential data, which defines when this tool should be used (synthetic scenarios) and sets clear constraints. No alternative tools are mentioned, but since there are no siblings, this level of guidance is sufficient.

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