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

With zero annotations the description carries the full load, and it does substantial work: it explains default ear placement, that skipped tips are reported with reasons, that a warning is emitted when a point would weld something, and that radius 0 means Bambu Studio's default of 16 line widths. It does not state the one destructive-ish concern an agent would want — whether existing ears are replaced when keep=false — though 'keep: add to the ears the object already has' implies 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?

Front-loaded with the concept, then default behavior, then point overrides, then radius/keep, then a verification workflow — a sensible ordering. The sentences are heavily packed with parenthetical clauses, which costs some scannability, but no sentence is redundant.

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 annotations and no output schema, so the description must cover behavior and results; it does cover default placement, skip reporting and warning emission well. The remaining gaps are the undocumented clearance parameter and no statement of what the call returns or whether it requires an already-loaded plate.

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 0%, so the description must compensate, and it explains narrow, small, points (both [[x,y]] and [[x,y,radius]] forms, units in plate mm, warning behavior), radius (including the 0 = default special case) and keep. The notable omission is clearance, a 7th parameter that is never mentioned anywhere, and object is only implicitly the target.

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?

Starts by defining the specific resource ('small round brims only where a part needs them') and contrasts it with the alternative it replaces ('instead of a brim all around'), so an agent can distinguish it from a plate-wide brim setting or a generic brim tool. The add operation is unambiguous from the name plus the defaults/per-points behavior it then describes.

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

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

Explicitly states the intended use case — 'Meant for print-in-place and articulated models' — and explains why the alternative fails ('a full brim fills the joint gaps on the first layer and welds them'), which is a real when-to-use/when-not rationale. It also prescribes a verification workflow (preview_plate, slice_project, preview_layer). It does not name sibling remove_brim_ears or any exclusion conditions for non-articulated models, keeping it just 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 behavioral burden. It does disclose two valuable traits: the action fires before the target layer prints, and z is snapped to the nearest real layer at or above the requested height. It does not say whether the action persists in the saved project, how it interacts with existing actions at the same height, or what errors occur for out-of-range z or plate.

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

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

Front-loaded with the trigger condition before the action enumeration, and every clause adds information rather than repeating the name. The nested parentheticals make it dense but not padded; a slightly cleaner enumeration of action→parameter coupling would tighten it further.

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

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

For a mutation tool with no annotations and no output schema, the description covers the trigger semantics and most parameters but leaves the required `plate` argument unexplained and says nothing about persistence, error conditions, or the return result. Adequate to call correctly in the happy path, incomplete for anything adjacent.

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, and it largely does: z gets a unit and a snapping rule, action gets its three legal values with meanings, message is explained as shown in Bambu Studio, filament is explained as the AMS slot used from that height on, and gcode accepts full command lines. The notable omission is `plate`, which is required but never mentioned, and the coupling between action and the other params is only implied.

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

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

Specific verb+resource with scope: it registers an action that fires when the print reaches height z, before that layer prints. The three action modes (pause, filament_change, gcode) are enumerated, so the agent knows exactly what class of operation this is and can distinguish it from siblings like set_height_range or remove_layer_action.

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?

Each action value carries an inline use case — pause to insert magnets or nuts, filament_change to switch AMS slots from that height, gcode for arbitrary commands like 'M104 S210'. That is clear when-to-use-per-mode context, but there is no explicit statement of prerequisites (a loaded project, a valid plate) or of when to prefer remove_layer_action / set_height_range instead.

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 behavioral burden and does disclose meaningful traits: z coordinates are measured from the object's bottom, region coordinates from the center, negative removes material, modifier changes settings inside, and cylinder shape derives width from the smaller region side. It does not cover permissions, reversibility, or return behavior, but it provides substantial operational 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?

The description is dense but front-loaded with the core action, then organized by kind and shape. It contains no obvious filler, though the single-paragraph run-on format could be slightly easier to scan.

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 7-parameter tool with no schema descriptions, no annotations, and no output schema, the description is complete enough to support correct invocation. It covers the key geometric semantics and kind behavior; missing details are mainly around the object parameter and any return/undo behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it largely does: it explains z_from/z_to origins and the z_to=0 top convention, region format [x0, y0, x1, y1] from center, kind values, shape values including cylinder width semantics, and a settings example. Only the object parameter is not elaborated, but its meaning is evident from the first sentence.

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: adding a part to an object, with kinds modifier, negative, support_blocker, and support_enforcer. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as add_shape or add_relief.

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 implied usage through kind explanations and examples, such as using negative for a magnet hole and modifier for changing infill in a region. However, it does not explicitly say when to use this tool versus alternatives or name any sibling tools, so guidance remains inferential.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: whether the operation mutates project state (it clearly does), whether existing plates are unaffected, where 'the end' is in ordering, and whether the new plate inherits settings from the current plate. 'At the end' is the only behavioral detail offered.

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 a single, front-loaded sentence with no redundant padding, which is structurally fine, but the brevity comes at the cost of substance rather than being earned through precise wording.

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 state-mutating project operation with no annotations, no output schema, and an undescribed parameter, the description is far from sufficient—it doesn't say what is returned, whether the added plate becomes the active/selected plate, or how failures are surfaced.

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 the single optional 'name' parameter, and the description never mentions that a name can be supplied or what happens when it is omitted (the schema default is an empty string). The one parameter is effectively undocumented across both structured and unstructured 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?

The verb and resource are identifiable ('Add ... plate'), but the description is thin: it never says this creates a new, empty build plate appended to the project, nor how that differs from siblings like 'rename_plate', 'set_plate_settings', or 'remove_plate'. An agent can guess the effect, but the definition doesn't distinguish it explicitly from other plate-scoped tools.

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 guidance on when to add a plate versus using an existing one, no mention of any alternative tool, and no prerequisites (e.g., does the project need to be open?). Usage is only implied by the tool name.

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 at all, the description carries the full burden and does well: it discloses that raised relief becomes a new part (colored by filament=N) while engraved relief becomes a negative part, that it wraps around curved faces keeping size along the surface, and that it recommends a preview afterward. It omits failure modes, whether the original object is modified, and any permission/error behavior, so it falls short of 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?

The purpose sentence is front-loaded, followed by a compact parameter glossary and a closing tip. It is dense but every line carries information; the only mild bloat is the repeated curved-face explanation, which could be trimmed.

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 an 11-parameter tool with no annotations, no output schema, and zero schema coverage, the description supplies the semantics an agent needs for most parameters and the raised-vs-engraved model. The unexplained required 'object' parameter and the unmentioned 'font' / text-vs-svg precedence are the remaining 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 coverage is 0%, so the description must compensate, and it largely does: it defines face (with the six enumerated values and 'the side it is read from'), at ([x,y,z] plate point, defaulting to the face center), size (cap height for text, longest side for SVG, in mm), depth, rotate, engrave, and filament. It leaves 'object' (the sole required param) and 'font' undefined, which keeps it from 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?

The description names a specific verb and resource ('Text or an SVG logo on a face of an object, raised or engraved') and draws a clear analogy to Bambu Studio's Text and SVG tools. It also names the closest behavioral relatives (add_shape/add_modifier are implicitly distinguished by the text/SVG focus) and the follow-up sibling preview_plate, so an agent can tell it apart without opening the schema.

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

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

It gives clear context for when to use it (adding text/SVG to a face, raised or engraved) and explicitly points to preview_plate afterwards, plus set_part_type to revert an engraving. It stops short of naming an alternative tool to use instead (e.g. add_modifier or boolean_objects) or stating exclusions, so a 4 rather than 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. It does disclose a non-obvious side effect: base > 0 creates a separate part named 'Base' with its own filament, and base_filament 0 means inherit the text filament. It does not state units for most dimensions, whether objects are placed at the origin or at x/y, or what the tool returns, so the safety/placement profile remains incomplete.

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 verb and the shape list, then per-shape parentheticals that each carry real information rather than filler. The density is justified by 18 parameters, though the text/svg clauses become long and would read better as separate lines.

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 an 18-parameter mutation tool with no annotations, no output schema and no schema descriptions, the description covers shape semantics well but omits object placement (x/y), the meaning of plate and filament indices, and any return value. It is adequate to build a solid but not to fully predict 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 coverage is 0%, so the description must compensate, and it does for most parameters — including disambiguating the overloaded `height` (box height vs. depth of text letters vs. raised height for svg) and explaining text_height, base, base_filament, font, svg and size semantics. Gaps remain: x, y (placement), name, plate and filament indices are never mentioned.

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 ("Create a simple solid") and then enumerates the exact shape families supported (box, cylinder, cone, sphere, text, svg) with their governing dimensions. An agent can immediately tell this is the primitive-creation tool and, via the closing sentence, how it differs from add_relief.

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

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

