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

No annotations are provided, so the description carries the behavioral burden. It adds useful context by stating there is a per-call credit cost, that cost applies only to successful calls, and that the output includes a confidence score and review_needed flag. It does not discuss failure modes or side effects, but for a read-oriented parsing tool this is substantial disclosure.

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 tightly packed sentences with no filler. It front-loads the core purpose, then covers input, output, and cost in order of importance.

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 or annotations, the description correctly summarizes return values and the important credit cost. It omits nothing critical for invocation because the input schema already documents all seven parameters and their relationships, though it could have explicitly guided users between schema, schema_id, and instructions.

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 100%, so the baseline is 3 and the schema already documents all parameters. The description reiterates that url/base64 are input alternatives and that schema/instructions are optional, but it does not add much meaning beyond the schema's own parameter descriptions.

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 ('Extract') and resource ('PDF or image') and states the result is 'clean, schema-guaranteed JSON'. It distinguishes itself from parse_text by explicitly framing the input as PDF/image rather than text.

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 clearly says the tool is for PDFs or images and supports url or base64 input, plus optional schema and instructions. It does not explicitly name when to use parse_text, infer_schema, or validate instead, so it stops short of full alternative routing.

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