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

With no annotations, the description carries the full burden and does so unusually well: it discloses the $0.25/call price, the USDC-on-Base no-account payment model, a 10 MB input ceiling, the 400-on-unreadable-input failure mode with no charge, and the null behavior for fields the document does not state. These are exactly the traits an agent cannot infer from the schema.

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?

It front-loads the core contract ('structured data ... plus a JSON Schema, get back one JSON object') and then packs pricing, formats, limits, and failure semantics into short clauses with no filler. Every sentence carries information an agent needs.

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 7-parameter tool with no output schema, the description covers return shape, null semantics, cost, and error behavior well. It stops short of explaining the payment handshake (whether a 402 challenge precedes the call), which matters given the pay-per-call model, leaving a small gap for the agent.

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 coverage is 100%, so the baseline would be 3, but the description adds meaning the schema does not: the schema parameter governs the shape of the returned object, and absent fields resolve to null. The 10 MB cap and the url-XOR-base64 rule are restated from the schema rather than extended.

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 gives a specific verb+resource: send a document plus a JSON Schema, get back one JSON object filled from it. It distinguishes itself functionally from sibling converters (doc_ocr, doc_to_markdown) by emphasizing schema-driven extraction, but it never names those siblings, so the agent must infer the boundary.

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?

Concrete use cases are listed (invoices, contracts, forms, CVs, receipts) and the input shape ('url or base64') is stated, giving a clear picture of when this applies. There is no explicit statement of when NOT to use it or a pointer to doc_ocr/doc_to_markdown for raw text, which is the only real gap.

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