3D Printer on Demand

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

Annotations already cover read-only safety, but the description adds substantive behavior: it reads the file, runs the same automatic design checks as the website, stores nothing, and returns an upload link when no file is attached. That is real context beyond structured fields.

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?

Three sentences, trigger front-loaded, every clause carrying information (what it checks, what it does not do, the fallback). No filler or repetition of the title.

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?

An output schema exists, so return values need not be described. Given the read-only annotations plus the description's coverage of inputs, side effects (stores nothing) and the no-file path, an agent has everything needed to call it correctly.

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 schema already documents material, model_file and part_description, including the enum values. The description names supported file formats but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (check a 3D model's printability) and enumerates exactly what it inspects: size, walls, mesh problems and remediation. It also distinguishes itself from siblings with 'It gives no quote,' routing quoting intent to get_print_quote.

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 trigger is explicit: 'Use this when someone attaches an STL, 3MF, STEP or OBJ file and wants to know whether it will 3D print well.' It also states the negative case ('gives no quote') and the no-file fallback behavior, leaving little to inference.

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 destructiveHint=false and openWorldHint=false, so the bar is lower, and the description still adds real context: a new quote record is written, earlier quotes are left untouched, and the response carries combined totals versus per-quote costs. It stops short of stating idempotency or whether repeated combines stack, which is the only meaningful gap.

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 selection condition, then behavior, then exclusions — a sensible order with no filler. Three sentences is proportionate, though the middle sentence packs two ideas (what is saved and what is returned) that could read more cleanly.

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 one-parameter mutation with annotations and an output schema, everything an agent needs is present: trigger, preconditions, side effects, what is left unchanged, and what the returned link represents. Return-value details are bonus rather than a burden here since an output schema exists.

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 minItems/maxItems already constrain the array, so the schema does the heavy lifting. The description still adds meaning the schema cannot: the links must be 'private quote links from earlier quotes in this chat' and one per part, which is exactly the mis-fill an agent would otherwise make.

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 ('saves one quote that holds all the parts') plus the outcome ('returns its private link with one combined total and one shipping charge'). It also distinguishes itself from quote_from_link by excluding quotes made outside this chat, so an agent can pick it out of the sibling list without opening a 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 trigger ('use this when someone has two or more quotes from 3D Printer on Demand in this chat') and explicit exclusions ('does not take a quote made outside this chat or a part still waiting for a person'). Both when-to-use and when-not-to-use are covered with no inference required.

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, destructiveHint=false and openWorldHint=false, and the description adds real behavioral guarantees beyond that: it will not fabricate costs and it reports which number is missing. That missing-value disclosure is the kind of failure-mode behavior annotations cannot express. The rest ('returns the totals for each, the crossover quantity...') largely restates what the output schema already conveys, which keeps it from 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?

Three sentences, front-loaded with the when-to-use clause, then outputs, then the reliability caveat. No filler and no repetition of the tool name or title.

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 seven optional parameters (zero required), a full output schema and clear annotations, the description covers purpose, inputs, outputs and trust behavior adequately. The one gap is that it never explains what happens if the user supplies no numbers at all, which matters given that every parameter is optional.

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 schema already documents all seven parameters with units, defaults and bounds, making 3 the baseline. The description adds little parameter meaning and only names four of the seven inputs (quantity, printed unit cost, tooling cost, molded unit cost), silently omitting setup_cost, revision_cost and tool_revisions, which could mislead an agent into ignoring revision-related costs.

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 (compare) and two specific resources (3D printing vs injection molding) plus the scope (for a quantity, using the user's own numbers). This is clearly distinguishable from siblings like get_print_quote or recommend_material, which do different jobs.

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?

'Use this when someone wants to compare 3D printing with injection molding for a quantity, using their own numbers' gives a clear triggering condition and even constrains the input mode (user-supplied figures, not a quote lookup). It does not name an alternative tool or state when not to use it, so it stops short of a 5.

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 readOnly/openWorld=false/destructive=false, so the safety profile is covered. The description still adds that answers come with published sources and a link to the full page and that it is scoped to guidance (not file checks), which is useful behavior beyond the structured fields.

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 topic list is long but front-loads the trigger and every item earns its place by defining coverage scope. No filler sentences; the exclusion is placed last as a boundary marker.

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 an output schema covering return values and annotations covering safety, the description only needs to cover trigger, scope, and boundaries – all present. The brief omission of how topic vs question interact when both are supplied is minor.

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% and the enum enumerates every topic, so the schema carries the parameter burden; per calibration this is a baseline 3. The description recaps 'takes a topic or the question' but adds no syntax or format detail beyond 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?

States a specific verb and resource ('how to design a part for FDM 3D printing') and enumerates the covered topics, so the agent knows exactly what guidance it returns. The closing line 'It does not check a specific file' distinguishes it from the check_printability sibling.

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 trigger is explicit ('Use this when someone asks how to design a part...') and the exclusion 'does not check a specific file' rules out the file-inspection use case. It never names the routing sibling by name, but the when/when-not is clear enough to select correctly.

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 destructiveHint=false, so the safety profile is covered. The description adds real context: it consumes the private order link from email, it explicitly does not return the shipping address, and it does not mutate the order. This is useful beyond the annotations, though it doesn't mention rate limits or error 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?

Three efficient sentences, front-loaded with the usage condition, followed by what it returns and what it excludes. Every sentence adds distinct value and there is no redundancy.

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 single-parameter read-only tool with an output schema, the description is complete: it states the trigger, the return contents, and explicit exclusions. Nothing an agent needs to call it correctly is missing, and the output schema handles return structure.

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%, meaning the single parameter is already fully documented in the input schema. The description repeats that it 'takes the private order link from their order email' but adds no new syntax, format, or validation detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('returns the order's status, its parts, how many have shipped, and any tracking numbers') and clearly distinguishes it from siblings like get_print_quote and reorder_from_order by describing exactly what it retrieves. An agent knows precisely what this tool does 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?

Explicitly states when to use it: 'when someone who ordered from 3D Printer on Demand asks where their order is or what state it is in.' It also states exclusions ('does not show the shipping address and it does not change the order'), which helps an agent avoid misusing it for address changes or order modifications.

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 only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds substantial behavior on top: it reads the file, validates printability, persists the quote, returns an estimate with a private website link, and degrades to an upload link when no file or an unreadable type is present. The stated 'saves the quote' is consistent with readOnlyHint=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-loads the trigger condition, then layers the normal path, the fallback path, and the scope exclusion in four tight sentences with no filler. Each sentence carries distinct, load-bearing information.

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?

An output schema exists so return values need no explanation, yet the description still clarifies the key output (estimate plus a private quote link) and the degraded fallback response. Combined with the write semantics implied by annotations, an agent has everything needed to call this correctly.

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 schema already documents material, color, quantity, and the nested model_file fields — this sets the baseline at 3. The description reinforces which file types are acceptable and that a missing attachment is tolerated, but adds no new syntax or constraint detail for the individual parameters.

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+resource (produce a 3D printing cost quote) and enumerates the exact input file types accepted (STL, 3MF, STEP, OBJ). It also carves out scope boundaries that separate it from siblings — it explicitly excludes drawings/photos and describes the no-file fallback that distinguishes it from quote_from_link.

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?

Opens with an explicit trigger ('Use this when someone asks how much it costs...'), states an exclusion ('does not cover drawings or photos'), and describes the no-file/unreadable fallback path. It stops short of naming the sibling to use instead (e.g., quote_from_link, check_printability), so routing among neighbors is still partly inferential.

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. The description adds a meaningful behavioral fact beyond annotations: it returns facts 'as our website publishes them,' signalling the data is static published documentation rather than computed/real-time. It doesn't discuss freshness or latency, but the annotations carry the safety profile.

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?

One dense sentence with the trigger front-loaded and the fact list following. The topic enumeration is long but each item is a genuine query category; minimal waste.

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, readOnly/openWorld annotations, and an output schema present, the description covers exactly what an agent needs: when to call it and what categories of facts come back. Return-value explanation is unnecessary given the output schema.

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 the baseline is 4. The description correctly implies a no-argument retrieval of published facts, consistent with the empty 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?

States a specific resource (3D printing service details) with an enumerated list of covered facts (lead time, shipping, quote hold, file types, max size, refused items, upload/contact). It's clearly distinct from siblings like get_print_quote or list_materials, though it doesn't explicitly name them.

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 a clear trigger ('when someone asks how 3D Printer on Demand works') plus concrete example topics. It doesn't articulate when NOT to use it or name alternative tools, but the enumerated question types effectively scope its use.

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 cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds real value by describing the return contents and, notably, the negative scope 'returns no engineering figures', which sets agent expectations. It stops short of detailing any limits or freshness 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?

Two sentences, front-loaded with the trigger conditions and followed by the return summary. Both sentences carry distinct, non-redundant information and the negative scope note earns its place.

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?

An output schema exists so return values need not be enumerated, yet the description helpfully summarizes them anyway, and a 0-param list tool requires little else. The one gap is the unstated boundary against recommend_material, which is a relevant sibling.

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 document and the baseline is 4. The description correctly does not invent parameter semantics, and the empty schema means no compensation was ever needed.

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 (list) and resource (print materials/plastics) with concrete detail about what each entry contains (purpose, colors, quoting). It is clear, but the trigger 'which material suits a job' overlaps with the sibling recommend_material, and the description never names that sibling to disambiguate.

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 four explicit trigger scenarios (which plastics, which colors, which suits a job, which are human-quoted), which is strong when-to-use guidance. However it offers no when-not guidance and does not explicitly route to recommend_material when a recommendation rather than a list is wanted.

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 establish that this writes (readOnlyHint=false) and reaches external sites (openWorldHint=true), and the description goes well beyond that by disclosing the exact pipeline: it reads the site licence, downloads the file, validates printability, persists a saved quote, and returns an estimate plus a private link to the stored quote. It also states the multi-file listing behavior and the rights-confirmation fallback — real behavioral context the annotations cannot convey.

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 trigger ('Use this when...') followed by the operation sequence and then edge cases; every sentence carries information. Sentences are long and clause-heavy, which slightly hurts scanability, but there is little true redundancy.

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 complex, open-world, write-enabled tool with 7 parameters, the description covers the trigger, the multi-step behavior, the artifact created, and the out-of-scope case. Because an output schema exists, it need not explain return values, and nothing an agent needs to invoke 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning on top of the schema by explaining the multi-file selection round-trip (which motivates file_key) and the condition under which rights_confirmed is required, giving workflow context the field descriptions alone don't provide.

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 states a specific verb and resource ('quote ... to have it printed and shipped') and spells out the full operation: read licence, fetch file, check printability, save quote, return estimate. It clearly separates this link-driven flow from the sibling get_print_quote without naming it, so an agent can identify it precisely.

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?

"Use this when someone shares a link to a 3D model" gives an explicit trigger condition, and the closing sentence handles the when-not case (non-model links require rights confirmation). It does not name alternative sibling tools for other quoting paths (e.g. get_print_quote, update_print_quote), so it stops short of full routing guidance.

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 only establish that this is a safe, non-destructive read; the description goes well beyond them by disclosing the return shape (fits ranked best-first, plain-word reasons, ruled-out materials and why) and two real behavioral limits: it does not rank by strength/stiffness, and safety-critical parts are escalated to a human. That escalation behavior is exactly the kind of thing an agent could not infer from schema or annotations.

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?

Three sentences, front-loaded with the usage trigger, then the return contract, then the boundaries. Every sentence adds information an agent needs and none is redundant with structured fields.

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 an output schema present the description need not explain return values, yet it still summarizes the ranked/reasons/ruled-out shape and the human-escalation rule. Combined with the annotations and fully documented enums, an agent has everything needed to call and interpret this tool; the only unmentioned detail is that all parameters are optional, which is evident from the schema.

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% with all seven enums documented, including defaults, so the schema carries the parameter burden and a 3 baseline applies. The description restates the criteria categories but adds no format, precedence, or interaction guidance (e.g., how conflicting criteria are resolved) beyond 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?

States a specific verb and resource ('recommend which of our plastics suits a part') and immediately scopes it to selection-by-requirements, which separates it from list_materials. The description also names the ordering and the rationale output, so an agent knows exactly what kind of answer to expect.

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 opening 'Use this when someone wants help choosing which of our plastics suits a part' gives clear trigger conditions, and the enumerated criteria (indoor/outdoor, heat, impact, flexing, chemicals, looks, cost) tell the agent what inputs matter. It does not name an alternative sibling (e.g., list_materials for a plain catalogue) or state exclusions as routing advice, so it stops short of a 5.

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 only say readOnlyHint=false with no destructiveness, which leaves the write semantics ambiguous. The description resolves this by stating it takes no payment and does not change the earlier order, and by describing the internal steps (estimate each part from saved files, return a private link). That is meaningful behavioral context beyond the structured fields.

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 trigger sentence, then what it takes, what it does, and its side-effect boundary. Four sentences are all load-bearing, though the workflow sentence could be tightened slightly.

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?

Output schema exists, so the returned private link need not be elaborated further. With annotations, a single 100%-documented parameter, and no nested objects, the description covers when to use it, what it consumes, what it produces, and its non-side-effects — 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?

Schema coverage is 100% and the schema already documents order_link including its source emails. The description restates the same idea ("private order link from their order email") without adding format, validation, or failure-mode detail, so the baseline 3 applies.

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?

Specific verb+resource+scope: it reorders parts from an *earlier* order, using saved files, and returns a review/order link. That scope implicitly separates it from quote_from_link and get_print_quote, but no sibling is named explicitly, so it falls just short of the top tier.

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?

"Use this when someone wants the same parts again from an earlier 3D Printer on Demand order" gives a clear trigger condition. There is no explicit when-not guidance or named alternative (e.g., if the user has no earlier order, use quote_from_link instead), which keeps it out of the 5 band.

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 establish the read-only, non-destructive profile, so the bar is lower. The description still adds meaningful context: output is source-attributed published guidance plus a test method, and it proactively discloses a limitation ('no single universal hole offset, because none is published'), which prevents the agent from overpromising.

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?

Three sentences, zero waste, and the usage trigger is front-loaded ahead of the return and limitation notes. Every sentence carries a distinct piece of information.

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 an output schema present, the description need not explain return values, and it still covers usage trigger, output nature, and an explicit limitation. Nothing an agent needs to select or call the tool 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?

Schema description coverage is 100%, so the schema already documents fit_type, hole_axis and hole_diameter_mm. The description's scenario list loosely maps to the fit_type enum values but adds no format or syntax detail beyond the schema, matching the baseline 3.

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 pairs a specific verb and resource ('size a printed hole or fit') with an enumeration of the exact scenarios it handles (sliding, bolt/pin clearance, mating, press, snap). It also states plainly what it returns (published starting clearances and hole guidance with sources), letting an agent distinguish it from generic siblings like get_design_guidance.

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 an explicit usage trigger ('Use this when someone asks what clearance or hole size to draw') followed by concrete scenario examples. It does not name alternatives such as get_design_guidance or state when-not-to-use, so it stops short of a full routing rule.

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 only declare the generic write/non-destructive/non-open-world profile. The description adds real behavior: the estimate is recomputed from the file saved with the original quote (no re-upload), the result is persisted, a new private link is issued, and the earlier link keeps serving the earlier quote. The last point is a non-obvious versioning guarantee the agent cannot infer from annotations.

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 sentences, all load-bearing, with the trigger condition front-loaded before the mechanics and the exclusions. No restatement of the title and no filler.

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 mutation tool with an output schema already covering return shape, the description supplies everything else: the eligibility condition, what is and is not accepted, the recompute-from-saved-file behavior, and the link-versioning outcome. 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?

Schema coverage is 100%, so per-parameter text is already handled and the baseline is 3. The description adds provenance semantics the schema does not stress — the link must come from one of our quotes — and clarifies that color changes apply to the same material. Small but genuine value over 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?

States a specific verb and resource ('Update a 3D print quote') and immediately narrows scope to changing quantity or color on a quote that already exists. An agent can distinguish this from get_print_quote (create a new quote) without opening either 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?

Explicit trigger ('when someone wants a different quantity or color on a quote... already gave them') plus explicit exclusions: no new file, no different material, no link that did not come from one of our quotes. The negatives route the agent away from unsupported requests instead of leaving it to guess.

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