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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral detail beyond that: it generates a preview image in addition to computed metrics, and it consults installed layer heights and printer fit. It does not disclose cost, file requirements, or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence opening with the workflow cue 'Geometry before slicing:' followed by a compact enumeration. The list is dense but every item is a concrete output, so there is little waste; the trailing 'plus a preview image' is well placed.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the metrics and the preview image. What remains missing is input guidance on path format and the effect of optional printer/nozzle defaults, which keeps it short of full completeness.

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% for three parameters, so the description must compensate. It partially does: 'fit on the printer' and 'which installed layer heights hit them exactly' imply how the printer and nozzle parameters are consumed. However, the required 'path' parameter is never characterized (file type, local vs. remote), and nothing explains behavior when nozzle/printer are omitted.

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 the resource (model geometry) and enumerates the specific analyses performed: size, fit, overhang share, bed contact, slenderness, flat tops, layer-height hits, and suggested object types. The phrase 'Geometry before slicing' positions it in the workflow relative to the slice_model sibling, though it never names that sibling 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?

'Geometry before slicing' implies the usage window (pre-slice inspection) but gives no explicit when-to-use, prerequisites, or alternatives. An agent must infer whether this is mandatory preparation or an optional diagnostic compared with slice_model or compare_slices.

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 and non-destructive; the description usefully adds 'Nothing is saved,' which confirms no side effects. It names the metrics that get compared, but gives no detail on run cost, error modes, or how results are surfaced.

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, then drops into parameter guidance with a concrete example; three sentences with little waste. Dense but every clause carries 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?

For a 10-parameter, nested-object tool with no output schema, the description usefully enumerates the comparison outputs (standing in for a return spec) and explains the pivotal vary parameter. Yet most parameters remain undocumented in both schema and description, so an agent cannot fully configure it from this text alone.

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?

Top-level schema coverage is 0%, so the description must carry parameter meaning; it does clarify vary and values with concrete examples ('support_type', ['tree(auto)','normal(auto)']). However the other eight parameters (nozzle, printer, process, settings, filaments, auto_adjust, object_type, objects) are unexplained, leaving a substantial 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?

States a specific verb and resource ('Slice the same model several ways and compare') plus the exact comparison dimensions (time, grams, colour changes, support time, flat-top deviation). This distinguishes it in spirit from slice_model/slice_project, but it never names or contrasts those siblings 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?

Provides strong how-to guidance for the vary parameter ('process' vs any setting key, with examples), but never says when to pick this tool over slice_model or slice_project, nor any exclusions. Usage is implied by 'compare' 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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered structurally. The description adds content-level context (profile version, cache folder, safety guarantees) but does not clarify format, stability of values, or what 'safety guarantees' concretely reports.

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?

It is short and front-loads the scope, but it is a single comma-spliced fragment with no verb, which makes it harder to parse than a properly formed sentence of the same length. Brevity is achieved partly through under-specification.

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

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

With no parameters and no output schema, the description must carry the full burden of explaining what comes back. Listing four content areas is a reasonable start, but 'safety guarantees' and 'where ... profiles are' remain vague for a zero-arg discovery tool whose whole value is its return contents.

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 there is no parameter semantics to document; the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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 is a noun phrase enumerating returned contents ('where Bambu Studio and its profiles are, profile version, cache folder, safety guarantees') rather than stating a verb+resource like 'returns the local environment and profile paths'. An agent can infer it reports environment info, but the purpose is implied rather than asserted, and nothing distinguishes it from the sibling get_settings.

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 when-to-use guidance, no mention of prerequisites, and no routing against the closely related get_settings sibling. The agent is left to guess whether environment info or settings is the right call.

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 closed-world, so the safety profile is fully covered. The description adds useful behavioral detail beyond that: the free-text filtering behavior and the 'per_object' marker indicating which keys are settable per object/part. It does not describe output shape or how the nozzle dimension affects results.

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, front-loaded with the return content and followed by filter and workflow guidance. No filler, though the quoted filter-word list is somewhat list-heavy for the space it occupies.

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

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

No output schema exists, so the description must describe returns, and it does: valid setting keys, current values, and the per_object distinction. Missing only the nozzle parameter's role and any note on how printer/process resolution works when process is null.

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 carries the burden. It explains the query filter with concrete example words and implies printer+process scoping, but the 'nozzle' parameter is never mentioned and 'process' is only implied. Three of four parameters get some meaning; one is entirely 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 states precisely what the tool returns: every valid setting key with its current value scoped to printer+process. That is specific enough to separate it from sibling listing tools like list_presets and list_printers, 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?

