FabTally 3D-Print Slicer, Quote & DFM

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

With no annotations the description carries the full burden, and it does substantial work: geometry-only, uncapped, free, accepted formats, zip-unpacking behaviour, and which hosts (Thingiverse/Printables/MakerWorld) block server downloads. It also warns that inline base64 can silently truncate. It stops short of stating error behaviour or any data-handling/retention facts for uploaded files.

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 capability list, then handles input logistics in a compact run of sentences; each clause carries information. There is some duplication between the description and the schema's model_url/model_base64 text, and the all-caps 'FREE' framing is promotional 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 4-param tool with no annotations and no output schema, the description supplies the output metrics, input formats, retrieval constraints and size caveats an agent needs to call it correctly. Remaining gaps are error/edge-case behaviour and file-size expectations for the base64 fallback.

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 (including the unmentioned 'printer') is already documented. The description reinforces model_url as PREFERRED and repeats the upload workflow, but adds little semantic detail beyond the schema's own text. Baseline 3 is correct 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+resource ('3D-model analysis') and enumerates the concrete outputs (bounding box, volume, triangle count, watertight/manifold, solidity). The 'general, beyond printing' framing cleanly distinguishes it from the printing-oriented siblings like analyze_model and check_printability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear use contexts (game-asset QC, AR/VR optimisation, marketplace upload validation, engineering sanity checks) that justify reaching for this tool over a print-focused one. It never names the sibling tools or states when to prefer analyze_model/validate_model instead, so the routing guidance is implied rather than explicit.

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 no annotations, the description carries the full burden and does so well: it labels the call FREE, enumerates the heuristic outputs, and discloses non-obvious behaviors not present in structured data (zip handling uses 'first printable model inside', server fetch is blocked by certain marketplaces, MCP clients can silently truncate base64 payloads). This is behavioral context beyond the schema, not a restatement of it.

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?

Purpose and the output inventory are front-loaded, and every sentence is on-topic. It loses a point for redundancy: the long 'paste a link' passage repeats the model_url model description almost verbatim, so a chunk of the text does not earn new 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?

There is no output schema and no annotations, yet the description enumerates the return values, states the cost profile (FREE), covers the input-source edge cases and the base64 size limit, and routes to the right siblings. 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 description coverage is 100%, so every parameter (printer, material, filename, model_url, model_base64) is already documented with enums, defaults, and formats. The description's URL/upload guidance largely duplicates the schema's own model_url and model_base64 text, adding little beyond the documented baseline.

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 with concrete outputs: 'geometry sanity check' returning bounding box (mm), volume (cm3), triangle count, watertight/manifold flag, fits-on-bed, and a printable verdict. It explicitly distinguishes itself from the near-identical sibling analyze_3d_model ('general, non-printing framing') so the agent can pick between the two.

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 positive routing ('Great pre-flight before get_print_quote') and names the alternative with the condition that selects it ('See analyze_3d_model for a general, non-printing framing'). It also spells out the source-specific conditions (Thingiverse/Printables/MakerWorld block server downloads; local files must be uploaded first), covering how to invoke as well as when.

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 no annotations, the description carries the full burden and does so well: it discloses the cost model (free for personal/interactive use, fair-use limits, prepaid credits or x402 for agents/high-volume), the heuristic-vs-exact labelling of every field, the 0.4mm-nozzle assumption behind wall-thickness estimates, and the silent-truncation risk of inline base64 arguments. This is well beyond what any structured field provides.

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 tool's identity and cost, then input handling, then the full=false/true semantics. It is dense but nearly every clause is actionable; the only real redundancy is restating the model_url sourcing rules that already appear verbatim in the schema.

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, no-output-schema, no-annotation tool, the description covers what the call returns (verdict, watertight/manifold, dimensions, bed fit, wall thickness, overhang) and the cost/limit model, which is what an agent needs before spending credits. It stops short of noting that the tool is side-effect-free and gives no rate-limit specifics.

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 all 9 parameters (defaults, enums, ranges, printer/material ids). The description largely repeats this (model_url sourcing, base64 size caveat, quality presets, nozzle assumption) rather than adding new syntax or constraints, so the 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 and resource: a free DFM/printability check on an STL/3MF/OBJ/PLY model, and explains the two operating modes (fast geometry read vs full slice report) so the agent knows what the call produces. It does not, however, explicitly distinguish itself from close siblings like validate_model, analyze_3d_model, or slice_model, whose overlap is left for the agent to infer.

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 clear input-sourcing guidance (GitHub/Drive/Dropbox links, direct file URLs, .zip handling, the Thingiverse/Printables/MakerWorld blocking caveat, and the upload workaround) and explains when to set full=true vs the default. But it never states when to prefer check_printability over sibling tools such as validate_model or slice_model, so the routing guidance an agent most needs is absent.

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?

