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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals that the operation costs $0.065 USDC on Base, that it returns evidence and status labels, and that it takes no payment or bookkeeping action. This effectively communicates the non-mutating nature and the fee without contradicting any structured metadata.

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 key cost and input facts are front-loaded, output behavior follows, and the important 'no payment or bookkeeping action' clarification is included at the end. Every sentence adds value.

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 a nested expected object, five parameters, no output schema, and no annotations, the description is missing meaningful detail about how to supply expected amounts and how the document input modes relate to mime_type. It covers fee, inputs, and outcomes well, but is not fully complete for correct invocation.

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 0%, so the description must compensate. It does map document formats to the likely document_xml, document_url, and document_base64 parameters, but it says nothing about the nested 'expected' object with fields like tax, total, subtotal, currency, supplier_name, and purchase_order, which are central to the 'amount checks' behavior.

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 names the operation ('Paid invoice check'), the resource (invoice), and immediately specifies the accepted input forms and expected outputs. It also states what the tool does not do, removing ambiguity about its role.

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 gives clear context for invocation: it is a paid preflight validation step with a fee, identifies accepted document formats, and explicitly excludes payment or bookkeeping actions. It does not name alternatives, but no siblings exist, and the usage context is otherwise explicit.

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