ply 3D Printing

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description focuses on value-add: license filtering on Printables and pre-scaling on Poly Haven results. It doesn't mention result limits or ranking 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?

One compact sentence plus a return-value clause, front-loaded with the action. Minor typo ('ply may print') and the parenthetical license note brush up against density, 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?

With no output schema, the description explicitly enumerates returned fields (titles, designers, licenses, page links), which is exactly what an agent needs to use results. Sources and filtering semantics are also covered.

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?

Single parameter with 100% schema coverage including an example, so the schema does the work. The description adds nothing about query syntax or matching behavior, so the baseline of 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 (Search) and resource (ready-made 3D models) and names the two sources (Printables, Poly Haven). It also states an exclusion (non-commercial models left out), which sharply separates it from siblings like make_part or list_materials.

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?

Makes the selection condition clear: use this when you need ready-made models you may print and sell, with commercial licensing enforced. It does not name a sibling tool as an alternative, which is the only missing piece.

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, idempotentHint and openWorldHint=false, so the safety profile is fully covered and the description carries a low bar. It adds value by disclosing the shape of the payload — colors, strength levels, and per-material suitability notes — but says nothing about how many materials exist or how the suitability text is presented. Annotations mean a 3 is an adequate bar here.

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?

A single compact sentence with no filler, and the most useful clause (what each material is good for) is retained. It is slightly awkward as a fragment — a leading verb such as 'Lists' would front-load the action more clearly — 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 zero-parameter, read-only catalog with no output schema and no nested objects, the main missing piece is a sense of what the return values look like. The description covers that in prose (materials, colors, strength levels, suitability). Only the routing to recommend_material and any indication of result size are absent.

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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument catalog call and does not introduce any parameter confusion.

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 sentence identifies the resource precisely — materials, colors, strength levels — and adds that it explains what each material is good for, which goes beyond the title. It is a noun phrase rather than a verb-led statement, so the listing action is inferred from the name, but the resource is unambiguous. It does not differentiate from recommend_material.

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?

There is no statement of when to use this catalog versus recommend_material, which is the obvious sibling for material selection. No prerequisites, no call-order guidance (e.g., call this before make_part), and no exclusions.

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 that this is a read-only, idempotent, non-destructive operation. The description adds relevant behavior beyond that: it previews the part in 3D, shows pricing and an Order button, applies sensible defaults, and supports re-running with changed inputs. It does not directly contradict the read-only annotation because it describes a preview rather than placing an order.

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 four front-loaded sentences with no obvious filler. It moves from purpose to output preview to default behavior to reuse pattern efficiently.

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 29-parameter tool with full schema coverage but no output schema, the description supplies the missing high-level return context: a 3D preview with price and Order button. It also covers defaults and reuse, though it does not elaborate on pricing rules or validation behavior.

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 schema already documents all 29 parameters with template-specific meanings. The description adds only high-level context such as exact sizes being in mm, template names, and defaults for omitted values, so it is at the baseline for a fully documented 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 bundle (build/check/price) and resource (custom 3D-printed part from exact mm sizes), and enumerates the supported templates. This is clearly distinct from sibling pricing tools for existing files/models and from order_part.

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 gives useful context that it should be reused when the customer asks for size or option changes, and that omitted sizes use defaults. However, it does not explicitly state when to use this versus price_file, price_model_link, recommend_material, or order_part.

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 say this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds meaningful behavioral context that annotations do not: no charge occurs here, the output is a completion link, and final steps happen on plyparts.com. It could be stronger by warning that repeated calls may create duplicate carts, 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?

The description is two tight sentences, front-loading the core action and the no-charge caveat. Every sentence adds useful information and there is 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 complex ordering tool with 36 optional parameters and no output schema, the description explains the return link and the two input modes. It still leaves unclear which parameter combinations are required for each template or file mode, which is a meaningful gap for correct invocation despite the rich schema descriptions.

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 97%, so the schema already explains nearly every one of the 36 parameters in detail. The description only broadly groups inputs into built-part mode (template, sizes, options) and file mode (path, options), which is useful but adds limited per-parameter meaning 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?