No annotations are provided, so the description carries the full burden and does well: it flags the fair-use limit (one slice per printer), the FREE cost, server-side fetch/unpack behavior, and host download blocking. It omits auth requirements and failure/error behavior, so it is not complete enough for 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?

Front-loads 'FREE' and the core outcome before secondary input logistics. It is dense but largely earns its lines; the URL-type enumeration is partially duplicated in the schema descriptions, which is mild 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?

With no output schema and no annotations, the description compensates by describing the returned table columns and best-pick outputs, plus input logistics for a 17-parameter tool. It lacks auth/permission and error-handling context, leaving a modest 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 100%, so the schema already documents all 17 parameters; the description only re-states the model-input channel (URL vs base64 vs upload) that the schema's model_url/model_base64 descriptions already carry, and restates the max-6 printer limit. 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 (slice/compare) and resource (the same model across several printers), and enumerates the concrete output: print time, filament, cost, fits-on-bed, cheapest and fastest picks. This clearly distinguishes it from sibling slice_model, which operates on one printer.

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?

Names the triggering question ('which of my printers should I use?') and routes the agent through input-source choices (URL types, upload fallback), with explicit guidance on blocked hosts. It stops short of naming sibling alternatives like slice_model or list_printers for the single-printer or enumeration case.

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 no annotations, the description carries the full burden and does well: it declares FREE, fair-use limits (one slice), that the server fetches and unpacks archives, that some hosts block server downloads, and that inline base64 can silently corrupt. It omits auth requirements and any rate-limit specifics beyond 'fair-use'.

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 purpose and 'FREE' well, but the entire 'Paste a link... download the file yourself... paste that URL' passage repeats the model_url schema description verbatim, adding length without new information. The margin/setup/currency framing sentence is a tighter, more useful summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, no-output-schema tool, the description names the four output components (material, machine-time, setup, margin) and covers input sourcing fallbacks, which is enough for correct invocation. Only auth/rate-limit expectations and the returned shape of the breakdown remain unstated.

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 all 15 parameters including BYO pricing fields, enum values, and defaults. The description's URL guidance duplicates the model_url description almost verbatim and adds no new parameter semantics, so 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: 'Break a quote into material vs machine-time vs setup vs margin', which tells an agent exactly what output it produces. It does not name or differentiate against the closest sibling, get_print_quote, so an agent must infer the split between quoting and breaking down an existing 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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance despite 13 siblings, including get_print_quote and compare_printers. The only context ('FREE', 'Fair-use limited (one slice)') is a constraint, not a selection criterion.

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 no annotations, the description carries the full burden and discloses a lot: it is free, has fair-use limits, what the response contains (print time, filament grams, priced quote with material + machine time + setup and automatic volume discounts), that a pricing_basis is echoed, and that currency is a label only with no conversion. It also warns about a real failure mode (large inline base64 args getting truncated by MCP clients).

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 'FREE. Slicer-accurate...' which is good, but the input-handling guidance (link types, blocked sites, upload fallback) is duplicated almost verbatim in the model_url schema description, and the 17-parameter tool's description runs dense with little whitespace or grouping. Some of the length is earned by the input complexity, but the redundancy costs it.

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 17-parameter, zero-required, no-output-schema tool, the description covers the essentials: how to supply the model, the free/paid boundary, and what the response contains. The only real gap is that the interplay between layer_height and quality, and the interaction of quantity with minimum_price/volume discounts, is left to 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%, so the baseline is 3, but the description adds value by grouping the BYO pricing parameters coherently and noting they are all optional and that the response echoes a default-vs-custom pricing_basis. That interplay between the custom-pricing inputs and the returned basis is not stated anywhere in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get a 3D printing price quote') and immediately sharpens the scope with 'Slicer-accurate FDM price quote from a real slice (not an estimate)'. That qualifier cleanly separates it from estimate-style siblings like cost_breakdown and from model-processing siblings like slice_model or analyze_3d_model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use guidance for input paths: paste a link (with the specific accepted link/file types), and the explicit exclusion that Thingiverse/Printables/MakerWorld pages usually block server downloads so the user must download and upload instead. It also flags the free-tier boundary (personal/interactive vs high-volume/agent use via credits or x402). It does not name sibling tools as alternatives, so it falls 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?