Explicitly routes the agent to add_relief for putting text or a logo on an existing object, which is the key sibling ambiguity. It does not cover other plausible alternatives (import_model, add_modifier) or prerequisites such as an open project, but the main exclusion is stated clearly.

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. It does disclose genuine operational mechanics (alignment is computed from outer bounding boxes; distribute anchors on the two outermost objects; both modes may run together), which is real value. It omits side effects: whether positions are mutated in place, whether it requires all objects on the same plate, undo behavior, and 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?

Purpose is front-loaded in the first clause, followed by the two mode descriptions in compact order. Roughly three sentences with no filler; even the closing 'Both can be given' is a needed combination rule rather than 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 mutation tool with zero annotations, no output schema, and 0% schema description coverage, the description covers the align/distribute value space well but leaves the required 'objects' argument and the return behavior undefined. An agent could call it correctly on the mode arguments yet still guess wrong about what to pass for objects.

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 0% and no enums are declared, so the description is doing the heavy lifting: it enumerates valid align values (left, right, center_x, front, back, center_y) and distribute values ('x' or 'y'), including which axis each belongs to. The 'objects' parameter is never explained (names vs. IDs, whether they must share a plate), keeping it from 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 (line up) and resource (objects of one plate) and clarifies the axis semantics of align versus distribute. The Bambu Studio analogy and 'by their outer boxes' pin down the operation precisely. It does not, however, distinguish itself from the sibling 'arrange' or 'move_object', which an agent could plausibly confuse with alignment.

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 implied: the description explains what align/distribute do but never says when to reach for this tool versus 'arrange' or 'move_object'. It does add one useful usage rule, 'Both can be given', indicating align and distribute can be combined in a single call, but there are no exclusions or preconditions.

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: side effects are disclosed (nozzle heats, currently loaded filament is returned to its slot, new filament purged), the dry-run behavior of the first call is described, and the firmware/permission constraints are named. An agent knows exactly what physical change will occur and when nothing will be sent.

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?

Content is front-loaded: purpose first, then parameter meaning, then preconditions, then the confirm protocol. Dense and mostly economical, though the Bambu Studio analogy and the final firmware paragraph could be tightened without losing 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?

