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

With no annotations, the description carries the full load and does well: it discloses accepted formats, a 10-file cap, 50MB per file, and the important constraint that URLs are not fetched (bytes must be supplied). It does not cover auth requirements or failure/partial-upload behavior, keeping it below a 5.

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?

Four short, front-loaded sentences with no filler; each carries a distinct constraint. The dashes and colloquial phrasing cost a little structural crispness but nothing is wasted.

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 no-output-schema, no-annotation tool, the description supplies formats, limits, encoding, and the key negative constraint. Missing only return/error behavior and the token/orderId provenance, which the schema partially covers via 'From submit_job.'

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 67%, and the description adds meaning beyond it: the format whitelist, per-file size cap, item-count maximum, and the base64-not-URL requirement. The 'fileName extension decides how the file is read' nuance duplicates the schema rather than extending it, but overall it compensates for the coverage gap.

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 first sentence gives a specific verb and resource ('Send the geometry as base64 bytes'), and the mention of quotes/a waiting job clearly separates it from submit_job and check_geometry. An agent can identify the operation without opening the schema.

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?

'Quotes need it — a job with no file waits for one' states the condition under which this tool is required, which is strong routing context. It stops short of explicitly naming alternatives or when-not-to-use this tool, so it does not reach the full when/when-not/alternatives bar.

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