Mandarin 3D

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

Annotations already declare non-read-only, non-idempotent, open-world, non-destructive. The description adds genuinely new behavior: creation triggers a customer checkout flow that collects the shipping address, and requires a documented terms acknowledgement gate. What it does not state is whether repeated calls create duplicate links or what the tool itself returns (a URL?), which matters given idempotentHint=false.

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?

Front-loaded with the action, then the flow, then the gating condition. The quoted terms text is long but is verbatim-required content, so it earns its space; the structure is tight overall.

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 checkout-creation tool with no output schema and partial param coverage, the prerequisite gate and customer-facing flow are well covered. The missing piece is the return value (presumably a checkout URL) and duplicate-call behavior, which an agent calling a non-idempotent creation tool would want.

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 only 40% schema description coverage, description needs to compensate. It does explain customer_accepted_terms precisely by quoting the exact sentence the customer must agree to, which adds real value beyond the schema. However, quote_id is undocumented anywhere and the description adds no detail on color, qty, or how the options map to the link's charges.

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?

States a specific verb and resource ("Create a payment link for a quote") and immediately explains the customer-facing effect: they pay and enter their shipping address on the linked page. An agent can distinguish this from sibling tools like price_quote or quote_file 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?

Gives an explicit precondition (show the price, get explicit agreement to the exact terms sentence) and names the alternative when the condition is not met: "Otherwise give them the order_url from quote_file instead." This is textbook when/when-not with a named sibling.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint=false), and the description usefully clarifies that nothing is created or quoted here — it only returns a link and the customer completes the work externally. That downstream behavior is context an agent could not infer from the annotations alone.

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?

Two sentences, no waste: the audience condition and example parts come first, then the mechanics and expected outcome. Nothing is repeated from the schema or annotations.

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?

There is no output schema, so the description must explain the return value — and it does, stating it returns a link. Combined with the single well-documented parameter, an agent has everything needed to call this correctly and set user expectations.

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% and the parameter already documents format and units, so the baseline is 3. The description adds value by stating what the input is used for — pre-filling the external designer — which explains why the free-text description matters rather than just what it contains.

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?

States a specific action and outcome: returns a pre-filled link to Mandarin 3D's AI part designer, with concrete example use cases (knob, clip, bracket, box, spacer, enclosure). It doesn't name a sibling explicitly, but the 'without a 3D model' framing implicitly separates it from file-based tools like quote_file.

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?

'For customers without a 3D model' gives a clear selecting condition that routes the agent away from file-upload tools, and the downstream flow (adjust, see price, order) sets expectations. It stops short of naming an alternative tool or stating exclusions explicitly.

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

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

Annotations already declare readOnlyHint and closed-world, so the safety profile is covered; the description contributes the substantive scope constraints (US-only shipping, size/file limits, turnaround) that shape what answers are possible. It does not state whether the facts are static documentation versus live data, which is the one behavioral detail an agent might want. No contradiction with the read-only annotation.

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 content list is front-loaded in one dense sentence using a parallel structure, with the usage routing in a second sentence. Every clause maps to a distinct fact category, though the enumeration is long enough that it reads as a checklist rather than a sharp summary.

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 parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does so by cataloguing the seven fact categories. The only missing piece is the return shape (prose versus structured sections), which is minor for a static info tool.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly signals a parameterless lookup by presenting the tool as a fixed fact sheet rather than a query interface.

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 enumerates precisely what the tool returns: printing capabilities, US shipping scope, pricing formula with examples, colors, size/file limits, turnaround, and ordering steps. That is far more specific than the title 'Service facts and prices'. It stops short of a crisp verb framing (it never says it returns a static knowledge document), but the content scope is unmistakable.

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?

It gives explicit trigger questions ('where can I get something 3D printed', 'how much does 3D printing cost'), which tells the agent when to reach for it. The gap is that it does not distinguish itself from the sibling price_quote, even though it claims the 'how much does 3D printing cost' intent — the agent must infer that this returns a generic formula while price_quote produces a specific number.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and 'No side effects' merely restates that. The description adds nothing the structured fields don't cover — nothing about whether the returned price is persisted, how rounding/currency works, or that quote_id must reference an existing quote.

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?

Two short sentences with zero filler; the scope statement is front-loaded and the safety note trails it. Nothing to trim.

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 pricing calculation with a nested options object and no output schema, an agent still doesn't know what comes back (a total only, or a line-item breakdown) or whether unmentioned add-ons inherit from the original quote. Adequate but with real gaps.

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 only 25%, but the description maps its three mutable dimensions (qty, color, options) onto the parameters, and the nested option fields carry rich per-option descriptions in the schema itself. quote_id's requirement (must be an existing quote) is only implied by 'existing quote'.

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?

States a specific verb (price) and resource (an existing quote) plus the dimensions being varied (quantity, color, add-ons). 'Existing' distinguishes it from quote_file, but that sibling is not named, so differentiation is inferred rather than stated.

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 phrase 'for another quantity, color or add-ons' implies the scenario (re-pricing an already-created quote), but there is no explicit when-to-use/when-not guidance and no reference to alternatives like create_checkout or quote_file.

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

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

Adds real context beyond the annotations: 100 MB URL vs 20 MB base64 limits, a 5–60 second latency expectation for new files, and the returned quote_id/order_url flow. It does not discuss idempotency or the auth/rate-limit profile, though the annotations already flag idempotent and open-world behavior.

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 tight sentences: what it does, how to supply the file, what comes back, how long it takes. No filler and the core action leads.

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, the description correctly enumerates the return fields and the follow-on order_url, and it covers size limits, formats and latency. An agent has everything needed to call it and interpret the result.

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 baseline is 3; the description still adds value by giving the size caps and the file_url vs file_base64 + filename pairing rule, which the schema only partially implies. It omits qty from the description, but the schema documents it fully.

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?

States a specific verb and resource — slice a 3D model and return an exact delivered price — plus the shipping method, so the function is unmistakable. It never names or contrasts with the sibling tools (price_quote, create_checkout), so an agent must infer the boundary itself.

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?

Clearly routes between the two input modes: file_url for a public direct download link, file_base64 + filename for a local file, with size caps for each. It stops short of saying when to choose this over price_quote or create_checkout.

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