PrintPal

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds real context by disclosing the built-in density table (PLA, PETG, ABS, ASA, TPU, Nylon, PC, CF blends) and that leftover estimation works from gross spool weight. It does not explain what happens when both grams and meters are supplied, which is the one behavioral ambiguity.

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 tight sentences, capability list front-loaded and the invocation constraint placed last where it is easy to find. The material enumeration is long but load-bearing; nothing is redundant padding.

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 9-parameter tool at 44% schema coverage with no output schema, the description covers the main conversion/cost/spool use cases but leaves the spool-weight parameter interplay and the return shape unspecified. Adequate but with clear gaps an agent must resolve by trial.

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 44%, so the description must compensate, and it does clarify the grams/meters either-or that the schema leaves unstated (0 required params). However, the spool parameters (spool_weight_kg, empty_spool_weight_grams, spool_gross_weight_grams) and how cost is derived from spool_price_usd are never explained in prose.

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 concrete verbs and resources: grams→metres conversion, volume, cost, and remaining-on-spool estimation, with the material density set named. It is clearly distinct from calculate_layer_heights and calculate_volumetric_flow, though it never addresses overlap with the sibling calculate_print_cost, which also computes cost.

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 closing line 'Give either `grams` or `meters`' tells the agent how to invoke it, but there is no guidance on when to pick this tool over calculate_print_cost or the other calculate_* siblings, and no mention of which inputs are mutually exclusive versus combinable.

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, non-destructive and closed-world, so the safety profile is fully covered for a pure computation. The description adds domain context (the "magic number" concept, default kinematics, and output "filtered to what suits the nozzle") but no return format 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?

Two sentences, front-loaded with the verb and resource followed by a parenthetical default example. Tight and purposeful, with 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 six-parameter calculator with no output schema and no parameter descriptions in the schema, the description is adequate but not complete: it omits the max_layer_height_mm parameter and says nothing about the shape of the returned layer-height list, which the agent would need to use 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 description coverage is 0%, so the description must carry parameter meaning; it covers step angle, microstepping, and lead-screw pitch/starts and even echoes the default values (1.8°, 1/16, T8 2 mm × 4 starts). However, nozzle_diameter_mm is only hinted at ("filtered to what suits the nozzle") and max_layer_height_mm is never mentioned, leaving one of six parameters undocumented.

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 gives a specific verb ("Compute") and resource ("Z-axis magic number layer heights for a printer") and enumerates the driving inputs. It is clearly distinguishable from the calculate_filament_usage / print_cost / volumetric_flow siblings by resource, though it never names an alternative explicitly.

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?

Usage is implied by the domain (feed in printer kinematics, get layer heights) and the default set signals a common Ender/Prusa scenario, but there is no explicit when-to-use or when-not-to-use guidance relative to the sibling calculators. Meets the minimum-viable bar without routing help.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: what the computation includes (failure allowance, machine wear) and which defaults are applied (1 kg spool at $20, 120 W, $0.12/kWh, 5% failures), which tells the agent the output is deterministic and assumption-driven.

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 dense sentences, front-loaded with the purpose and followed by the input requirements and default assumptions. No filler, though the parenthetical cost-component list is somewhat long.

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-parameter tool with no output schema and low schema coverage, the description covers the essentials (what it computes, required inputs, key defaults) but omits the remaining parameters and gives no indication of the shape of the returned cost/selling-price breakdown. Adequate but with visible 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 38% across 13 parameters. The description usefully explains the roles of the required weight/time inputs and enumerates key default values (spool price, printer power, electricity rate, failure rate), compensating partially. But it leaves quantity, markup_percent, printer_cost_usd, lifespan, and labor_rate undocumented in either place.

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 ('Estimate') and resource ('FDM print costs'), with an explicit breakdown of the cost components (material, electricity, machine wear, labor, failure allowance) plus selling price. This clearly distinguishes it from siblings like calculate_filament_usage or calculate_volumetric_flow, which compute a single quantity rather than a full cost 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?

