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

Goes well beyond the annotations: it states the file is sliced and priced server-side, saved into a basket on harktech.co.uk, and that the tool stops short of ordering or taking payment. It also documents the 3MF multi-colour handling (up to 4 colours priced from a real slice). The one gap is that repeat-call behaviour — whether a second call creates another basket entry, which the non-idempotent hint implies — is not spelled out.

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 prose paragraph is front-loaded with purpose, host rules, and return shape, all earning their place. The Args block is docstring-style and partly redundant with the schema field names, but it adds real detail rather than noise.

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?

No output schema exists, so the description explicitly enumerates the return payload (summary, price, size, postage, checkout_url) and clarifies what the caller must do next. For a four-parameter tool with a server-side side effect, nothing an agent needs to call it correctly is missing.

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?

With 0% schema description coverage, the description carries the whole burden and does so: file_url format and host constraints, the full material vocabulary, the 1-999 quantity range, and what each lead_time value does to price and turnaround. This is meaningfully more than the bare titles and defaults in the schema.

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?

Opens with a specific verb and resource: price a person's own STL/3MF/STEP file supplied as a share link. That cleanly separates it from siblings like search_models (catalogue browsing) or get_quote (pricing an existing model).

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?

Gives clear use context and explicit exclusions: the file must be reachable via a public share link, and links from unsupported hosts are refused. What's missing is a named alternative for the obvious failure case — e.g. pointing at the upload page when the person has a local file rather than a link.

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