No output schema exists, yet the description tells the agent what the first (dry-run) response contains — what would happen plus a confirm code — which is exactly the return-value detail needed for the two-step flow. For a two-parameter hardware mutation tool, prerequisites, effects, and the safety protocol are all 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 coverage is 0%, so the description must compensate, and it largely does: 'slot' is defined via a concrete mapping (AMS 1 = slots 1-4, AMS 2 = 5-8) referencing printer_status, and 'confirm' is explained functionally through the two-call flow including that the first response returns the code. It never states the confirm value is an opaque string taken verbatim from the response, which is a small remaining 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 (load filament from an AMS slot into the nozzle) and grounds it in a familiar reference (Bambu Studio's Load button), making the operation's scope unambiguous. It is clearly distinguishable from the ams_unload sibling, and the description of the internal sequence (unload current filament back to slot, feed new one, purge) removes any doubt about what 'load' entails.

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

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

Explicitly states the precondition 'Only when the printer is not printing' and a hard environmental gate: firmware only accepts it in LAN-only mode with Developer Mode, otherwise fall back to the printer screen, Bambu Handy, or Bambu Studio. The two-call confirmation protocol is spelled out with the trigger condition for the second call (only after the user agrees).

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: it discloses the physical side effect ('the nozzle heats'), the two-phase dry-run confirmation (nothing is sent on first call, code returned), and the firmware mode restriction that determines success or failure. These are exactly the safety and environment facts an agent cannot infer elsewhere.

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 action, then the precondition, then the confirm protocol, then the environment constraint — in the order an agent needs them. Sentences are dense but every one carries non-redundant 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 single-parameter, no-output-schema mutation tool, everything needed to call it correctly and safely is present: precondition, safety side effect, confirmation handshake, and troubleshooting fallback when firmware blocks the call.

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 0% and the sole 'confirm' parameter has no schema description, but the description fully explains its semantics: omit it to get the code, supply confirm=<code> to execute. It does not state the type or that an empty string is the default, but the operational meaning is unambiguous.

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?

Names a specific verb and resource ('Unload the filament in the nozzle back to its AMS slot') and anchors it to a known UI affordance in Bambu Studio's Device tab. It also implicitly distinguishes itself from the sibling ams_load by naming the opposite direction of filament travel.

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?

States the precondition ('Only when the printer is not printing'), the firmware prerequisites ('LAN-only mode with Developer Mode'), and explicit fallbacks when those fail ('use the printer screen, Bambu Handy or Bambu Studio'). The two-step confirmation protocol is spelled out with the condition for the second call ('only after the user agrees').

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 that nothing is moved if objects don't fit, the answer reports leftovers and required plate count, unselected objects stay put, and multi-material plates reserve the back-right corner for the prime tower. It does not cover permissions, reversibility, or rate limits, but for a local arrangement operation it is substantially transparent.

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

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

The description is dense but front-loaded, starting with the core purpose and then methodically covering parameters and edge cases. Every clause adds information; however, the run-on style could benefit from bulleted structure for faster parsing.

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?

Given nine parameters, zero schema descriptions, and no output schema, the description is nearly complete: it explains every parameter, the failure behavior, and a recommended follow-up (preview_plate). It lacks explicit sibling-tool routing and any note on permissions/undo, keeping it just 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 coverage is 0%, but the description compensates by explaining all nine parameters: gap units and edge behavior, plate selection semantics, plates modes (0/N/-1), rotate with rotation_step, multi_material meaning, avoid_calibration_area with printer examples, align_to_y, and objects as ids or names. This goes well beyond the bare titles and defaults 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 ('Arrange') and resource ('objects') with a precise scope: using real outlines from above including brim ears, to enable nesting. It contrasts with Bambu Studio's convex-hull-only Arrange, though it does not explicitly differentiate from nearby siblings like fill_plate or align_objects.

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 operational guidance for selecting objects (plate N, named objects, or all), plate spreading modes, rotation, material handling, and calibration-area avoidance. However, it never states when to prefer this tool over siblings such as fill_plate or align_objects, nor any preconditions or exclusions.

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

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

With no annotations, the description must carry behavioral disclosure. It does say what information is returned (which is genuinely useful given there is no output schema), but it never states that the call is read-only/without side effects, nor what happens when Bambu Studio is not installed.

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 clause that front-loads the resource (installation location) followed by the remaining reported fields. Nothing extraneous, though it reads as a fragment rather than a sentence.

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 field enumeration is doing real work, but it omits the failure mode (not installed / not running) and the shape of values such as version strings or project paths. Adequate for a trivial zero-param tool, but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; no parameter semantics are required or missing.

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 specific resource and enumerates what the status covers: install location, version, running state, and current project. It is clearly distinguishable from name alone, though it lacks an explicit verb and never differentiates itself from siblings like printer_status or sync_with_bambu_studio.

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 guidance on when to call this versus printer_status or open_in_bambu_studio, and no prerequisites such as 'Bambu Studio must be installed'. The usage is only implied by the name and the field list.

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, so the description carries the full load, and it discloses key post-conditions: result keeps object's name, settings and filaments, painted colors persist, new faces take the part's filament, and the tool object is deleted unless keep_tool=True. It does not cover reversibility/undo or failure modes beyond the closed-solid check.

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 before the operation breakdown, and every clause adds usable information. It is dense across three sentences but not padded.

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

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

For a mutation tool with no annotations and no output schema, the description covers inputs, results, and the key side effect (tool removal). Minor gaps remain around error behavior when solids are open and what the returned result handle looks like.

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 0%, but the description defines all five parameters in context: object vs tool_object roles, the three valid operation values, part (defaulting to the biggest) for union, and keep_tool controlling whether the tool object is removed.

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 ('Mesh boolean between two objects on the plate') and anchors it to a known reference (Bambu Studio's Mesh boolean). It is clearly distinguishable from siblings like merge_objects and cut_object by naming the operations and their geometry semantics.

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 each operation's intent (difference = cut a hole; intersection = keep shared volume; union = weld onto a part), which tells the agent which one to pick. It also states the closed-solid prerequisite and points to check_object. It stops short of explicitly contrasting with cut_object/merge_objects 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?

No annotations are supplied, so the description carries the full burden. It does disclose the reported facets (size, volume, piece count), which is meaningful since there is no output schema, but it never says whether the call is read-only or mutates the model, what happens on invalid input, or how the object is identified.

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 clauses, front-loaded with the key question and then the measurable facets. No filler, though the interrogative framing is slightly informal for a tool spec.

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 inspection tool with no annotations and no output schema, the description covers the expected return facets but leaves the input identifier and safety profile undefined. Adequate to guess at intent, not complete enough to call 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% and the single required 'object' parameter is completely unexplained in both schema and description. It is unclear whether this is an object name, an internal ID, or a file path, which is a real usability gap for a required parameter.

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 identifies the resource (a mesh/object) and enumerates the specific properties it evaluates: closed solid, size, volume, and number of separate pieces. It lacks an explicit action verb ('check' only appears in the tool name) and never distinguishes itself from nearby analysis tools like measure_object or check_print_risks, but the facets listed make the intent recoverable.

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 indication of when to call this versus measure_object, check_print_risks, or slice_project, and no prerequisites such as whether the object must already be loaded on a plate. The agent must infer usage entirely from the question phrasing.

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. It does useful work by disclosing the exact heuristics (height vs. footprint width, narrow footing without brim, filament temp of 0 for the plate, tall parts sharing a crowded plate), but never says whether the tool is read-only, whether anything is modified, or what form the warnings take.

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 risk summary is front-loaded before the checklist, so an agent can stop reading after one clause. The enumerated criteria are dense but each maps to a distinct check, though the parenthetical asides (e.g. "pins lying on their side") cost more words than they return.

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 annotations and no output schema, the description should explain what an agent gets back (a list of warnings? a score? per-plate groupings?) and whether the call is side-effect free. It covers the input scope well but leaves the return contract entirely unspecified for a diagnostic 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 0% and the sole parameter has no description, so the schema alone would leave "plate" ambiguous. The phrase "Per plate (0 = all)" supplies the one non-obvious semantic, resolving the default value's meaning; it adds nothing about valid ranges beyond that.

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 analysis: predicting parts that will come off or topple plus settings that don't fit, scoped per plate. It is clear what the tool produces conceptually, but it never contrasts itself with the near-sibling check_object, so an agent must guess which checker to reach for.

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?

"Before a long print" gives a concrete timing condition for invocation, which is more than most definitions offer. It stops short of exclusions or naming alternatives (e.g. check_object) for single-object inspection.

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. It discloses that the operation scales to millimeters and that restore=True scales back down, implying reversibility. It does not state whether the change is permanent, whether it modifies the object in place, or whether it requires any preconditions, leaving meaningful behavioral gaps.

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

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

The description is a single dense paragraph with no wasted words, and the core scaling effect is given early. The opening phrase is slightly awkward, but the examples and restore behavior follow logically. It could be better front-loaded with an action verb, but it remains efficient.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the conversion behavior well but omits key context: what 'object' refers to, whether the operation is in-place or returns a new object, and any side effects. It is minimally viable but has clear gaps for an agent to invoke it 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%, so the description must compensate. It adds useful meaning for 'unit' (allowed values: inch, cm, meter) and 'restore' (scales back down), but it does not explain the required 'object' parameter at all. This partial coverage is just enough for a 3.

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

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

The description explains the specific operation: scaling an object from a source unit (inch, cm, meter) to millimeters, with an option to restore. It gives a concrete example (1-unit cube becomes 25.4, 10, or 1000 mm). It does not start with a crisp verb+resource phrase, but the effect is clear and distinct from generic transform tools.

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 implies use when an object is modeled in non-mm units and points to import_model as the detector for such cases. However, it does not explicitly state when to choose this over alternatives like transform_object or when not to use it. Usage context is inferred rather than spelled out.

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 well by disclosing that replace=True first removes the targets' own settings and that height_ranges=True copies height bands. It does not discuss permissions, reversibility, or error behavior, leaving some behavioral gaps.

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

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

The description is three concise, front-loaded sentences with no wasted text. The core copy operation, optional parameter meanings, and Bambu Studio analogy are all presented efficiently.

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

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

For a mutation tool with five parameters, no annotations, and no output schema, the description covers the main operation and all optional behaviors sufficiently. It leaves minor gaps around defaults, error cases, and return behavior, but an agent can call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains keys as a filter, replace=True as removing target settings first, and height_ranges=True as copying height bands, covering the key optional parameters well, though it does not explicitly name from_object and to_objects or clarify omitted-key defaults.

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: copying one object's own settings to other objects. The Bambu Studio Copy/Paste analogy and the mention of set_object_setting make the scope clear and distinguishable from related sibling tools.

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 clear context for when this tool applies: transferring settings from one object to others, analogous to Copy/Paste process settings. It does not explicitly state when not to use it versus set_object_setting or duplicate_object, but the intended use is easy to infer.

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 behavioral burden and does well: it explains placement results, connector fitting failures, material preservation, and that modifiers, negative parts, and painted colors are kept. It does not state whether the original object is replaced/consumed, whether the cut is reversible, or what the response contains.

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

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

The description is long but justified by a 14-parameter tool, and the main purpose and keep options are front-loaded. It is a dense run-on paragraph with many parentheticals, so structure could be improved, but there is little wasted content.

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

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

For a complex, unannotated 14-parameter mutation tool with no output schema, the description is substantially complete on cut geometry, connector behavior, and edge cases. It still lacks lifecycle details such as what objects are returned and whether the source object is modified in place.

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 0%, so the description must compensate, and it does: it defines the cut plane via z/point/normal, explains keep, place, connector types, shape, style, size, depth, count, positions, and clearance in context. Nearly every parameter has meaningful semantics beyond its bare name.

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: 'Cut an object with a plane', with optional connectors. It clearly distinguishes the operation from generic object manipulation, but does not explicitly contrast it with the sibling split_object 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?

The description explains many parameter choices and behaviors, but gives no explicit guidance on when to use cut_object versus alternatives like split_object, or when not to use it. The agent must infer tool selection from the purpose alone.

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 provided, the description bears the full behavioral burden and delivers almost none: it doesn't say the deletion is irreversible, whether undo exists, whether dependent settings/parts are discarded, or what the response looks like. The word 'Remove' implies mutation, but nothing beyond the obvious is disclosed.

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 short, front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than tight editing.

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 destructive, one-parameter tool with no annotations, no output schema, and zero schema descriptions, the description should carry identification format, irreversibility, and side effects. It covers only the bare action.

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?

There is one required parameter at 0% schema description coverage, so the description must explain what 'object' is, yet it only gestures at 'an object'. It does not say whether this is a name, id, index, or handle — a critical ambiguity for a destructive operation.

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 (Remove) and resource (an object in the project), which is immediately actionable. It does not distinguish itself from near-neighbours like remove_part, remove_plate or skip_objects, so the agent must infer the scope difference.

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 guidance on when to use this versus alternatives, no prerequisites, and no note about whether the object must first be deselected/printable. The agent is left to infer everything about invocation context.

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 behavioral burden and does add real context: a backup copy is retained (implying recoverability), and it explains the mechanism blocking cloud-preset deletion. It stops short of stating required permissions, whether the deletion is immediate, or what the response contains beyond a hint about the cloud copy location.

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 action is front-loaded in the first clause, which is good. The remainder is somewhat convoluted, especially the trailing 'and the answer says where it is', which restates indirectly what the sentence already implies and costs clarity.

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 annotations and no output schema, so the description must justify itself, and it covers the destructive-behavior and cloud-scope story well. It is still incomplete for a two-required-parameter tool: the meaning and accepted values of 'kind' are absent, and nothing tells the agent how to recover the backup copy it promises 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 0% and both parameters are required, yet the description never mentions them. 'kind' in particular is undefined — the agent gets no hint that it selects a preset category (filament/process/printer), nor any guidance on valid values or the interplay between kind and name.

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

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

Specific verb+resource: 'Delete one of your user presets'. It also draws a scope line (local presets only, not Bambu cloud presets), which separates it from cloud-side deletion. It does not explicitly contrast with nearby siblings like edit_preset or delete_object, but the resource is 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?

The when-not case is stated clearly: a cloud preset cannot be deleted here, because Bambu Studio would re-download it. However, the alternative is described only as 'its own Delete' with a pointer to 'the answer' rather than naming a concrete tool or workflow step, so the agent has to infer the follow-up action.

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 thoroughly. It discloses irreversibility, the two-step dry-run confirmation flow with a returned code, what the dry-run response contains, and the print-running safety guard.

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

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

The description is dense but front-loaded and well structured. It moves from purpose to selection criteria to the confirmation workflow and finally the safety warning, with every sentence contributing necessary 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 destructive file-deletion tool with no annotations and no output schema, the description covers the critical missing context: destructive nature, confirmation protocol, response contents, irreversibility, and runtime blocking. An agent has enough information to call it safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains names as values from printer_files, older_than_days as an age filter, and confirm as the code from the dry run. It gives kind values for prints and thumbnails but does not explicitly state the exact kind value for timelapse videos, leaving a minor gap on the required parameter.

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: delete files from the printer's SD card. It further distinguishes the supported file categories (timelapse videos, past prints, orphan thumbnails), making it clearly different from sibling delete_object, which operates on project objects.

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 explains how to select files, either by names from printer_files or by older_than_days, and gives a strong operational condition: nothing is deleted while a print is running. It does not explicitly name sibling tools or discuss when to prefer them, but the usage path is clear.

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: it usefully discloses that the operation is 'read-only on the printer' and that it writes a copy into the local projects folder, plus the side effect of extracting the last frame of a timelapse. It does not explain overwrite behavior if the target name already exists, permission requirements, or failure modes, which are significant gaps for a file-copy operation with zero annotation coverage.

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

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

The description is short and front-loaded with the core action, then adds parameter behavior and the read-only safety note. The sentence about the timelapse's last frame is slightly awkward and could be clearer, but every clause is relevant and nothing is padded.

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 tool with no output schema and 0% schema description coverage, the description covers purpose, parameter modes, and read-only status. It still leaves important operational details unstated: what the tool returns or where exactly in the projects folder the file lands, how name collisions are handled, and whether the downloaded file becomes a project or just a file.

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, and it does explain both parameters: name is drawn from printer_files or defaults to 'latest' for timelapses, and kind='prints' selects a past-print file. It stops short of listing all valid kind values or clarifying what name should be when kind='prints', so it is helpful but not fully authoritative.

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 and resource ('copy a file from the printer's SD card into the projects folder') and immediately enumerates the two supported targets: a timelapse video or a past print file. It also names the sibling tool printer_files as the source of valid names, so an agent can distinguish it from printer_files, delete_printer_files, and send_to_printer without opening a schema.

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

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

It explicitly states which case uses which mode: timelapse videos use name from printer_files or 'latest', while past-print files use kind='prints'. However, it does not state when not to use this tool or name a clear alternative for related operations (e.g., listing files vs deleting them), leaving some inference to the agent.

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 behavioral burden. It discloses that copies are placed onto free spots and default to the same plate, but it does not explain what happens if there are insufficient free spots, whether object settings are copied, whether the source object remains, or what the operation returns.

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

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

The description is a single efficient sentence with the core action and default placement behavior front-loaded. Every phrase contributes to understanding the 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?

For a simple three-parameter mutation tool, the description covers the main action and placement semantics. However, without annotations or an output schema, it leaves important failure and result behavior 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 0%, so the description must compensate. It gives useful meaning for all three parameters: the object being copied, the number of copies, and the optional target plate, though it does not clarify plate indexing or the default plate value beyond what the schema states.

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: copying an object a given number of times onto free spots. It is clear what the tool does, but it does not explicitly distinguish it from nearby siblings such as copy_object_settings or fill_plate.

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 default behavior of keeping copies on the same plate unless `plate` is given implies when the tool is useful. However, it gives no explicit guidance on when to choose this over alternatives like copy_object_settings, arrange, or fill_plate.

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 delivers: a backup copy is kept, null values revert to the parent preset, changes only appear in Bambu Studio after a restart, and the change is uploaded to Bambu cloud if the preset exists there. These are exactly the side-effect, reversibility, and propagation facts an agent needs before mutating shared state.

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 backup guarantee are front-loaded in the first clause, with semantics following. The content is dense but nearly all of it earns its place; the extruder-variant detail is essential rather than filler, though the formatting is one unbroken block.

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

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

For a mutation tool with no annotations, no output schema, and a free-form nested object parameter, the description covers reversibility, propagation delays, cloud sync, and the read-only system-preset constraint. Combined with the parameter detail, an agent has enough to call it correctly and anticipate consequences.

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 0%, and the description compensates for two of three parameters in depth: it enumerates the 'kind' values (filament | process | printer) and fully specifies the 'values' object, including per-extruder list form, null-to-remove semantics, and concrete examples. The 'name' parameter's matching behavior (exact string, case sensitivity) is never addressed, which keeps it below 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?

The description states a specific verb and resource ('Change settings of one of your user presets') plus a scope qualifier ('directly, without a project'), which separates it from the save_*_preset and rename_preset siblings by implication. It does not explicitly name those siblings, so the distinction is clear but not spelled out.

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 concrete precondition and exclusion: 'Bambu system presets are read-only: save a user preset from them first', which tells the agent when this tool will not work and what to do instead. It stops short of naming alternatives such as rename_preset, delete_preset, or list_user_presets for related operations, so guidance is clear but incomplete.

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 real work: it discloses that negative parts/holes are cut out and that colors and settings are NOT carried into the STL, plus the one-file-per-object vs consolidated grouping behavior. It does not say where files are written or what the call returns, which is the remaining gap.

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

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

Front-loaded with the action and resource, then scope options, then the behavioral caveats; nearly every clause carries information. The parenthetical farm/share rationale is slightly verbose but justifies usage.

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 3-parameter tool with no annotations and no output schema, the description covers selection scope, grouping, and geometry semantics well. The notable omission is any indication of the output (file locations or return value), which an agent would want given there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (titles only), so the description must compensate, and it does: 'objects' is explained as named objects, 'plate' as selecting all of a plate, and 'one_file=True' is described as merging objects that are on the plate. It does not clarify plate index conventions, the default plate 0, or whether object names or IDs are accepted.

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 ('Save objects as STL files') and immediately enumerates the three export scopes: named objects, a whole plate, or the entire project. This is clearly distinguishable from nearby siblings like save_project, slice_project, and replace_with_stl.

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 motivation for using it ('to print them on other printers of a farm, or to share them') and explains the scope choices an agent must pick between. It stops short of naming alternatives or stating when NOT to use it (e.g. versus save_project or replace_with_stl).

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 and no output schema, the description carries the full burden; it does disclose that the result is a set of name/hex pairs, which is the key behavioral fact. However it omits what happens with an unknown preset, whether the '@BBL X1C' suffix is required, and whether this is static reference data or requires a connected printer/profile.

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

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

A single compact sentence with the resource and return shape front-loaded and a useful inline example. Nothing extraneous, though the phrasing is slightly compressed to the point of ambiguity about what 'line' means.

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 lookup with no output schema, the description covers the resource and roughly the return contents, which is close to adequate. It falls short on the exact preset string contract and failure behavior, which an agent needs to invoke it reliably.

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 0% for the single required 'preset' parameter, so the description must compensate. It partially does by giving one literal example ('Bambu PLA Basic @BBL X1C') that reveals the expected string format, but never states that preset = the filament line/preset name or whether prefix matching is allowed.

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 concrete resource and return shape: 'Official colors (name, hex) of a Bambu filament line.' An agent can tell this is a read lookup of filament color options, distinct from sibling tools like search_presets or save_filament_preset, though the differentiation is by implication rather than explicit contrast.

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 versus search_presets, list_user_presets, or get_setting, and no prerequisites or exclusions. The example preset string hints at the expected input but gives no guidance on selection.

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 delivers real behavioral detail: nesting respects the real outline including brim and brim ears, rotation is attempted in rotation_step increments, and other objects on the plate are left untouched. It omits failure modes (e.g., object not found, plate full) and whether the plate must be active.

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 action, then parameter semantics in compact clauses; every sentence carries information. It is dense in a good way, though the multi-clause run-on sentence takes some parsing.

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 6-parameter mutation tool with no annotations and no output schema, the description covers placement logic, rotation behavior, and side effects well. The gaps are the unexplained gap parameter and no indication of what is returned or how success/failure is reported.

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, and it does for most parameters: 'copies: 0 = as many as fit, N = at most N', rotate paired with rotation_step degrees, and keep_original's effect on placing the original again. Only 'gap' and the meaning of the 'object' identifier are left entirely to inference.

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: fill the free area of an object's plate with copies of it, anchored to a known analog (Bambu Studio's 'Fill bed with copies'). This is clearly distinct from duplicate_object or arrange, though no sibling is named 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?

The Bambu Studio analogy implies the use case, and the copies/rotate/keep_original notes hint at configuration, but there is no explicit guidance on when to pick this over arrange, duplicate_object, or copy_object_settings, nor any prerequisites.

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; it does disclose a genuinely useful behavioral trait — that the project is re-read if it was saved in Bambu Studio in the meantime, which signals freshness/consistency semantics. However it never states read-only safety, whether an error occurs when no project is open, or anything about payload size/cost.

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, and the core content is front-loaded. The first sentence is a dense comma-separated list that is slightly cryptic (bare 'printer, process'), but nothing is wasted.

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

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

With no output schema and no annotations, the description is the only documentation, and it partially compensates by enumerating returned fields and stating the re-read behavior. It still omits the read-only guarantee, failure modes when no project is loaded, and how large/nested the object payload is.

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 4 applies. The enumerated field list in the description is effectively return-value documentation, which the schema does not provide.

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

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

The description is a noun-phrase inventory of what the project object contains (printer, process, filament slots, plates, objects, overrides, warnings) rather than a verb+resource statement; combined with the name get_project the intent is inferable, but the agent must do the work. It does nothing to distinguish this state reader from siblings like bambu_status, list_printers, or get_setting.

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 statement of prerequisites (e.g. must a project be open), and no routing to alternatives such as bambu_status or get_setting. The only conditional sentence is about re-reading, which is behavioral rather than usage guidance.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful domain context about units (mm³), filament changes, prime tower, and infill/objects, but it does not explicitly state that it is a read-only getter or describe the output structure.

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 a single sentence with little wasted text, but it is a dense run-on with nested parentheses and a colon rather than being front-loaded with a clear action. It is concise but structurally awkward.

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 getter with no output schema, the description should clearly say what is returned. It conveys the returned concepts (volumes and multiplier) and their meaning, but it does not explicitly describe the return format or confirm that it retrieves current settings.

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 has zero parameters, so baseline 4 applies. There are no parameters whose semantics need explanation in the 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 identifies the resource as purge/flush volumes between filament slots and the multiplier, but it is written as a noun phrase rather than stating 'gets' or 'returns' current values. The verb is only implied by the tool name, so the purpose is understandable but not crisply stated.

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 only guidance is a parenthetical cross-reference to set_purge_volumes, which indicates an alternative exists but does not state when to use this tool versus the setter. There is no explicit read-vs-write guidance for the agent.

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 behavioral burden. It usefully describes the return content as the current value, its source, and the preset value, but it does not explicitly state that the operation is read-only, nor does it mention permissions, errors, or other operational constraints.

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

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

The description is a single efficient sentence with no redundant filler. It is appropriately sized for a simple getter, though it front-loads the return characteristics rather than an explicit action verb.

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 one-parameter getter without an output schema, the description partially covers return values (current value, source, preset value). However, it omits key format details and any usage context, so the agent is not fully equipped to invoke it correctly without guessing the key syntax.

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 required parameter 'key' has 0% schema description coverage, so the description should compensate. It only hints at setting categories ('print/filament/printer') but gives no key format, examples, or naming conventions, leaving the parameter semantics largely 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 identifies a specific resource (a print/filament/printer setting) and what will be returned (current value, origin, preset value). It implies a read operation through 'Current value' and is distinguishable from set_setting/reset_setting, though it does not explicitly name those siblings.

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

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

There is no guidance on when to use this tool versus alternatives such as set_setting or reset_setting. The description only states what the tool returns, leaving the agent to infer its role from the name and context.

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 disclosure burden, and it does add real behavior: auto-placement near center when x/y are omitted, and that a 3MF imports every object with parts and filament assignments. It omits critical mutation facts: whether existing plate contents are preserved or overwritten, what happens on a missing/invalid file, and whether the operation is undoable.

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 short sentences, front-loaded with the core action, and each adds information: formats, placement fallback, 3MF multi-object behavior. No filler or repetition of the name.

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 8-parameter mutation tool with no annotations, no output schema, and 0% schema coverage should explain scale, rotation, target plate, and naming. Those gaps mean an agent cannot confidently call this beyond the simplest path-only invocation.

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 all 8 parameters need the description to explain them. Only x/y (optional, auto-place) and filament (via 3MF assignments) are touched; path, plate, scale, rotate_z, and name are entirely undocumented anywhere, leaving half the surface 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?

States a specific verb and resource ('Put an STL, OBJ or 3MF on a plate') and enumerates supported formats, which implicitly separates it from add_shape, duplicate_object and replace_with_stl. It does not explicitly name a sibling, so an agent must infer the boundary rather than read it.

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 second sentence gives a clear conditional rule for the optional x/y case, which is genuine usage guidance. However, there is no guidance on when to choose this over add_shape, duplicate_object or replace_with_stl, and no stated prerequisites such as where the file must live.

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 provided, the description carries the full disclosure burden. It does clarify the geometric outcome (a face ends up on the bed) and implies a non-arbitrary deterministic result, but it says nothing about whether existing rotation is overwritten, whether the object stays in place or is re-seated on Z=0, or whether the operation is undoable.

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 the key outcome front-loaded and the parameter ordering rule appended where it is immediately needed. Nothing is redundant or padded.

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 mutation tool with no annotations and no output schema, the description covers the core semantics but leaves the mutation footprint, failure modes with non-flat or ambiguous geometry, and the post-call state unaddressed. Adequate to attempt the call, short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must supply all meaning, and it does so for the non-obvious parameter: 'face' is defined as an index ordered by descending flat-face area, with 1 being the largest. Only the 'object' parameter goes unexplained, which is acceptable since its name is self-evident.

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 ('Rotate') and resource ('an object') plus the exact resulting state ('one of its flat faces lies on the bed'), which is far more informative than a bare name restatement. It stops short of differentiating itself from nearby siblings such as orient_object, align_objects, or transform_object, so an agent still has to infer the split.

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 prefer this over orient_object, align_objects, or transform_object, nor any prerequisite such as an active object selection. The only implicit context is that an object must be flat-faced and the caller wants it bed-aligned.

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 it does disclose the shape of the return data (short names, with full machine preset names also acceptable). However it never says this is a read-only enumeration, whether results are scoped to installed/available printers, or how the list is ordered.

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

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

One short sentence with no waste, and the key fact (short names usable as printer identifiers) is front-loaded. It reads as a fragment rather than a complete statement of what the tool does, which slightly undercuts clarity.

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 tool with no output schema, describing the returned identifiers is the essential missing piece, and the description supplies it along with the interchangeability of preset names. Only the enumeration's scope and ordering are left unstated, which is a minor 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The parenthetical about full preset names is a small extra hint for callers passing the results into other tools.

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 that identifies the resource (printer short names) but never states the action; it relies on the tool name 'list_printers' to convey that a list is returned. It does distinguish the output from full machine preset names, which helps separate it from preset-related siblings, but the purpose itself is only implied.

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 hints at downstream usage ('can be used anywhere a printer is asked') but gives no guidance on when to call this versus siblings like list_user_presets, search_presets, or set_printer. No prerequisites, no exclusions, no alternative routing.

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 behavioral burden and does well: it discloses that results include inheritance, changes, cloud membership, and reverse dependencies, and warns that cloud presets can only be deleted or renamed in Bambu Studio. It stops short of explicitly stating read-only safety or permission requirements, which are implied by 'list' but not stated.

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 core action and scoped parameter, then the return contents and sibling alternative. The density is high but every clause contributes necessary context.

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 convey return meaning; it does by describing inherited preset, changed settings, cloud status, and dependent presets. For a single optional parameter list tool, this is complete enough for correct invocation.

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 0% and the schema only declares kind as an unconstrained string with default empty. The description compensates fully by naming the allowed values filament, process, printer and explaining that empty means all.

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: list the user's own Bambu Studio presets, scoped by kind. It also explicitly distinguishes this from search_presets for system presets, so an agent can select between them 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?

Explains that kind filters to filament, process, or printer, and empty returns all. It also names the alternative search_presets for finding system presets too, giving clear routing guidance.

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

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

With no annotations at all, the description carries the full burden and does reasonably well: it discloses that the tool mutates project state by adding a new plate, that the geometry is truncated to the first `height` mm, and that the result is not printable until sliced. It does not state what happens to the source plate or what identifying information the new plate gets.

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 short clauses, zero filler: the operation is front-loaded, the motivation follows, and the required next call closes it out. Every sentence 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?

For a 3-parameter mutation tool with no annotations and no output schema, the description supplies the operation, the intent, the truncation semantics and the required follow-up slicing step. An agent can call this correctly and knows what to do next.

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, and it does: `height` is defined in mm of the first layers, `plate` is implicitly the source plate whose objects are used, and `objects` is the optional explicit list. It does not mention the defaults (plate=1, height=0.8) or what an empty `objects` list means.

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 concrete verb and resource ('Add a plate with the first `height` mm of the objects') and states the purpose (bed-adhesion / first-layer check). It is clearly distinct from sibling test generators like make_temperature_tower or make_flow_test, though it never names those alternatives 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 says when to use it ('a short print to check bed adhesion and the first layers before a long print') and gives the required follow-up call: slice_project(plate=<new plate>). That is a clear workflow, but there are no explicit exclusions or prerequisites (e.g. when to prefer a full slice preview instead).

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. It does disclose the side effect of adding a plate of objects and explains how to read the results (smoothest top = best), but omits whether it creates a new plate or modifies the current one, what filament/printer prerequisites apply, and whether printing the plate is required.

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 purpose, then the procedural detail in order of use. Slightly extra prose in the second sentence, but every line contributes actionable 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?

Adequate for a tool with no annotations, no output schema and an undocumented schema, since it covers the calibration workflow and most parameters. However, the unexplained 'filament' parameter and the unstated plate-creation side effect leave an agent guessing about prerequisites.

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, and it does well for three of four parameters, giving concrete low/high/step values for both passes. The 'filament' slot parameter (default 1) is never explained, leaving one 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: 'Add a plate of flow-rate squares for a filament slot', each engraved with a different flow modifier. An agent can tell this is a calibration-plate generator, distinct in substance from towers or retraction tests. It does not explicitly contrast with the closely related make_max_flow_test, so sibling differentiation is only implicit.

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 a concrete two-pass workflow ('Pass 1: -20..+20 step 5. Pass 2: around the best one') plus a selection criterion for the resulting squares. That is strong procedural guidance for how and when to use the tool, but no explicit alternatives or exclusions (e.g. when to prefer make_max_flow_test) are named.

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 load; it does disclose a key side effect (writes a separate project file, leaves the open project untouched). It does not say whether the new project is opened/activated, what it returns (name/id), how long the test takes, or what printer/material prerequisites exist.

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 purpose and the non-destructive scoping note, then the mechanics, then interpretation guidance. The interpretation sentence is long but earns its place by telling the agent how to convert the result into a setting.

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-parameter calibration generator with no annotations and no output schema, the description covers intent, side effects and result interpretation reasonably. It leaves unclear what the tool returns (project reference) and the exact semantics of the undocumented numeric parameters.

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 0%, so the description must compensate. It does partially: it establishes that low/high/step are volumetric speed Q values in mm³/s and that the filament parameter refers to a filament slot. But it never maps names to parameters explicitly or explains the units/meaning of `step` or how a slot index is chosen.

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: generates a max volumetric speed test as a separate project file with single-wall cylinders. It also clarifies scope (the open project is not changed), which an agent needs. It doesn't explicitly name sibling calibration tools (make_flow_test, make_vfa_test, make_pa_tower), leaving the agent to infer the distinction.

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?

"Default range: around the filament's current limit" and the 90% recommendation give useful operational context for choosing values and interpreting results. However, there is no explicit when-to-use/when-not guidance relative to make_flow_test or make_vfa_test, which are the obvious alternatives an agent would weigh.

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 meaningful work: it discloses the generated geometry, the K-value progression, how to read the result, and a non-obvious side constraint (the printer's automatic flow dynamics calibration must be off when the job is sent). Gaps remain: it does not say whether the plate is added to the current project, whether existing plates are affected, or whether a printer must be selected first.

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 what is created, then the interpretation formula, then the caution. Almost no filler, though the pronoun in 'When sending it' requires the reader to infer that 'it' means the sliced job or plate.

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-parameter object-creation tool with no annotations and no output schema, the description covers the what and the how-to-read but leaves the `end` and `filament` parameters and the scope of the side effect (current project? plate index?) unspecified. Enough to call it correctly in the common case, not enough to be confident across cases.

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 0%, so the description must explain all four parameters. It gives real meaning to `step` ('the K value grows by `step` every millimeter') and embeds `start` in the formula, but `end` is never mentioned and its meaning is genuinely ambiguous against the formula (max K? max height?), and `filament` is not addressed at all. Two of four parameters remain undocumented 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?

States a specific verb and resource: 'Add a plate with a pressure advance (flow dynamics) tower', plus a concrete physical description ('a thin square tube printed fast'). The resource name alone distinguishes it from make_temperature_tower, make_flow_test, and make_vfa_test, but it never explicitly says how it differs from those calibration siblings.

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

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

Usage is implied rather than stated: the interpretation guidance ('Find the height with the sharpest corners and no gaps') tells the agent what the output is for, and there is one explicit operational instruction about turning off automatic flow dynamics calibration when sending. However, there is no explicit statement of when to choose this tower over make_flow_test or make_max_flow_test, nor any prerequisites.

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 a key non-obvious behavior: multiple separate projects are created because Bambu printers cannot change retraction mid-print, and the outputs must be printed sequentially. It also names the follow-up mutation path. It omits whether existing projects are affected, whether projects are saved/opened, and what the call returns.

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, front-loaded with the purpose and followed by the workflow and the exact follow-up calls. The parenthetical justification earns its place because it explains the multi-project design. Minor slack in the run-on structure of the last sentence.

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 2-parameter, annotation-free tool with no output schema, the description covers the purpose and the post-test action but not the call's own outcome: how many projects/plates are created, whether they are named, whether they are saved or opened, and what the caller gets back. An agent would still need to guess at the side effects before invoking it.

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 0%, so the description must compensate. It implies the `lengths` array ('one project per retraction length') and hints that `filament` is the slot ('for a filament slot'), but never states units, ordering, or what happens when `lengths` is null (the default), leaving the most important defaulting behavior 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 names a specific verb+resource: it generates a stringing/retraction test with one small project per retraction length for a filament slot. That is clearly distinguishable from the sibling test generators (make_temperature_tower, make_flow_test, make_pa_tower, make_vfa_test). It stops short of explicitly contrasting itself with those siblings, but the purpose is 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?

It gives a concrete workflow: print the tests one after another, pick the shortest length with no strings between the two pillars, then apply it via set_setting('filament_retraction_length', value, slot) or save_filament_preset. That is strong when-and-how guidance. It does not state prerequisites (e.g. a printer/AMS/filament must be selected) or when to prefer another test tool instead.

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 does real work: it discloses the generated geometry (one 8 mm block per temperature, hottest at the bottom, engraved temperature and bridge) and how defaults are derived ('filament's temperature +15 down to -25 °C, within its allowed range'). It does not say whether it appends to the current plate or creates a new one, which would be valuable for a plate-creating mutation.

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 compact sentences that front-load the action and follow with geometry, defaults, and evaluation advice. Dense with little waste, though the final sentence is workflow advice rather than tool-selection 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 4-parameter, no-annotation, no-output-schema tool, the description covers purpose, generated geometry, and default behavior reasonably but leaves parameter semantics largely undefined and says nothing about what the call returns or how it interacts with plates. 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 must carry all four parameters, but it only gestures at 'filament' and at the default temperature span. The meanings of start, end, and step are never defined, and the stated defaults ('+15 down to -25 °C') do not map cleanly onto the schema defaults of start=0, end=0, step=5, leaving the agent uncertain whether 0 means auto or literal.

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: 'Add a plate with a temperature tower for a filament slot', plus concrete geometry (8 mm blocks, hottest at bottom). It does not explicitly distinguish itself from the many sibling test generators (make_pa_tower, make_vfa_test, make_flow_test, make_retraction_test), though 'temperature tower' implies the difference.

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 useful post-print guidance ('Pick the block with the best bridge, surface and least stringing') and explains the default range, which implies when the tool is appropriate. But there is no explicit selection guidance versus the sibling test tools nor stated prerequisites such as needing an existing plate or filament slot.

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 behavioral burden. It discloses that a plate is added and describes the generated blocks and engraved speed labels, but it does not mention project state requirements, side effects on existing plates, or permissions.

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 action and includes only relevant details about the test structure, interpretation, and Bambu Studio distinction. The prose is dense and nested in one long parenthetical, but no sentence is clearly 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 calibration-test generator with no annotations, no output schema, and 0% schema description coverage, the description gives strong domain context and interpretation guidance. It remains incomplete on parameter semantics, especially filament and step, and on prerequisites for adding a plate.

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 four undocumented parameters. It explains the start-to-end speed range and the per-speed block concept, but never explains the step parameter explicitly or the filament parameter at all.

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: add a plate containing a VFA test, and explains the generated block structure. It does not explicitly name or differentiate itself from sibling calibration tools such as make_flow_test or make_temperature_tower, but the purpose is otherwise 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?

Provides useful post-test guidance: inspect long faces with side lighting and choose the fastest speed without ripples for outer_wall_speed. It does not explicitly say when to choose this test over sibling calibration tests or what prerequisites are required.

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

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

With no annotations, the description carries the full burden and does well: it discloses units (plate mm), the sign convention (negative axis gap = overlap along that axis), and that shared volume is only reported when objects overlap. It never explicitly states the operation is non-mutating, but 'measure' plus the read-only framing makes that clear enough.

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 dense sentence that front-loads the core purpose before listing return values. Every clause carries information, though the parenthetical nesting makes it slightly harder to parse on first read.

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, so the description must describe the return values, and it does so thoroughly — minimum gap with location, center distance, per-axis box gaps, and overlap volume. Complete enough for an agent to call it and interpret results; only the interaction with measure_object remains 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?

Schema description coverage is 0%, so the description must compensate, and it does for the non-obvious parameters: it explains that part_a/part_b select sub-parts and that reusing the same object with two parts measures internal clearance. object_a/object_b are self-evident from their names; the only gap is part-name format or behavior on invalid part names.

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 — distance between two objects or two parts — and enumerates exactly which measurements are produced. It implicitly distinguishes itself from the sibling measure_object by requiring two operands, but never names that sibling or says so 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?

The parenthetical gives one concrete usage recipe: pass the same object twice with two different parts to get the clearance between them. Beyond that there is no guidance on when to prefer this over measure_object, or what preconditions (both objects on the same plate?) apply.

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 substantial work: it discloses the complete measurement set returned, the conditional cross-section behavior triggered by z >= 0, the fallback rule that thin-wall detection uses the nozzle line width unless min_wall is given, and that locations/heights are reported alongside findings. It does not state that the operation is non-destructive or anything about cost/runtime, which keeps it from a 5.

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

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

It is a single long run-on sentence built from stacked clauses, so the reader must parse a wall of commas to extract the report contents. The core purpose is front-loaded, and every clause carries information, but better enumeration/line breaks would materially improve scanability.

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, so the description must describe return values, and it does so thoroughly — down to island length/width/thickest point and hole dimensions. Combined with the parameter semantics, an agent has enough to call this correctly; only the absence of any safety/side-effect statement leaves a small 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 0%, so the description must compensate, and it largely does: `part` is defined ('or its part `part`'), `z` is given meaning (cross-section height above bed, with the negative/default case implied), and `min_wall` is defined (wall thickness threshold in mm, defaulting to nozzle line width). Only `object` is left to inference, which is acceptable given its name.

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 opens with a specific verb and resource ('Measure an object ... in plate mm') and enumerates exactly what is reported: dimensions, position, per-part volume/surface, bed-contact area, joint clearances, thin walls. An agent can distinguish it from measure_between by the object-centric scope, though the sibling is never named.

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 implied by the content ('if you want measurements of an object'). There is no explicit statement of when to prefer this over measure_between, no prerequisites, and no exclusion of cases. The only real conditional guidance is for `z` (cross-section only when z >= 0), which is parameter-level, not tool-level.

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 behavioral burden well: it discloses that positions are retained, parts keep filament and painting, and the merged object inherits the first object's settings with differing settings listed. It stops short of stating reversibility, whether originals are removed, or any permission/constraint failures.

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 action is front-loaded in the first sentence, and the analogy and settings-inheritance details each add useful information. It is somewhat dense but not padded.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema coverage, the description explains the merge behavior but omits parameter documentation and key constraints such as minimum object count, handling of objects on different plates, and undo/irreversibility.

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%, and the description never explains the 'objects' parameter's expected format or the optional 'name' parameter. It only indirectly hints that array order matters via 'the merged object takes the first object's settings.'

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: 'Join objects of the same plate into one object with several parts.' The Bambu Studio Assemble analogy and model/base example make the operation concrete, though it does not explicitly distinguish itself from siblings like boolean_objects or split_object.

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 usage context: use when objects should move and print as one while each part keeps its filament and painting, such as a model and a differently colored base. It does not state when not to use it or name alternative tools.

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 behavioral burden. It does not clarify whether mirroring modifies the object in place, creates a mirrored copy, or affects linked instances, nor does it mention undo behavior or any required selection state. The axis and center semantics are useful but insufficient for a mutation tool with zero annotation coverage.

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

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

The description is a single front-loaded sentence with no wasted words. The operation and axis options are stated immediately and nothing is repeated from structured fields.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema parameter coverage, the description is too thin. It omits whether the operation mutates in place, what happens on failure, and what 'object' refers to, leaving the agent without enough context to invoke the tool 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%, so the description must compensate. It meaningfully explains the axis parameter as x, y, or z, but it never explains what kind of identifier 'object' expects or how the default axis behaves. The most important parameter remains 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 a specific verb and resource: 'Mirror an object across its own center', and adds the scope 'axis x, y or z'. It is clearer than the bare name, but it does not explicitly distinguish the tool from nearby siblings such as transform_object, orient_object, or duplicate_object.

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 no when-to-use guidance, no prerequisites, and no alternatives. It implies the operation is for mirroring but never tells the agent when to choose it over transform_object, duplicate_object, or align_objects.

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 behavioral burden. It usefully discloses that plate moves preserve x/y when supplied and otherwise choose a free spot, but it does not cover prerequisites, mutation side effects, undo behavior, or what the call returns.

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 definition is a single compact sentence that front-loads the main action and then efficiently enumerates the supported modes. There is no filler.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description is adequate but incomplete. It lacks details on coordinate units, default plate semantics, preconditions, and side effects.

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, and it does explain the roles of object, x/y, dx/dy, rotate_z, and plate. It still omits coordinate units, constraints, and what the default plate value 0 means.

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 ('Move an object') and enumerates the supported move modes: absolute x/y, relative dx/dy, Z rotation, and plate transfer. It is clear what the tool does, but it does not explicitly distinguish itself from related siblings such as transform_object, align_objects, or arrange.

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 explains when to use the different parameter modes, such as absolute x/y versus relative dx/dy versus plate transfer with optional x/y preservation. However, it gives no explicit guidance about when to choose this tool instead of transform_object, align_objects, or arrange.

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. It usefully discloses that filaments map to AMS slots in order, that names without '@...' are auto-matched, and that bed type is inherited from Bambu Studio settings — but it says nothing about side effects on the current project, permissions, or what the call returns.

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 purpose in one sentence, and the filaments example earns its place by showing the exact object shape. The trailing sentence about bed type and set_setting is slightly tangential but remains relevant; there is little waste.

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

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

For a creation tool with four parameters, no annotations, and no output schema, the description covers the trickiest input (filaments) but leaves key gaps: printer/process semantics and what happens to the currently open project. Adequate but 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?

Schema coverage is 0%, so the description must compensate for four parameters. It does this well for filaments (format, example, matching rule) but leaves printer (name vs. serial?), process (empty default meaning), and name undocumented, so the compensation is only partial.

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: 'Start an empty project.' An agent can tell this creates a new project rather than fetching or saving one. It does not explicitly contrast with the sibling open_project, so it stops short of full sibling differentiation.

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 statement of when to use this versus open_project, or of prerequisites such as whether an existing unsaved project is discarded. The only 'guidance' is the aside on changing bed type via set_setting, which is a parameter detail rather than usage guidance.

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

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

With no annotations, the description carries the burden and does disclose a genuinely non-obvious trait: Bambu Studio re-slices on Slice plate and does not reuse the slicing done here, plus the default-project fallback behavior. It still omits whether the studio must be installed/running, whether the call blocks, and failure behavior for an invalid path.

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 action and default, followed by the caveat and the alternative. Dense but every sentence carries information; 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?

There is no output schema or annotations, so the description must cover everything, and it explains purpose, default, and the re-slicing caveat but not the return value or error conditions. Adequate to call, incomplete for predicting what happens.

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?

There is one parameter with 0% schema description coverage, and the description only explains its default ('last saved project, else the last sliced one'). It never states that path must point to a .3mf file, whether relative or absolute paths are accepted, or what happens with a malformed path.

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 ('Open a .3mf in the Bambu Studio window') and states default behavior when no path is given. It implicitly separates itself from the in-app open_project and from send_to_printer, but never names open_project as the sibling to avoid, so differentiation is only partial.

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 concrete routing rule: for a plate already sliced and ready to print, use send_to_printer(via='bambu_studio') instead. That is clear context for the alternative, though it does not state explicit when-not conditions (e.g., when to use open_project instead of sending to the external app).

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 disclosure burden and does add real value: it explicitly declares the source file is never mutated and warns that some content may not be carried over ('what could not be carried over'). It omits what happens to any currently-open project state, what errors occur on an invalid/corrupt path, and whether loading has side effects on the session.

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 short sentences with no filler; the core action and accepted format come first, followed by the immutability guarantee and the return-behavior note. Every sentence carries distinct 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?

The absence of an output schema is partly offset by the description naming the return payload (project summary plus un-carried-over items). For a load operation that mutates application state, the description should say whether the current project is replaced or unsaved work is affected, and what happens on failure.

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 0% for the single 'path' parameter, so the description must compensate, and it does: it constrains path to a .3mf file saved by Bambu Studio or downloaded from MakerWorld, narrowing the valid input domain beyond a bare string. It does not specify absolute vs relative paths or whether the file must be local, keeping it below 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 (open) and a specific resource (a .3mf authored by Bambu Studio or MakerWorld), which pins down both the action and the accepted input format. It contrasts with save_project, but does not disambiguate from the similarly-named sibling open_in_bambu_studio or from get_project, which an agent could reasonably confuse with a load operation.

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 line 'The file is never modified: save_project writes a new file' implicitly tells the agent to use save_project for persistence rather than this tool. However, there is no explicit statement of when to prefer this over new_project, get_project, or open_in_bambu_studio, so the routing guidance is inferred 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?

With no annotations, the description carries the full burden and largely meets it: it discloses the optimization objectives (support area, bed area, height), the overhang threshold semantics, that three candidates plus current values are returned, and that apply=False is a dry run. It stops short of stating irreversibility, undo behavior, or what 'apply' does to the object's existing transform beyond implication.

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 optimization criteria, return behavior, and parameter semantics are packed into three compact sentences with no filler. The scoring logic is front-loaded before the parameter-specific details.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers return values, optimization criteria, and the dry-run mode. Remaining gaps are the required object identifier and prerequisites, but nothing critical to invoking it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description meaningfully compensates for three of four parameters: overhang_angle is defined via faces leaning more than that many degrees from vertical, choice is explained as selecting candidate 2 or 3, and apply is explained as compare-only when false. The required 'object' parameter's identifier format is never described.

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 ('Turn an object the way up it prints best') and anchors it to a known behavior ('like Bambu Studio's Auto orientation'). This clearly distinguishes it from siblings like lay_flat, arrange, and transform_object, which either flatten, pack, or apply explicit transforms.

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 usage context: apply=False only compares, choice=2/3 selects another candidate, and 'Look at preview_plate afterwards' supplies an explicit follow-up step. It lacks explicit routing away from alternatives such as lay_flat, but the intended workflow is clear.

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 discloses that triangles crossing a band edge are split so the edge is sharp, that clear=True removes paint, and that part scoping is possible. It leaves open whether existing paint is overwritten, and what prerequisites (loaded project/object) apply.

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 verb and resource, and every clause adds real information. It is one dense run-on with nested parentheticals, which costs some readability, but there is essentially no waste.

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

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

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the core mechanics, region semantics and the natural follow-up verification step. Missing pieces are overwrite behavior and error/permission conditions, which keep it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and it does: it explains z_from/z_to as mm from the object bottom with the non-obvious z_to=0 = to the top convention, enumerates facing values, defines angle in degrees from vertical, and explains filament's role with paint='color'. Only the obvious 'object' parameter is left implicit.

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 ('Paint a region of an object') and enumerates all paint modes, which clearly separates it from generic sibling setters. It never names an alternative tool it could be confused with, so it stops short of full sibling differentiation.

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?

Implicitly clear when to use it (region-based painting vs. whole-object settings) and it documents the removal path via clear=True plus a follow-up step ('Look at preview_plate (colors) afterwards'). It does not say when NOT to use it or point to alternatives like set_object_filament or add_modifier.

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 whole burden. It usefully discloses rendering behavior (filament colors, zoom framing extrusions vs. whole bed) and the slice-project dependency, but never states that the operation is read-only/non-destructive, what the error looks like if slicing hasn't run, or how the image is delivered.

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 what the tool returns, then the prerequisite, then parameter selection rules, then rendering detail. Dense, zero filler, no restating of the name.

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 no-annotation, no-output-schema tool the description supplies what an agent needs: the return is an image, the prerequisite is named, and selection semantics are covered. The unexplained plate parameter and unstated non-destructiveness are the remaining holes.

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 0%, so the description must compensate, and it largely does: it defines layer numbering (1 = first), z as height in mm, and both zoom states with the default. Only 'plate' (default 1) is left completely unexplained, which is the one gap preventing 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?

It states a concrete verb+resource: renders an image of a single sliced layer viewed from the top, with a styling detail (extrusions in filament colors). That clearly separates it in spirit from the plate-level sibling preview_plate, but it never names that sibling, so the differentiation is inferred rather than stated.

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?

'needs slice_project first' gives the agent an explicit precondition, which is the main usage trap for a preview-after-slice tool. There is no explicit guidance about when to prefer preview_plate or preview_layer, so it falls just short of full alternatives coverage.

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?

It provides specific behavioral details beyond the schema, such as clarifying that objects are shown in 'filament colors (painted colors too)' and detailing the scope of labeling ('ID and name on 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?

The description is dense and lacks clear structure, reading more like a technical spec or bulleted requirements list than a coherent explanatory tool definition.

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?

While it is complete in describing the visual output of the image, it is weak on providing broader context regarding the 'plate' itself (e.g., if it's a configuration template or a print job reference).

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?

Given the 0% schema description coverage, the description excels at defining the semantics of each parameter. It specifies valid values for 'view' ('iso | top'), the function of 'zoom' ('frame the objects'), and the contents of 'labels'.

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 clearly states that the tool generates an image of a plate with its objects, which defines its core function. However, it doesn't explicitly state the primary goal (e.g., 'to visualize layout').

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 focuses entirely on the output settings (view, zoom, labels) rather than providing guidance on when to use this tool versus other visualization tools (like preview_layer).

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 at all, the description carries the full behavioral burden; it does useful work by declaring read-only semantics, the cloud-mode requirement, and the caveat that the image is dark when the chamber light is off. It omits failure behavior (printer offline, unsupported model) and says nothing about latency, caching, or how the image is returned.

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 identity, then use cases, then caveats, then the parameter note — every clause carries information. The final 'max_size' sentence feels appended rather than integrated, which slightly hurts flow but not content.

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 tool with no annotations and no output schema, the description covers purpose, hardware scope, prerequisite, and the main gotcha (dark image). It could add what an error/offline case looks like, but an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter has no schema description, so the description must compensate — and it does, defining max_size as 'longest side in pixels', which gives the agent enough to choose a value alongside the schema's default of 1280. Only the absence of guidance on sensible ranges keeps it below 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?

The description opens with a concrete verb+resource: a live picture from the printer's camera, scoped to P1 and A1 series hardware. That is clearly distinct from siblings like printer_status, preview_plate, or printer_files, though it never names a sibling explicitly to route the agent.

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 states clear use cases — checking how a print is going, detecting a part that came off or 'spaghetti', seeing what is left on the bed — plus the prerequisite that the printer must be in cloud mode. It stops short of saying when not to use it (e.g. prefer printer_status for non-visual checks).

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 state read-only behavior, the cloud-mode connectivity requirement, sort order (newest first), and what is returned. It doesn't cover what happens if the printer is offline or how `limit` affects results, so some behavioral ground is left uncovered.

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 return shape and folder semantics; each parenthetical earns its place by defining a category. Slightly dense phrasing ('name, size and date and the total per folder') but no wasted content.

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, so the description must describe results, and it does (name, size, date, per-folder totals, sorted newest first). The one real gap is pagination/limit behavior for a list tool that caps at 30 by default.

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 entirely. It effectively defines the `kind` values via the three folder categories, but `limit` is never mentioned despite having a default of 30, and it doesn't clarify that 'all' is a valid kind.

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 the resource (files on the printer's SD card) and the returned fields (name, size, date, per-folder totals) plus sort order, which clearly separates it from siblings like delete_printer_files or download_printer_file. The verb is implicit ('Files on...' rather than 'List files'), but the enumeration of the three folder categories makes the scope 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?

The parenthetical definitions of timelapse/prints/thumbnails implicitly guide selection of the `kind` value, and 'works with the printer in cloud mode' gives a prerequisite. However, it never names alternatives (download_printer_file, delete_printer_files) or states when to prefer them, so usage 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 behavioral burden and does so well: it declares read-only behavior, states that nothing is sent except a status request, explains cloud-mode compatibility, and clarifies polling and age_s semantics. It also describes the meaning of warnings and unknown AMS spool values.

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

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

The description is front-loaded with the core purpose and return contents, and the polling and non-mutating behavior are clearly stated. It is somewhat long because it enumerates many status fields, but the details are relevant 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?

There is no output schema and no annotation layer, so the description must explain both behavior and return contents. It does that thoroughly for a status tool, including state, job, progress, temperatures, AMS details, warnings, read_at, and age_s, leaving little ambiguity for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so parameter semantics are inherently simple and the baseline is 4. The description does not need to explain parameter meanings, and it appropriately focuses on what the returned status contains instead.

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 clearly states a specific verb and resource: read-only status of the printer on the local network, with a detailed list of what status includes. It is more specific than a tautology, but it does not distinguish itself from closely related siblings such as bambu_status or list_printers.

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 useful context that the tool works in normal cloud mode and that only a status request is sent, but it does not explicitly say when to use this tool instead of bambu_status or other printer-related siblings. Usage is implied rather than routed.

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?

There are no annotations, so the description carries the full behavioral burden. It discloses one effect—the brim reverts to the project's brim type—but does not state whether the removal is destructive or irreversible, what permissions are needed, or what errors may occur.

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 definition is a single front-loaded sentence with no wasted wording. It states the action first and then the resulting brim state.

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 one-parameter tool with no output schema, the description covers the core action and its main effect. However, given zero schema description coverage and no annotations, it leaves gaps around object identifier semantics and mutation safety.