With no annotations, the description carries the full burden and does disclose the commercially relevant behavior: personal/interactive use is FREE under fair-use limits, while agent, production and high-volume calls incur x402 or prepaid credits. That is genuine auth/payment context an agent needs before calling. It does not describe response format or whether the fleet list is live/cached beyond the word "live".

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 "FREE." and "Discovery:", then the resource inventory, then the routing instruction, then the pricing caveat. Efficient overall, though "FREE" is asserted twice (opening token and the personal-use clause), which is mild 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?

With no output schema, the description compensates by enumerating the fields returned (id, name, bed/build volume mm, nozzle) and the material set, so an agent knows what it will get. Missing only minor details such as pagination or the exact pricing figures, which the pricing model reference implies are returned rather than summarized.

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 is 4. The description still adds value by explaining that the returned printer and material ids are the inputs other tools consume, which frames the parameterless call's role in the workflow.

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/discover) and enumerates the exact resources returned: FDM printer fleet with id, name, bed volume and nozzle, 12 filament materials by name, and the pricing model. This clearly distinguishes it from siblings like compare_printers and recommend_material, which operate on the ids this tool surfaces.

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?

"Call this FIRST to pick a `printer` and `material` id" gives explicit sequencing relative to the other 13 tools, and the free-vs-paid split tells the agent when cost applies. It stops short of naming a specific alternative or a when-not-to-use condition, so it is strong context rather than 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?

With no annotations, the description carries the full burden and does add real behavioral context: free personal/interactive tier with a fair-use cap counting as ~4 slices, a 4-candidate slicing run, exact slice-derived results, filament/time savings and an estimated price, plus prepaid credits/x402 for agents. It omits runtime duration, rate-limit specifics, and error/retry behavior for a server-side fetch-and-slice job.

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 first line leads with pricing/quota rather than the purpose, and the text repeats the model_url paste-a-link guidance that already appears in the schema, plus filler like 'Reduces support waste, print time and post-processing.' The purpose is still reachable in sentence two, but there is redundancy that dilutes front-loading.

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 and no annotations, the description supplies the key return context (chosen orientation, filament/time saved, estimated price) and the cost model. It is nearly complete for an 8-param, zero-required analysis tool, missing only failure/timeout behavior and any note that all params are optional defaults.

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% with 8 well-documented params, so the schema already defines printer, quality, material, infill and the model_url/base64 options. The description mostly repeats the model_url guidance verbatim rather than adding new semantics; 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 (orientation optimiser) and a precise mechanism: it really slices up to 4 candidate build orientations with automatic supports and recommends the one using the LEAST support material. This is clearly distinguishable from siblings like slice_model, check_printability and recommend_settings, which the description implicitly does not overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: use it to reduce support waste, print time and post-processing, with fair-use limits (~4 slices) and an agent lane for high volume. However it never names a sibling or states a when-not-to-use condition versus slice_model/check_printability, so routing is left partly 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?