Explains the context of use by naming the two required slicer-derived inputs and reassuring that everything else defaults sensibly. It does not, however, explicitly route the agent away from sibling calculators or state when a cost estimate is preferred over a filament estimate.

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 this a safe, idempotent, non-destructive read. The description adds real behavioral context beyond that: the computation performed and the fact that the result is a comparison against the hotend limit plus a maximum safe speed, which is effectively return-value behavior for a tool with no output 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 compact sentences, front-loaded with the purpose and formula, with the accepted preset list trailing usefully. The preset enumeration with an ellipsis is slightly loose but not wasteful.

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 5-parameter tool with no output schema and low schema coverage, the description covers purpose and computation but not validation rules, units, or the precise shape of the result (single flow number vs. a max-speed recommendation). Adequate but with clear 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 20% (just the hotend enum), so the description must compensate. It does clarify that line width and layer height feed the flow formula and that max_volumetric_flow_mm3_s is an alternative to a preset, but it leaves units and the interaction of the two mutually exclusive flow inputs (hotend vs explicit max flow) unexplained.

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 plus the exact formula being evaluated: volumetric flow (mm³/s) = layer height × line width × speed, checked against the hotend limit. It is clearly distinguishable from siblings like calculate_filament_usage or calculate_print_cost.

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 framing 'Check whether a hotend can keep up' implies the use case, and it notes the two input modes (hotend preset name or explicit max flow). However, it gives no explicit when/when-not guidance or named alternatives among the calculator siblings, so usage must be inferred.

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, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real value beyond them: the concrete status enum (queued/processing/completed/failed) and the fact that the download URL is time-limited.

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 tight sentences that are front-loaded with the operation and its origin, followed by the return behavior. Every clause 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?

With no output schema, the description correctly carries the return-value burden by enumerating possible statuses and the download URL. It is nearly complete; minor gaps remain around failure-mode handling and how long the URL stays valid.

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 0%, so the description must compensate for the single `generation_uid` parameter. It only indirectly conveys that the uid originates from a prior `generate_3d_model` call; it gives no format, length, or validation detail, so it adds partial but not full meaning.

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 (Poll) and resource (a PrintPal AI generation) and explicitly ties itself to the sibling tool that creates the job (`generate_3d_model`). It also names the return artifact (status + download URL), so an agent can distinguish it from generate_3d_model and get_3d_model immediately.

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 clearly frames when to use it: polling a generation that was started with `generate_3d_model` in API-key mode. It stops short of naming exclusions or an alternative retrieval tool (e.g., get_3d_model), so the routing is clear but not fully disambiguated.

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?