The description states a specific verb and resource: putting a part into a ply cart and returning a link to finish the order on plyparts.com. It distinguishes two input modes (built part vs file), which helps separate it from make_part and price_file, but it does not explicitly name or contrast those siblings.

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 usage context for built parts versus files, and clarifies that shipping, payment, and engineer review happen later. However, it does not say when to use this tool instead of price_file, make_part, or price_model_link, nor does it state prerequisites such as needing a ply path from price_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?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioral context the annotations can't: this renders a card in the UI, degrades to an upload button when no file exists, and supports re-pricing via `path`. It doesn't say what the card shows or whether pricing is persisted/reusable beyond the `path` hint.

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 compact sentences, front-loaded with the primary action, then the no-file fallback, then the host-specific and re-pricing cases. No filler, though the parenthetical sourceUrl aside is slightly parenthetical-heavy.

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 13-param, schema-rich, annotation-covered tool with no output schema, the description covers the main flows (new file, no file, re-price). It omits what the resulting card/quote actually contains, which matters since there is no 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?

Schema coverage is 100% and the schema already explains `path`, `units` (including the '25x too small' heuristic), `sourceUrl` and the enums. The description repeats the `path` and `sourceUrl` semantics rather than adding new meaning, so baseline 3 applies for a fully documented 13-param 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 ('Price the customer's 3D file') and enumerates supported formats. It does not explicitly distinguish itself from price_model_link, whose territory the sourceUrl sentence brushes against, so it falls short of a 5.

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 concrete routing: no file → show upload card with sourceUrl; ChatGPT → pass the attached file; existing priced file → pass `path` to change options. It never says when to use price_model_link or make_part instead, so it stops short of explicit alternatives.

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 read-only, idempotent, open-world behavior, yet the description adds substantial context: license gating (CC0/CC BY/CC BY-SA/GPL/Commercial vs declined with reason), designer crediting, auto-scaling to 150 mm, and file-listing when a model has multiple files. This is exactly the extra context 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?

Organized by site (Printables, Poly Haven, other), which front-loads the decision-relevant branching. It is on the longer side, but nearly every clause carries conditional information an agent needs; the closing sentence on `file` is well placed.

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 carries the result burden; it does state that the result appears in ply's card and whether the file is fetched or linked. It could say more about what 'priced' means numerically (cost estimate, time), but for this tool the site-branching coverage is the core need and it is complete.

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, but the description adds real meaning: `file` is only relevant when a Printables model has several files, and `sizeMm` is scoped to Poly Haven with a 150 mm default longest-side behavior. That enriches the schema's bare 'up to 250' note.

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 ('Price a 3D model from its page link') and names the surface where the result lands ('ply's card'). Clearly distinguishable from siblings like price_file or find_models without opening any 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 explicit conditional guidance per source site: Printables fetches automatically when the license permits, Poly Haven is fetched and scaled, other sites require a manual upload. It lacks an explicit routing sentence versus price_file or make_part, which is the only gap.

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, idempotent, non-destructive and closed-world, so safety needs no elaboration. The description adds genuinely non-obvious behavior: the advisor may ask up to 2 clarifying questions, implying a multi-turn flow that the agent must handle by returning with `answers` — context an agent could not get from annotations or schema.

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 with no filler. The core action and its output are front-loaded, and the input-mode constraint follows immediately after, so an agent reads the essential facts in the first pass.

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 29-parameter tool with no output schema, the description still communicates what comes back (process, material, color, strength) and how the interaction may loop, which is the critical missing context. The remaining gap is that it does not indicate what the response looks like structurally when answers are needed versus when a recommendation is returned.

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 every parameter is already documented and the baseline is 3. The description does add structural meaning by framing the two input families (path vs. template+sizes) and by explaining that earlier Q&A is passed back, but it does not clarify how the template-scoped parameters group together beyond what per-property descriptions already say.

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 ("Run ply's material advisor for a part") and names the concrete output of the tool: a recommended process, material, color and strength. It also anchors the tool to a known surface ("Help me choose" on plyparts.com), which clearly separates it from siblings like list_materials or price_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?

The description distinguishes the two valid invocation modes — a file `path` or a template plus sizes for a built part — which effectively says when each input shape applies. However, it never says when to prefer this tool over alternatives such as list_materials or make_part, so routing between siblings is left to inference.

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