It gives concrete usage context: filter results with words like 'support', 'wall', 'infill', and it points forward to the workflow ('Use the exact keys in slice_model settings'), which is real guidance on why an agent would call this. It lacks any when-not or alternative-tool exclusion, so it stops short of a 5.

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

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

Annotations already declare this as a safe, read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds genuine domain context by explaining that each listed type represents a delta from the printer's default configuration, which an agent cannot infer from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, and the core payload is front-loaded. The parenthetical enumeration of the nine type values is long but earns its place by making the return content selectable at a glance; the only weakness is the verbless, grammatically incomplete construction.

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

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

For a zero-parameter, read-only enumeration with an output schema present, the description covers what the list contains and the meaning of each entry, so return values need not be explained. Nothing operationally necessary is missing, though an explicit 'use this before choosing an object type in slice_model' would have closed the loop.

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 there is nothing for the description to disambiguate. Baseline of 4 applies; the schema is an empty object and needs no elaboration.

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 the resource (object types) and what the tool returns about each one ('what each changes from the printer's default'), so an agent can tell it apart from siblings like list_printers or list_presets. It stops short of an explicit verb such as 'List', but the enumerated payload makes the intent 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?

There is no statement of when to call this tool versus alternatives, nor any prerequisite or follow-up guidance. Usage is only implied by the fact that the returned type names (functional, vase, draft, etc.) map onto parameters of other tools such as slice_model.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds a genuine scoping fact — results include the user's own presets — which is useful. It says nothing about pagination, result size, or how the query/nozzle filters behave.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with no waste, and the resource plus its scope are front-loaded. It is efficient rather than padded, though it is perhaps too sparse for a 4-parameter tool.

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

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

An output schema exists so return values need not be described, but with 4 parameters at 0% schema coverage and zero usage guidance, the definition leaves the agent guessing about query/nozzle filters and when this tool is the right call. For a parameterized query tool this is noticeably thin.

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% across 4 parameters, so the description must compensate and only partly does: 'printer' and the process/filament 'kind' are implied by the text. The 'query' and 'nozzle' parameters are never explained anywhere, leaving half the inputs semantically opaque.

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

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

States a specific resource (presets) and scope (process or filament presets compatible with a given printer, including the user's own). Clear enough to distinguish from siblings like list_printers or get_settings, though it never says 'list' explicitly and offers no differentiation statement.

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?

No explicit when-to-use, prerequisites, or alternatives. The only guidance is implicit: it's tied to a printer and a preset kind. Nothing tells the agent whether to reach for this versus get_settings or list_printers when hunting for configuration.

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

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

Annotations already establish that this is a safe, idempotent, closed-world read, and an output schema exists, so the description is not obligated to explain safety or return values. It still contributes useful behavioral context by noting the cardinality rule ('one per printer + nozzle') and the field set, though it says nothing about ordering, limits, or how an empty result behaves.

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 what the tool returns and followed by the parameter hint; nothing is padded. The first sentence is a dense field dump, but every item listed is genuine content an agent would want.

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 simple zero-required-parameter list tool, the description covers the resource, the entry shape, and the filtering parameter, while annotations handle safety and an output schema handles returns. The only real gap is routing guidance against list_presets, which is a modest omission rather than a blocking one.

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 the single parameter — and it does, explaining that 'query' filters by words and giving a concrete example ('P1S 0.4'). It stops short of stating matching semantics (substring vs token, multi-word AND/OR) or how a null query behaves, but it is well above the low-coverage 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?

The description states the resource precisely — installed printer presets, one per printer + nozzle — and enumerates the fields each entry carries, so an agent knows exactly what it gets back. It does not explicitly differentiate itself from the sibling list_presets, so a reader must infer the printer-vs-process distinction from the noun alone.

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 when-to-use statement and no named alternative, despite the near-neighbour sibling list_presets existing. The only usage hint ('query filters by words') describes the parameter, not when this tool should be selected over another.

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

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

Annotations already establish it is a non-read-only but non-destructive, idempotent, closed-world operation. The description adds genuine behavior beyond that: rules are evaluated in order with 'later wins', z is measured from the part's base, and it returns a result plus a preview image that should be visually checked before trusting the paint. It does not mention auth, rate limits, or what exactly gets written, but the added semantics are substantial.

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?

Well front-loaded: a single-line purpose sentence precedes the rule grammar. The five JSON examples are dense but each demonstrates a distinct rule type, so they mostly earn their place; the block is longer than strictly necessary for a terse definition but proportionate to the tool's complexity.

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 0% schema coverage and no output schema, the description covers the rule grammar and the return value (result + preview image) but leaves most parameters undefined, so an agent cannot know what path, printer, output_dir, filaments, or settings expect. Adequate on the core mechanic, incomplete on the surrounding configuration surface.

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 carries the full burden. It does an excellent job on the hardest parameter, 'rules' (five rule-type examples plus shared 'within' and 'only_from' keys), but the other twelve parameters (path, output_dir, printer, filaments, settings, resolution, object_type, base, name, slice, nozzle, process) receive no explanation at all. Valuable but partial compensation for a large coverage 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?

The description names a specific verb and resource ('Colour a single mesh by rules ... then slice and verify'), which is concrete and unambiguous. It distinguishes itself functionally from pure slicing siblings like slice_model by emphasizing the painting step, though it never names or explicitly contrasts any sibling.

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

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

Usage is only implicitly conveyed: you call it when you want to apply filament rules to a mesh and get a sliced, verified result. There is no explicit when-to-use/when-not-to-use guidance and no routing to alternatives such as slice_model or analyze_model, leaving the agent to infer the boundary.

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 safety is covered. The description adds useful operational context (post-update timing, purpose of validating paint codes) but says nothing about what the test returns or how success/failure is signalled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler. The wording is a little cryptic ('slice six colour bands') but nothing is wasted.

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

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

For a two-parameter diagnostic with no output schema, the description is thin: it does not explain the nozzle parameter, what the six-band slice produces, or how to read the result. Annotations carry the safety profile, but the operational detail is incomplete.

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?

Two parameters (nozzle, printer) with 0% schema description coverage, so the description must compensate and does not. 'This machine' loosely hints at the printer parameter, but nozzle is entirely unexplained in both schema and description.

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 verb and object ('Slice six colour bands') and a goal ('prove the paint codes'), but the tool is named self_test and the text reads like a slicing action, which blurs its identity against the sibling slice_model. It is unclear whether this is a diagnostic or an ordinary slice.

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?

'Run after updating Bambu Studio' supplies one concrete trigger condition, which is more than nothing. However there is no guidance on when NOT to use it or how it relates to slice_model / paint_model, so the agent must infer the rest.

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 it is a non-read-only but non-destructive, idempotent, closed-world operation, and the description adds real substance: exact artifact paths written (<output_dir>/<name>.3mf plus <name>-report.md), that Bambu Studio itself saves the file, and the returned metrics (time, grams, purge, colour changes, problems). It does not mention permissions, runtime cost, or failure modes, but for an annotated tool this is solid added 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?

Front-loaded with the core action, then outputs, then the three flag behaviors. Dense and mostly waste-free, though the line-broken phrasing and the dangling '-report.md' fragment make it slightly harder to scan than it needs to be.

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

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

No output schema exists, and the description helpfully enumerates the return values, which is the strongest part. But with 11 parameters at 0% schema coverage and no sibling differentiation, an agent still lacks enough to populate printer/process/nozzle/filaments confidently.

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% across 11 parameters, so the description must carry the load. It does add meaning for object_type, auto_adjust, output_dir/name (file naming) and the settings precedence chain, but leaves nozzle, arrange, printer, process and filaments undocumented in both places.

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 multi-step verb chain (build project from meshes, slice headless, verify) plus concrete outputs, so the agent knows exactly what it produces. The only gap is that the sibling 'slice_project' is never mentioned, so the boundary between the two slicing tools 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 behavior of key flags ('object_type picks process and settings', 'auto_adjust adds supports/brim', 'settings always wins') and a scope note ('Never prints'), which implies when it is appropriate. However there is no explicit when-to-use/when-not guidance and no routing against the near-identical sibling 'slice_project'.

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

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

Annotations already declare destructiveHint=false and idempotentHint=true, but the description adds meaningful context beyond them: 'The original file is never modified' and that objects are re-arranged for the new bed when a different printer is chosen. That last point is a non-obvious side effect the agent could not get from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the operation and its input type, followed by the preservation guarantee and the non-destructive promise. 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 9-parameter, no-output-schema tool with 0% schema coverage, the description is directionally useful but incomplete: it never says what the tool produces or where (presumably a sliced file in output_dir), and several parameters remain unexplained. 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 0%, so the description carries the burden, and it does explain the intent of process, filaments, settings and printer ('optionally with another process, filaments, settings or even another printer'). However, name, output_dir, nozzle and object_type are never explained, leaving roughly half the parameters undocumented in both places.

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: slice an existing Bambu Studio project (.3mf, e.g. from MakerWorld), which distinguishes it from the sibling slice_model that presumably takes a plain model. It also enumerates what is preserved (objects, paint, modifiers), so the agent knows what class of input this tool consumes.

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 rather than stated: use this when you already have a Bambu project file and want to re-slice it, possibly with a different process, filaments, settings or printer. No alternative (slice_model, compare_slices) is named and no when-not condition is given, so the agent must infer the boundary from the resource type alone.

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