With no annotations, the description carries the full burden and largely meets it: it declares cost ('FREE'), a rate constraint ('Fair-use limited'), the non-obvious default behavior of slicing every candidate (quote defaults true), and real failure behavior of third-party hosts blocking server fetches. It stops short of stating side effects or auth requirements, but the disclosed behavior goes well beyond the name.

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 and the key default (quote=true) are front-loaded, and the remaining sentences cover input formats, blocked hosts, and limits without filler. It is dense but mostly single-purpose; the URL-format passage is somewhat duplicated from the model_url schema description, which is the only real 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 15-parameter tool with no annotations and no output schema, the description covers purpose, defaults, and the shape of the result (reasons plus per-candidate time/filament/cost quote). The BYO pricing family is left entirely to the schema, which is acceptable at 100% coverage, but the description never signals that a pricing-override mode 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 description coverage is 100%, so the baseline is 3. The prose restates the use_case enum and the quote default, both already in the schema, and adds a small amount of framing around model_url/model_base64. None of the seven BYO-pricing parameters are touched in the description, so it adds little beyond structured data.

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 ('Suggest the best filament(s) for a use case') plus the distinguishing output ('a real slice/quote per candidate'), which separates it from sibling quote tools. It never names a sibling it is not, so an agent must infer the boundary against recommend_settings or get_print_quote on its own.

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?

Most guidance concerns *how* to supply input (prefer model_url, paste GitHub/Drive/Dropbox/direct file links, upload local files, blocked host pages) rather than *when* to choose this tool over siblings. There is a useful workaround loop for blocked sites and local files, but no explicit when-not-to-use or comparison against recommend_settings/compare_printers. Usage is implied by the required use_case 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?

No annotations exist, so the description carries the full burden and does well: it discloses the FREE/fair-use limit, that the server fetches and unpacks archives, that Thingiverse/Printables/MakerWorld block server downloads, and that large base64 arguments get silently truncated by MCP clients. It omits what the returned slice output looks like in any detail.

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 opening sentence is well front-loaded, but the following paragraph duplicates the model_url and model_base64 schema descriptions nearly word-for-word, which is length that does not earn its place. Still readable and scannable.

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 14-parameter tool with no output schema and no annotations, the description covers input sourcing, cost/pricing intent, and hints at the return (time/filament/cost). The BYO pricing parameters are left entirely to the schema, but that schema is fully described, so the gap 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%, so every parameter including the BYO pricing fields is already documented. The link-handling paragraph in the description largely restates the model_url schema description verbatim, adding no meaning beyond structured data; 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: recommend layer height/infill/walls for a goal and then slice with those settings to show time/filament/cost. This distinguishes it in substance from slice_model and cost_breakdown, though no sibling is named explicitly, so differentiation must be inferred.

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 input routing: paste a public link, upload local files at the upload URL, or use base64 only for small files. It does not state when to prefer this tool over siblings like slice_model or optimize_orientation, but the input guidance is unusually specific.

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 no annotations, the description carries the burden and does well: it flags the service is FREE, fair-use limited, that dimensions are exact while time/filament are estimated from the volume factor off one real slice, and that zips use the first printable model. It does not explain the pricing/byo-cost behavior or what happens when required input is ambiguous.

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 value proposition and the three target modes, then the input-sourcing rules. However, the URL/upload instructions are a single dense run-on that substantially duplicates the model_url and model_base64 schema descriptions, costing some efficiency.

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 16-parameter tool with no output schema and no annotations, it covers scaling semantics, input sourcing, and accuracy expectations adequately. It leaves unclear what the response contains beyond the four named quantities and how the BYO pricing parameters alter the cost output.

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 the target syntax, printer ids, material ids, and every BYO pricing knob. The description's target-syntax restatement adds only redundancy, and it says nothing about the 10+ pricing 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 and outcome: reports new dimensions/time/filament/cost after scaling a model, and enumerates the three scaling modes (fit-bed, percent, dim:axis:mm). This is clearly distinguishable from quote/slice/analyze siblings, though it never names them 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?

Gives concrete operational guidance: paste a public link, which hosts work, that Thingiverse/Printables/MakerWorld block server downloads so you must download and re-upload, and how to handle local files. It stops short of saying when to pick this over get_print_quote or slice_model, so no exclusions or sibling routing are provided.

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?