With readOnlyHint and idempotentHint already declared, the description carries less burden, but it adds genuinely useful behavior: this tool does not generate the model itself — it rewrites the user's description into a precise CAD brief and 'returns the link; the user clicks it to generate.' That handoff (tool call produces a brief, generation is a separate user click) is important context beyond the annotations. It omits what the returned brief looks like in detail and any failure modes, so not 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 applicability condition and use-case examples before the mechanics. Dense but each sentence earns its place; the middle sentence listing agent capabilities (sliders, preview, export) is slightly promotional rather than decision-relevant.

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, and the description correctly discloses what the call returns (a link/brief) and that generation happens after a user click, which is the critical unknown for this tool. It is nearly complete; the only gap is any indication of what the brief contains or how long the link remains valid.

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 75%, so the schema already documents material, dimensions, description, and the export_format enum. The description reinforces semantics ('dimensions, tolerances, mounting, print orientation' and 'STL/3MF/STEP') but adds no syntax or format detail beyond the existing field descriptions, and notably omits that 'scad' is also a valid export value. Baseline 3 fits.

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 action and resource ('open PrintPal's AI CAD agent with a ready-to-run brief') and scopes it to 'mechanical / functional parts with exact dimensions' with concrete examples (brackets, enclosures, adapters, gears). It implicitly separates itself from the more generic generate_3d_model sibling, but never names an alternative explicitly, so it stops 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?

It gives clear selection context — use this for mechanical/functional parts requiring exact dimensions — which is actionable for an agent choosing among CAD siblings. It does not state when NOT to use it or name the fallback tool for organic/artistic models, so it lacks 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 readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds a characterization of the payload (full article body, transcript, build steps, BOM, model files, canonical URL), but since an output schema exists this is largely duplicative rather than new behavioral context.

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 action and then the id forms; nothing is padding. The long parenthetical prefix list is dense but each entry is functional.

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 tool with an output schema and full annotation coverage, the description supplies everything needed to invoke it correctly. The only gap is the unaddressed boundary against overlapping siblings such as `get_3d_model` and `get_build_guide`.

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 single `id` parameter is documented, so baseline is 3. The description goes beyond the schema's single `wiki:` example by enumerating all valid id prefixes, giving the agent concrete input format knowledge the schema does not spell out.

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 (fetch) and resource (the full content of a PrintPal item), and ties itself to the `search` sibling that produces the id. The enumerated id prefixes (`model:`, `tool:`, `wiki:`, etc.) make the scope of items unambiguous.

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 frames the workflow: call this after `search` to get an item's full content, and lists accepted id forms. It does not, however, say when to prefer this over the more specific siblings like `get_3d_model` or `get_build_guide`, whose scope appears to overlap for model/build content.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only 'Returns matching tools with links' plus the empty-task listing behavior; it says nothing about match quality, ranking, or what happens when nothing matches. Modest added value against an already-complete annotation set.

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 purpose is front-loaded in the first clause, followed by a dense semicolon-delimited catalog and two short operational sentences. The enumeration is long but each item is plausibly load-bearing for semantic matching in a finder tool. Slightly wall-of-text, but no sentence is pure 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?

With no output schema, the description correctly states the return shape ('matching tools with links') and covers the empty-input edge case. The only gap is the undocumented 'limit' parameter, which the schema bounds but does not explain. Otherwise complete for a zero-required-parameter discovery 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?

Schema coverage is 50%: 'task' is documented in the schema, 'limit' is not documented anywhere. The description compensates partially by defining the empty-task semantics of 'task', which the schema does not state, but it never mentions 'limit', its default of 6, or its 1-50 range. Baseline 3 is appropriate.

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: 'Recommend the right free PrintPal browser tool for a task', then enumerates the covered categories (calculators, generators, mesh utilities, AI generators). An agent can tell it is a catalog/finder rather than a computation. It never names the sibling calculators it overlaps with (calculate_print_cost, calculate_layer_heights, calculate_volumetric_flow), so routing between this and those is left to inference.

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?

One concrete usage rule is given: 'Pass an empty task to list every tool.' Beyond that there is no when-to-use versus the sibling calculator tools, and no guidance on when a specific calculator is preferable to this finder. Usage is implied rather than stated.

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 give generic hints (readOnlyHint=false, openWorldHint=true, non-idempotent), but the description goes well beyond them: it discloses that without an API key nothing is generated until the user clicks, that API-key mode spends the caller's credits, the required `Authorization: Bearer pp_live_…` header, and the returned `generation_uid`. No contradiction with 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 dense sentences, all front-loaded: capability first, then the two modes, then the routing to the parametric CAD sibling. Every clause carries decision-relevant information (auth, credits, return shape, domain of suitability) with 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 generative, side-effecting tool with no output schema, the description covers what an agent needs: input modes, auth requirements, credit consumption, the concrete return value, and how to poll the result. Nothing material 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 already 75% and covers `prompt` and `quality`. The description adds genuinely new semantics by restricting `image_url` to API-key mode and clarifying that the tool accepts either text or image input. It doesn't discuss `format` values or the cost tiers of `quality`, so not a 5.

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 ('Turn a text prompt or an image into a print-ready 3D mesh') and names the output geometry formats (STL/GLB/OBJ). It explicitly distinguishes itself from the sibling `design_parametric_cad` for exact-dimension mechanical parts, and names `check_3d_generation` as the follow-up tool.

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 when-to-use routing: text/image-to-3D here vs. `design_parametric_cad` for dimensioned parts. It also spells out the two operating modes (no API key = prefilled link only; API key = real job submitted and credits spent) and the condition that selects each.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds value beyond that by disclosing the return payload (stats, license, formats, download URL), which matters because no output schema exists.

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, zero filler: the resource and scope lead, the returned fields follow, and the accepted input forms close. Every clause carries information an agent needs.

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 read tool with rich annotations, the description covers identity, input source, and return contents adequately even without an output schema. It does not say what happens on an unknown uid, which is the only meaningful remaining gap.

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 single parameter's schema description already states both accepted forms (search-result uid or printpal.io/model/<uid> URL). The description restates the same accepted input without adding format, validation, or error semantics, 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 ('Get full details for one PrintPal model by uid') and enumerates exactly what comes back: description, license, file formats, author, stats, download URL. It also distinguishes itself from the sibling search_3d_models by naming it as the source of the uid, so an agent can route between search and fetch without opening schemas.

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 clearly establishes the usage context — the uid comes from `search_3d_models` results or a printpal.io/model/<uid> URL — which tells the agent this is the detail-fetch step following a search. It stops short of an explicit 'do not use this for searching' exclusion, but the workflow position is unambiguous.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context by itemizing what the guide contains (BOM quantities, downloadable STL/3MF/code, step-by-step content), which helps an agent know the return payload.

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, zero filler, with the resource and its contents front-loaded before the usage trigger. Every clause 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?

With no output schema, the description compensates by enumerating the returned sections, and the single required parameter is fully documented in the schema. An agent has everything needed to select and invoke 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 coverage is 100% and the slug parameter already documents its source (search results or printpal.io/projects/<slug> URL). The description adds only 'by slug', so the schema does the heavy lifting and 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 ('Read a full PrintPal build guide by slug') and enumerates the payload: summary, BOM with quantities/links, downloadable files, steps, callouts, code blocks. It clearly reads one full guide rather than searching, but it never names search_build_guides as the sibling it differs from.

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 when the user wants to actually follow or adapt a project' gives a clear usage condition that separates it from the search/list tools. No explicit when-not or named alternative, but the intent trigger is unambiguous.

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, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds value beyond them by disclosing response content — it returns sign-up, credit-purchase, and subscription links — which tells the agent this is an informational lookup with actionable URLs.

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 filler. The topical scope is front-loaded in the first sentence and the invocation condition is clearly deferred to the second.

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 parameterless, no-output-schema info tool governed by read-only annotations, the description covers what it explains, what it returns (links), and when to call it. 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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline 4 applies. The description correctly does not invent parameter guidance for a parameterless tool.

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 clear verb ('Explain') and enumerates the exact resource coverage: free tier, AI generation credits, CAD agent pricing, API access, and the on-demand 3D printing service. This is easily distinguished from sibling cost calculators like calculate_print_cost, which compute a specific print's cost rather than explaining pricing structures.

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 condition: 'Call when the user asks about cost, limits, subscriptions or how to get more generations.' That maps user intent to this tool directly. It doesn't name a sibling alternative (e.g., calculate_print_cost for a concrete quote), which is the only missing piece for 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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful behavioral context by noting that results are ids accepted by `fetch` for full content, which helps the agent chain tools correctly.

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 with no waste: scope first, return linkage second, usage examples third. Everything is front-loaded and 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 explained here. Combined with rich annotations, the description fully covers scope, content types, query style, and the fetch linkage an agent needs to use the tool 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?

The single parameter has 100% schema description coverage, so the baseline would be 3. The description adds value by supplying example natural-language queries such as 'PETG temperature', which clarifies the expected query style beyond the schema's generic 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?

The description states a specific verb (search) and resource (everything on PrintPal), then enumerates the content types covered. This clearly distinguishes it from narrower sibling tools like search_3d_models and search_build_guides.

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 provides clear context by saying the tool is 'suited to general 3D printing questions' and gives three concrete examples. However, it does not explicitly state when to prefer a narrower sibling search tool or when not to use this one.

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, so the safety profile is covered. The description adds genuine context beyond that: what a result card contains (thumbnail, author, tags, likes) and that files are downloaded from the linked model page rather than returned directly. It does not mention paging behavior for the limit parameter, leaving one modest 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?

Three sentences, zero waste: purpose and scope first, return contents second, tool routing last. The examples are compact and functional rather than 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?

An output schema exists so return values need no further explanation, and annotations cover safety. The description still supplies the corpus boundary, the download-path caveat, and sibling routing, making it nearly complete; only the limit/paging behavior is unaddressed.

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 schema coverage at 67%, query and category are already documented in the schema. The description contributes useful example queries ('articulated dragon', 'headphone stand') that clarify phrasing, but says nothing about limit or the category enum, so it adds only marginal value over the structured fields.

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 precise verb and resource (find printable 3D models by keyword) plus supported file formats (STL/3MF/OBJ) and the specific corpus (PrintPal community library). It also explicitly differentiates itself from the two sibling generation tools, so an agent can route correctly 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 an explicit boundary: 'Searches existing uploads only', then names the alternatives (generate_3d_model for AI mesh, design_parametric_cad for exact dimensions) and the condition that selects them. This is a full when/when-not/alternative mapping.

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, closed-world behavior, so the bar is lower. The description adds useful non-annotated context: each result carries difficulty, time, cost, and part/file/step counts, which tells the agent what the payload looks like. No pagination or result-count behavior beyond the default limit, though.

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 dense sentences: the first front-loads what the tool returns and over what domain, the second covers filtering and the empty-query case. No filler, no 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?

With no output schema, the description correctly takes on describing the result shape (difficulty, time, cost, counts) and enumerates the filter vocabularies. It is nearly complete except for sort/limit behavior on a five-parameter 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?

Schema description coverage is only 20% (just 'category'), so the description compensates by enumerating all seven category slugs and the three difficulty values, plus the empty-query browse behavior. It leaves sort and limit semantics unexplained, which remains a 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?

Specific verb (Find) plus the exact resource (PrintPal step-by-step build guides) and its scope (Arduino/ESP32 electronics, 3D-printed enclosures, robots, props, etc.). This clearly separates it from siblings like search_3d_models, search_learning_resources, and get_build_guide.

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 selection conditions: filter by category or difficulty, and 'leave query empty to browse featured guides.' However, it never names the alternatives (search_learning_resources, search_3d_models, get_build_guide) or states when to prefer this tool over them.

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, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral value by disclosing the content corpus scope and, with no output schema present, that results carry ids consumable by `fetch`; it omits pagination/ranking behavior and the 25-item cap.

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 tight sentences, front-loaded with the content scope before the `type` and `fetch` guidance. The parenthetical list is dense but every item earns its place by defining the corpus; no filler or restatement 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?

For a search tool with no output schema, the description covers what is searched, how to narrow it, and that ids feed `fetch`. It leaves result-shape detail (fields besides ids) and limit/pagination behavior unstated, which is a modest but real gap.

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 0%, so the description must compensate. Its content inventory implicitly maps onto the `type` enum values (wiki/docs/videos/courses) and it calls out `type` explicitly, but `limit` (1-25, default 8) and result-count behavior are unexplained beyond the raw schema constraints.

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 a precisely scoped resource (PrintPal's how-to content), then enumerates the four corpora (wiki, docs, videos, courses). This clearly separates it from siblings like search_3d_models, search_build_guides, and the generic search 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 implied usage ('Use `type` to narrow') and a downstream routing hint ('ids accepted by `fetch`'), which tells the agent what to do next. However it never states when to prefer this tool over the generic `search` or the other specialized search siblings, so selection guidance 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.