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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), but the description adds genuinely new operational context: the call is gated behind an x402 payment costing $0.015 USDC, which an agent must plan for, plus the arithmetic-consistency check on returned numbers. It omits failure modes, accepted file-size limits, and behaviour when the receipt is unreadable.

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?

One sentence, front-loaded with the action, and the long field enumeration earns its place because there is no output schema to document the return shape. The trailing payment-cost clause is useful but slightly abrupt in placement.

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?

With no output schema, enumerating the returned fields is the right call and makes the return contract reasonably clear. However, three fully undocumented input parameters and an x402 payment flow mentioned only in passing leave meaningful gaps for a tool an agent must invoke correctly on the first try.

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% for all three parameters, and the description compensates only indirectly by mentioning photo, scan or PDF inputs. It never explains which parameter (url vs file_base64) is appropriate, what content_type should contain, or how they interact, so the agent must guess the primary input channel.

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+resource ('Read a receipt or invoice') and enumerates the exact output contract (merchant, tax ID, line items, arithmetic check), which clearly separates it from generic siblings like ocr, extract or pdf. It never names a sibling explicitly, so the differentiation is implicit rather than stated, which keeps it below 5.

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?

There is no guidance on when to choose this over ocr, extract, pdf or invoice_create, and no prerequisites or input-selection advice. An agent cannot tell from the text whether to pass a URL or an uploaded file, nor what happens when neither is supplied (0 required params).

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