No annotations are provided, so the description carries the full burden and does so well: it discloses fair-use limits on free metrics, the prepaid-credit draw-down semantics, the FABTALLY_API_KEY env var auth path, and the x402 pay-per-call alternative. It stops short of describing failure modes (unsupported geometry, fetch errors) or what the response looks like.

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 free/paid split, which is genuinely the most decision-relevant fact, but the payment justification ('NOT a new payment or a charge decision') is belabored and largely duplicated in the api_key and x_payment schema entries. The slicing behavior itself gets less space than the billing rationale.

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 21-parameter, zero-required tool with no output schema and no annotations, the description covers the billing model, file-input quirks, and names the free metric outputs (time, grams, layers, fits-on-bed, quote). Return-value structure and error behavior are not covered, but the core callable context is present.

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 defaults, ranges, enums, and link formats, so the description adds little parameter meaning beyond repeating the model_url link guidance. Baseline 3 per the schema-coverage rule.

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+resource ('Slice on any of the 12 FDM printers') and separates the free metrics path from the paid deliverables path. It does not name any sibling tool, so an agent must infer the boundary with get_print_quote, analyze_3d_model, or optimize_orientation on its own.

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?

Strong operational guidance: accepted link types, that Thingiverse/Printables/MakerWorld pages usually block server fetch, the upload-then-paste fallback for local files, and the explicit instruction to run normally without confirming a purchase. What is missing is when to prefer a sibling (e.g. quote-only vs. actually slicing).

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 no annotations, the description carries the full burden and does so well: it discloses cost/speed profile ('FREE, fast, uncapped'), the geometry-only limitation ('no slice'), server-side fetch and zip-unpacking behavior, that Thingiverse/Printables/MakerWorld pages are usually blocked, and the real risk that inline base64 gets silently truncated by MCP clients. It also describes the return shape (verdict + reasons + one-liner).

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 value proposition and the core checks are front-loaded in the first two sentences, which is the right ordering. The remaining length is largely justified by genuinely useful input-path guidance, though the URL/upload advice repeats the schema's model_url description almost verbatim.

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 or annotations exist, but the description covers what the tool returns (printability verdict, reasons, one-liner) and the main operational caveats. It omits failure behavior (e.g., what happens on an unreachable link or unsupported format) and any latency expectations, which would round out a no-annotation 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 100%, so the baseline is 3. The description's link-handling paragraph and base64-truncation warning duplicate what is already written in the model_url and model_base64 schema descriptions, adding rationale but no new parameter semantics.

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 names a concrete outcome ('One-shot "is this printable?"') and enumerates exactly what is checked: watertight/manifold, wall-thickness estimate, size vs bed, and a verdict with reasons. It partially differentiates from siblings by scoping to 'Geometry-only (no slice)', which separates it from slice_model, but never mentions check_printability or analyze_model, the two siblings whose names most overlap.

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 a clear use case ('is this printable?', one-shot, no slicing) and practical invocation guidance for every input path (link types, blocked hosts, zip, local upload, base64 fallback). It stops short of explicit when-not-to-use or named alternatives, so the agent must infer that heavy slicing or cost work belongs to siblings.

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 no annotations, the description carries the full burden and does disclose real behavior: it is free, it is fair-use limited to one slice per infill value, the server fetches and unpacks the input, and certain hosts block downloads. It omits auth prerequisites, latency, and what happens on partial failure, but the core behavioral profile is present.

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-loading 'FREE' and the purpose is effective, but roughly half the text is a near-verbatim copy of the model_url schema description (link types, blocked hosts, upload URL), which is redundant inside the tool description. The fair-use note is the only unique sentence in the second half.

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 does step in by naming the returned columns (print time, filament, cost) and the 'one slice per infill value' constraint on a 15-parameter tool. Details like return ordering, units, or per-row error handling are absent, but the essentials for calling it correctly are 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?

Schema description coverage is 100%, so all 15 parameters (including infills, printer, quality, currency, and the BYO pricing fields) are already documented in the schema. The description adds nothing parameter-specific that the schema lacks — the URL paragraph duplicates the model_url description nearly verbatim.

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 operation (a sweep across several infill percentages) and the exact output (a table of print time / filament / cost), which is far more than a restatement of the name. It doesn't name or contrast any sibling (e.g. slice_model for one configuration, get_print_quote for pricing), so it stops short of the top score.

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 'so you can trade strength for material/time' clause implies the use case, and the description warns that Thingiverse/Printables/MakerWorld pages block server downloads. But there is no explicit when-to-use/when-not-to-use routing against alternatives such as slice_model or get_print_quote, so guidance 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.