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 the handoff mechanism, the cloud-mode dependency, and that no print is triggered. However, it omits prerequisites (signed-in app state required, what happens if the app is not running), failure behavior, and whether the operation leaves any persistent 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?

Two tight sentences, zero filler, and the core action is front-loaded ahead of the disambiguating caveat. 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?

No output schema and no annotations mean the description must stand alone; it adequately covers purpose, mechanism, and the 'no print' constraint. It is slightly thin on prerequisites and error conditions for a tool that depends on an external app being available.

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

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

Schema coverage is 100%, so the schema already documents name, version, and file_path, including file extensions. The description only loosely echoes the accepted file types via 'G-code or sliced 3MF file' and adds no new meaning for name or version. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb ('Open') and resource ('existing G-code or sliced 3MF file') plus the mechanism ('Bambu Connect official URL scheme'). This clearly distinguishes it from siblings like upload_file, print_3mf, and start_print, which move or execute files rather than hand them off.

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 frames the tool as a 'cloud-mode handoff and does not start printing by itself,' which tells the agent when this tool is and is not the right choice versus print tools. It stops short of naming a specific alternative (e.g., print_3mf/start_print) for when printing IS desired.

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, yet it does not disclose that the tool can start a bridge process/execute a command (connect=true, bridge_command), that per-call command overrides require MCP_ALLOW_EXECUTABLE_ARG=1, or what a successful/failed probe reports. Only the vague verb 'probe' hints at side effects.

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

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

A single, front-loaded sentence with no padding. It is efficient, though dense with product-specific jargon that slightly raises interpretation cost.

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 tool with six optional parameters, no annotations, and no output schema that can launch an external bridge process, the description omits the most decision-relevant facts: side effects of connect, return/result shape, failure modes, and prerequisites. What an agent needs to call it confidently is largely missing.

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

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

Schema description coverage is 100%, so all six parameters (connect, user_info, timeout_ms, country_code, bridge_command, bambu_network_config_dir) are already fully documented by the schema. The description adds no syntax, default, or interaction detail beyond it, which is the expected baseline of 3 when the schema does the work.

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 pair (inspect/probe) and resource (the FULU OrcaSlicer-bambulab BambuNetwork bridge runtime), with an additional scope note about cloud and restored BambuNetwork printing. An agent can tell this apart from an ordinary network call, but the description never names the sibling tools (bambu_network_call, print_3mf_bambu_network) it should be preferred over.

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 at all: no statement of when to inspect versus when to actually invoke bambu_network_call or print_3mf_bambu_network, and no hint about when the connect probe is appropriate versus a plain status read. Usage is only implied by the word 'probe'.

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 hints that arbitrary bridge methods are invoked ('raw'), but never discloses side effects, permission requirements, risk of destructive methods, or return/error behavior. For an unconstrained low-level call tool this is a significant 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?

A single front-loaded sentence that conveys the core action and the agent-injection option with no filler. It is tightly sized, though the dense jargon reduces immediate readability.

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 8-parameter power tool with no annotations and no output schema, the description leaves too much unsaid: which methods are safe, how errors surface, or how it relates to the higher-level Bambu tools. The safety-neutral annotation gap makes this incompleteness more costly.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters in detail. The description adds only a marginal restatement by noting the optional agent injection into the payload. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a clear verb (call) and resource (raw FULU OrcaSlicer-bambulab BambuNetwork bridge method), and the scope term 'raw' signals it is a low-level escape hatch. It implicitly separates itself from status-oriented siblings like bambu_network_bridge_status, but never names an alternative explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, nor any reference to the higher-level siblings (print_3mf_bambu_network, start_print). An agent is left to infer that this is the fallback for methods not covered elsewhere, without any statement to that effect.

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 the key traits: 'Calls can modify the active Blender scene and are never automatically retried.' That mutation warning and no-retry disclosure are exactly the safety context an agent needs. It omits auth/permission or concurrency details, so not a full 5.

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

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

Three sentences, front-loaded with the core action and the discovery prerequisite. Each sentence carries information, though the mid-sentence mention of execute_blender_code's parameters is slightly tangential to the tool's own purpose.

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, but the description compensates by stating it preserves 'its full MCP content and errors.' Combined with the mutation and no-retry disclosures and a documented timeout default, an agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents tool_name, arguments, and timeout_ms. The description only lightly augments this, noting that execute_blender_code accepts Python code and user_prompt. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Call a discovered tool on the configured Blender MCP server.' It names the sibling it depends on (blender_mcp_status) and clarifies the proxy nature of the tool, distinguishing it from the actual Blender tools it dispatches to.

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 a clear prerequisite flow: 'Discover tool schemas with blender_mcp_status first,' and names a concrete example (execute_blender_code). It does not, however, explain when to prefer this over blender_mcp_edit_model, leaving one sibling relationship implicit.

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 notable traits: output is verified, existing scene objects are preserved, and it needs a shared filesystem and Object Mode. It omits the dry-run default (execute=false validates only), though that is covered in the schema.

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

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

Two dense sentences that front-load the core pipeline and guarantees before the legacy-bridge caveat. The legacy sentence is niche but relevant; little is wasted.

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

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

For a 7-parameter mutation tool with no output schema, the description supplies the key operational constraints (filesystem, Object Mode, non-destructive scene handling) and implies an export flow. It could state the validate-vs-apply default behavior more prominently, but coverage is adequate.

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

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

Schema description coverage is 100%, so every parameter (including the execute flag, operations format, timeout, and overwrite protection) is already documented. The description adds no parameter-level detail beyond that, making the baseline 3 appropriate.

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

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

States a specific verb chain and resource: import/edit/export a local STL through Blender MCP, which distinguishes it from siblings like blender_mcp_call, blender_mcp_status, and get_stl_info. It does not explicitly name a sibling alternative, but the scope 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 prerequisites (shared local filesystem, Blender Object Mode) and notes a legacy bridge mode, which is real context. However, it never says when to use this tool versus blender_mcp_call or the other STL-manipulation siblings, so routing is left to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait that connecting does not mutate the scene, which is valuable. However, it omits other side effects of connect (e.g., that it initializes/starts a stdio process and may block up to the timeout) and any error/auth behavior, leaving meaningful 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?

Two tightly written sentences, front-loaded with the primary action, and the routing note placed second. Every clause earns its place with no redundancy.

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

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

With only two fully documented parameters and no output schema, the description covers purpose, mode selection, and the non-mutating trait adequately. It could say a bit more about what 'discover tools and schemas' returns or how connection failures surface, but nothing critical is missing.

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

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

Schema description coverage is 100%, with both 'connect' and 'timeout_ms' fully documented including defaults and bounds, so the schema does the heavy lifting. The description adds no syntax or format detail beyond what the schema already provides, which is the expected baseline.

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

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

States specific verbs and resource: inspect the Blender MCP configuration, or connect and discover the remote server's tools and schemas. It also explicitly routes to blender_mcp_call for scene inspection, distinguishing it from the call/edit 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?

Gives clear context on the two modes (inspect vs. connect) and clarifies that connecting does not edit the scene. It names an alternative path (get_scene_info via blender_mcp_call) for checking the Blender addon, but does not state when NOT to use this tool beyond that.

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 the return format (base64 JPEG), the optional disk write, the cold-start delay risk behind timeout_ms, and that ffmpeg overrides require MCP_ALLOW_EXECUTABLE_ARG=1. It stops short of describing error behavior for unsupported models or auth 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?

Three front-loaded sentences, zero filler, and the primary action plus return contract lead. The protocol routing could arguably move to a schema note, but its placement is still 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 an 8-parameter, no-annotation, no-output-schema tool, the description supplies the essential return contract (base64 JPEG, optional disk write) and the transport gotchas. It is nearly complete, lacking only failure-mode detail for unsupported models or token/auth errors.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters, including save_path, timeout_ms, and ffmpeg_path. The description re-states the save_path and base64 return behavior, adding only marginal value beyond the structured fields, which is the baseline-3 case.

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: 'Capture a single JPEG frame from the printer's chamber camera.' It also names the protocol split by model, which no sibling tool covers, so an agent can distinguish it immediately from the print-file and STL manipulation 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?

The model-to-transport mapping (A1/P1 vs X1/P2S/H2/X2D) is implied usage context, but the description never states when an agent should reach for this tool versus the status/inspection siblings, nor any exclusions or prerequisites beyond the protocol 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?

No annotations are provided, so the description must fully disclose behavior. It states 'cancel' but does not clarify whether the job is removed from the queue, if it can be resumed, or if any confirmation is required. The lack of detail on side effects reduces transparency for an agent.

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, concise sentence that efficiently communicates the purpose. No unnecessary words or repetitions.

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 cancel action with three optional parameters and no output schema, the description is minimally adequate. However, it lacks mention of prerequisites (e.g., an active job), irreversibility, or what happens to the job data, leaving some gaps for an agent.

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

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

Schema coverage is 100%, and each parameter has clear descriptions (hostname, serial, token) with defaults from environment. The description adds no extra meaning beyond the schema, meeting the baseline for high coverage.

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 the action 'Cancel' and the resource 'current print job on the Bambu Lab printer'. It distinguishes from sibling tools like pause_print and resume_print by implying finality, though it could explicitly note that it terminates rather than pauses.

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 tool versus alternatives like pause_print or start_print_job. Context signals indicate ample siblings, but the description does not specify that this is for stopping a running job irreversibly or that it should be used after confirming no further output is needed.

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 provided, so description carries full burden. It mentions translation but does not disclose whether the operation modifies the file in-place, returns a new file, or has other side effects.

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?

Single, front-loaded sentence with no redundancy. Could be slightly more structured, but effective for a simple operation.

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?

Lacks details about return values or file handling. With no output schema and no annotations, the agent is left guessing what happens post-operation.

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

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

Schema coverage is 100% for the single parameter (stl_path), but the description adds no extra meaning beyond the schema's 'Path to the STL file'. Baseline 3 is appropriate.

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

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

The description clearly states the action ('translate') and resource ('model'), specifying the exact goal: geometric center at origin. It distinguishes from sibling tools like rotate_stl or scale_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?

No explicit when-to-use or when-not-to-use guidance. Sibling tools like lay_flat or merge_vertices are not mentioned, leaving the agent to infer 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?

No annotations provided, so the description carries full burden. It mentions using an MQTT command but does not disclose side effects, required printer state, or whether it clears all errors or specific ones.

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 sentence, front-loaded with the verb 'clear', no wasted words.

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 tool with 3 optional parameters and no output schema, the description is minimal but functional. However, it lacks explanation of 'HMS errors', what clearing entails, or examples. Slightly below adequate.

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

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

Schema coverage is 100% with each parameter described. The description adds no extra meaning beyond the schema (host, serial, token with defaults). Baseline 3 is appropriate.

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

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

The description clearly states the tool clears HMS or print error state on a Bambu Lab printer using a specific MQTT command. It distinguishes from sibling tools like cancel_print, pause_print, and resume_print.

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 tool versus alternatives. Given many printer-related siblings, the description lacks context about the appropriate scenario (e.g., after a print error) or conditions.

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 fully discloses behavior: it deletes via FTPS, requires explicit confirmation (confirm:true), restricts directories, and blocks path traversal. This is comprehensive for a deletion tool.

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

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

Four concise sentences, each delivering key information: action, destructive guard, directory restriction, and path traversal check. No redundancy; well front-loaded.

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 description covers all essential aspects: operation, safety, constraints. A minor gap is lack of error handling info (e.g., file not found), but overall it is sufficiently complete for a file deletion 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 100%, and the description adds significant value: it clarifies default path for bare names ('cache/') and provides usage examples (e.g., 'timelapse/foo.mp4'). The confirm parameter behavior is clearly explained.

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 the action ('delete a file'), the target ('Bambu Lab printer's SD card'), and the mechanism ('via FTPS'). It effectively distinguishes this tool from siblings like 'list_printer_files' and 'upload_file'.

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

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

It provides important usage constraints: destructive nature requiring confirm:true, allowed directories (cache/, timelapse/, logs/), and rejection of path traversal. It does not explicitly compare with alternatives, but the constraints offer sufficient guidance for safe usage.

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 should disclose behavioral traits like whether the file is modified in-place or a new file is created, but it does not. Side effects and requirements are absent.

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, clear sentence with no unnecessary words. It effectively communicates the core purpose without redundancy.

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

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

Given the lack of an output schema and the presence of sibling STL manipulation tools, the description is too brief. It does not explain the output, error conditions, or how it differs from similar tools.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's property descriptions; it merely restates the schema information.

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?

Description clearly states the action 'extend the base' on an STL file, which distinguishes it from sibling tools like scale_stl or rotate_stl. However, it is slightly vague on what 'extend the base' entails (e.g., adding material to the bottom vs. increasing thickness).

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 tool versus alternatives such as scale_stl or lay_flat. The description does not mention any prerequisites or contextual usage hints.

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 helpfully discloses that the data is live over MQTT and enumerates the returned content, but says nothing about failure modes, connectivity/auth needs (token, serial), or whether the call blocks or is read-only. Partial behavioral coverage only.

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

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

A single front-loaded sentence that leads with the core action and then lists the returned fields. Efficient, though the trailing enumeration of outputs makes it dense.

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

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

With no output schema, the description does describe the return content, which is its main job here. However, it omits prerequisites (printer reachability, credentials) and any failure/error context, leaving gaps for a tool that talks to hardware over MQTT.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, giving a baseline of 3. The description adds minor value by linking bambu_model to the recommended load_filaments output, but adds no syntax or format detail beyond the schema.

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

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

Specific verb (Get) plus resource (live AMS/external filament inventory) with the transport (MQTT) called out. It clearly distinguishes itself from siblings like get_printer_status or resolve_3mf_ams_slots by naming the filament inventory and the several derived outputs (slot summary, profile paths, match confidence, recommendations).

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

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

Usage is implied by the resource it reads, but the description never states when to reach for this tool versus alternatives such as get_printer_status, reread_ams_rfid, or resolve_3mf_ams_slots. No prerequisites or exclusions are given, so the agent must infer the 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 provided, the description must convey behavioral traits. It only states a simple read operation, but fails to disclose potential side effects (if any), error behavior (e.g., if printer is offline), or authentication requirements beyond the parameter defaults. This leaves the agent unaware of safety or failure modes.

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

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

The description is a single concise sentence with no wasted words. However, it could benefit from slight expansion (e.g., a brief note on output format) without losing conciseness.

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 the tool has no output schema and three optional parameters, the description should provide more context, such as the return format or typical use cases. Currently, it only states the basic action, leaving the agent uncertain about what data the tool returns and how to interpret results.

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 input schema has 100% coverage, describing each parameter with its purpose and default behavior. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate. The tool is simple and the schema is sufficient.

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 the action 'Get' and the resource 'current status of the Bambu Lab printer', making the tool's purpose apparent. It distinguishes itself from sibling tools like cancel_print or pause_print, but could be more specific about what aspects of status are retrieved (e.g., printing, idle, errors).

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 is provided on when to use this tool versus alternatives. For example, it doesn't suggest checking status before printing or mention related tools like get_printer_filaments or list_printer_files. The agent is left without context for selecting this tool.

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 full burden. It explicitly states 'without slicing anything', which indicates the tool is non-destructive and read-only. However, it does not disclose other behavioral traits such as required permissions, file format limitations, or potential errors.

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 sentence that is perfectly concise, with no extraneous information. Every word adds value, and the key point about not slicing is front-loaded.

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 tool is simple with 3 parameters and no output schema. The description adequately explains the tool's purpose and behavior, but lacks details about what the returned settings look like or how to interpret them. For a complete understanding, an agent would benefit from knowing the output structure.

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 input schema has 100% coverage for parameter descriptions, so the baseline is 3. The description adds context by mentioning 'saved 3MF template or a JSON/config slicer profile', which elaborates on the source_path parameter, but does not add significant additional meaning beyond what the schema provides.

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 the verb 'inspect' and the resource 'slicer settings from a saved 3MF template or a JSON/config slicer profile', and explicitly distinguishes itself from slicing operations. This differentiates it from sibling tools like slice_with_template or slice_stl, which perform actual slicing.

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 implies usage for inspecting settings without slicing, but does not provide explicit guidance on when to use this tool versus alternatives like get_stl_info or list_templates. No exclusions or alternative suggestions are given, so the agent must infer the use case.

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

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

No annotations are present, so the description carries the burden. It indicates a read-only operation by stating 'Get detailed information', but does not disclose error behavior, permissions needed, or any side effects. It adds some value by listing the exact information 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?

The description is a single, focused sentence that immediately conveys purpose. No unnecessary words, well front-loaded.

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 query tool with one parameter and no output schema, the description is nearly complete. It states what it does and what information it returns. Minor improvement could include noting it does not modify the 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 100% (the single parameter 'stl_path' is described). The tool description adds no additional meaning beyond the schema's 'Path to the STL file to analyze'. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get' and resource 'STL file', and specifies the kind of information (bounding box, face count, dimensions). It distinguishes from sibling tools that modify STL files, making it unambiguously a read-only information retrieval 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 implies usage when needing STL file details, but gives no explicit guidance on when to use this tool versus alternatives like scale_stl or slice_stl. No when-not or exclusion criteria are provided.

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

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

The description explains the core action but lacks details on side effects (e.g., whether the file is modified in place), error handling for models without a flat face, or return value. With no annotations, more disclosure would be beneficial.

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?

Single, well-structured sentence that front-loads the action and outcome with no wasted words.

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 simple tool but missing expected output description (e.g., returns path or modifies in place). Could mention prerequisites like presence of a flat face.

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?

Only one parameter with 100% schema coverage, but the description adds no extra meaning beyond the schema's 'Path to the STL file'. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool rotates the model so its largest flat face lies on the XY plane, using a specific verb and resource that distinguishes it from sibling tools like rotate_stl which require manual angles.

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 tool versus alternatives (e.g., rotate_stl, center_model). The description does not specify prerequisites or scenarios where this tool is appropriate.

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?

The description is transparent about the read-only nature of listing object IDs. No annotations are provided, so the description carries the burden and does so adequately.

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

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

Two sentences with no wasted words. The first sentence states the purpose, and the second gives actionable guidance. Excellent front-loading.

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

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

The description is complete for a simple list operation, but lacking an output schema, it does not specify the format of the returned object IDs. However, the purpose and usage are clear enough.

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

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

Schema coverage is 100%, and the description does not add significant meaning beyond the schema's parameter descriptions. The additional context about skip_objects is usage guidance, not parameter semantics.

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

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

The description clearly states the verb 'List' and the resource 'object IDs from a sliced 3MF plate', and distinguishes itself from siblings by specifying the use with skip_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?

The description explicitly advises to use the IDs with skip_objects during a running print, providing clear context. It does not state when not to use it or list alternatives, but the usage is well-defined.

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 full burden but only states 'list files'. It does not disclose whether the result includes file sizes, timestamps, or if pagination is used. For a read operation, more behavioral context would be expected.

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, clear sentence. While it is concise, it could benefit from a bit more structure (e.g., specifying what information is returned).

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 list operation, the description is minimally adequate. However, given the lack of an output schema and the presence of many sibling tools, additional details about the returned file list (e.g., format, fields) would improve 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 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which only indicate default values from environment variables.

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 the action ('list files') and the target ('stored on the Bambu Lab printer'). It distinguishes from sibling tools like 'delete_printer_file' or 'upload_file' which perform different operations on printer files.

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 tool versus alternatives such as 'get_printer_status' or 'slice_stl'. No mention of prerequisites, context, or when not to use it.

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 disclose behavioral aspects. It only says 'list' without describing return format, error handling, or side effects. No indication that this is a read-only operation or what happens if the directory is missing.

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 sentence with no extraneous information. Every word is necessary, and it is front-loaded with the action and resource.

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 the simplicity of the tool (one optional param, no output schema), the description is minimally adequate. However, it lacks details on return values and edge cases, which could be added for 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 100% for the single parameter. The description does not add new information beyond the schema. Baseline 3 is appropriate as the schema already covers parameter details.

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 the tool lists saved slicing templates from a specific local directory. The verb 'List' and resource 'saved slicing templates' are precise, distinguishing it from siblings like save_template and slice_with_template.

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

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

No explicit guidance on when to use this tool or when to avoid it. No mention of prerequisites, default behavior, or alternatives. The description only states the source directory without 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the file is modified in place, side effects, performance implications, or if the operation is destructive. The agent lacks crucial behavioral cues.

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. It is concise, though it could optionally provide a bit more context about the operation's effect without becoming verbose.

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 no output schema and low complexity, the description should at least hint at return value or side effects (e.g., whether the file is overwritten). It lacks this context, making it incomplete for the agent to fully understand the tool's behavior.

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

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

Schema description coverage is 100% (both parameters have descriptions). The description adds no additional meaning beyond what is in the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the action ('Merge vertices in an STL file') and the condition ('closer than the specified tolerance'). It distinguishes from siblings like scale_stl, rotate_stl, etc., which perform different operations on STL files.

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 tool versus other STL tools, nor any prerequisites or exclusions. The description simply states what it does without context on alternatives like manual editing or other merge strategies.

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?

Without annotations, the description carries full burden. It discloses the action is non-destructive and resumable, but lacks details on permissions, timeouts, or state prerequisites.

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?

Single sentence, front-loaded with the verb, every word adds value. No fluff.

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 low complexity and good schema, description is nearly complete. Only minor gap: it doesn't explicitly state that the printer must be printing.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds no additional parameter info, but baseline 3 is appropriate since schema already covers meaning.

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

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

The description clearly states the verb 'Pause', the resource 'current print job on the Bambu Lab printer', and distinguishes this from sibling tools like cancel_print (destructive) and resume_print (reversal).

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 says when to use (pause current print job) and implies that resume_print is for resuming. However, it does not explicitly state when not to use or list all alternatives.

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

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

With no annotations, the description carries the full burden. It helpfully discloses the auto-slice fallback when gcode is missing and warns that a wrong bambu_model can damage the printer, which is real behavioral context. But it omits whether the call blocks until print completion, failure/rollback behavior, and auth prerequisite details for an irreversible physical action.

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 action, then the auto-slice behavior, then the safety constraint in caps. Nothing is wasted, though the 'IMPORTANT' warning largely duplicates the schema's own 'REQUIRED' wording rather than adding new information.

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

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

For a 33-parameter, no-annotation, no-output-schema tool that physically drives hardware, the description is minimally adequate: it names the action and the one hard requirement. It says nothing about connection-mode selection, slicer prerequisites, or the irreversible nature of a print job, which an agent would need to make a confident 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 description coverage is 100%, so the 33 parameters are already well documented in the schema, including enums for bed_type, slicer_type, connection_mode, and others. The description adds only the emphasis that bambu_model is required and dangerous to get wrong, which the schema itself already states, so it does not meaningfully exceed the baseline.

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

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

The description states a specific verb and resource ('Print a 3MF file on a Bambu Lab printer') and discloses the auto-slice behavior, so the core action is unambiguous. However, it does not distinguish itself from near-identical siblings such as print_3mf_bambu_network or start_print, leaving the agent to infer which variant to pick.

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 the many overlapping print siblings (start_print, start_print_job, print_3mf_bambu_network, x2d_native_control). The only routing-adjacent guidance is the internal note that bambu_model must be supplied, which is a prerequisite rather than a use-when rule.

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

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

There are no annotations, so the description must carry the full behavioral burden. It discloses the network path but omits critical operational facts: that this triggers a physical print, is destructive/irreversible in part, may require credentials, and can damage the printer if the wrong model is used. The schema carries a damage warning, but the description itself does not.

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

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

A single front-loaded sentence with no redundant or filler text. It efficiently states the core behavior and routing distinction.

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 47-parameter tool that performs a physical print with no annotations and no output schema, one sentence is not enough. The detailed schema helps with parameters, but the description omits safety, authentication, physical side effects, and practical usage context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, even though it could have clarified key interactions among the 47 parameters such as connection_type, required printer credentials, and model safety.

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 (Print), resource (a 3MF), and execution route (FULU OrcaSlicer-bambulab's restored BambuNetwork path). It also explicitly distinguishes itself from the alternative MCP LAN MQTT/FTPS path, so an agent can separate it from sibling print 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?

The description gives clear context for when to choose this tool: when using the restored BambuNetwork path instead of the MCP LAN MQTT/FTPS path. However, it does not name the alternative tool explicitly or state when not to use it, so it falls short of full when/when-not 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 full burden. It usefully discloses the fixed AMS tray policy (inner->black AMS 1 slot 1, outer->white AMS 2 slot 1), which is genuine behavioral context absent from the schema, but it says nothing about prerequisites (pre-sliced vs raw), failure behavior, permissions, or whether it waits for completion.

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 with the action and the tray policy front-loaded, no filler, and every clause carrying information an agent needs.

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

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

For a 14-parameter print tool with no annotations and no output schema, the definition covers the core action and tray policy but leaves the source_path/template_name requirement and printer-model constraints entirely to the schema. Adequate but with clear gaps given the tool's complexity.

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

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

Schema description coverage is 100% across 14 parameters, so the schema already documents host, model, source_path, template_name, calibration flags, etc. The description adds no parameter-level meaning beyond hinting that the project must be 'prepared'. Baseline 3 is appropriate.

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

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

States a specific verb (print) and resource (a prepared two-part dog collar charm project) plus the fixed tray policy, so an agent can tell it apart from the generic print_3mf siblings. However, it never names or contrasts the alternatives it overlaps with (print_3mf, start_print_job), so the differentiation is implicit rather than explicit.

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 phrase 'prepared two-part project' implies usage (use this for an already-prepared collar charm), but there is no explicit when-to-use, when-not-to-use, or routing to siblings like print_3mf or slice_with_template. Usage is left to inference.

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

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 a key side effect ('can move AMS filament'), a prerequisite (idle and unloaded), and a platform-specific route ('X2D on macOS uses the native official plug-in route'). It omits details like failure behavior or token requirements, but covers the critical safety-relevant traits.

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, followed by a platform note and a safety warning. Every sentence adds distinct value with no audience-irrelevant 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 mutation-like operation with no output schema and no annotations, the description supplies purpose, prerequisite conditions, side-effect risk, and platform nuance. It could go further on authentication or expected outcomes, but an agent has enough to invoke it safely.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including ranges and defaults. The description adds only the implicit scope of 'one AMS slot' and does not elaborate on parameter formats or constraints beyond the schema.

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

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

The description states a specific verb ('Trigger') and resource ('Bambu AMS RFID re-read') with explicit scope ('for one AMS slot'). No sibling tool performs a similar re-read action, so it is easily distinguished from the surrounding printer operations.

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

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

It gives a clear precondition: 'use only when the printer is idle and unloaded.' This doubles as a when-not rule. No alternative tool is named, but none exists in the sibling list for this exact operation.

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 disclosure burden. It does state the operation is read-only ('Does not upload or start a print') and that it reads live/inventory state, which is meaningful. It omits failure modes (offline printer, missing AMS, unresolvable profile), whether credentials/network are required, and what happens on a slot mismatch.

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

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

Two tight sentences with the core action front-loaded and the exclusion clause last. Every clause earns its place; nothing is repeated 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?

There is no output schema, so the description ideally should say what the matching produces (e.g., a per-tray filament mapping or match/unmatch result) and what the agent should do with it. It also leaves the printer/AMS prerequisite unstated. The action and its non-mutating nature are covered, but return semantics are not.

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

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

Schema description coverage is 100% and all seven parameters (host, serial, token, model hint, plate index, path, nozzle diameter) are documented in the schema itself. The description adds no format or defaulting detail beyond that, so the baseline 3 applies.

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

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

The description names a specific action (inspect a sliced 3MF and match its tray_info_idx filament requirements against live AMS inventory), which is a concrete verb+resource pairing that no sibling tool covers. The closing clause 'Does not upload or start a print' draws a boundary against print/upload siblings such as print_3mf and start_print, though it does not name them directly.

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

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

Use case is only implied: an agent can infer this is a pre-print verification step, and the negative scoping ('does not upload or start a print') rules out the obvious alternatives. There is no explicit when-to-use statement or named alternative, so this stays at the minimum-viable 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?

Annotations are absent, and the description does not disclose behavioral traits such as whether the print must be paused, what happens if it's already printing, or any side effects. The single sentence offers minimal transparency.

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 concise sentence with no wasted words. It front-loads the action and resource, but could be slightly more informative without losing brevity.

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 no output schema and no annotations, the description is incomplete. It does not explain expected return values (e.g., success message, new status) nor provide context for differentiating among many sibling print tools.

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

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

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no extra meaning beyond what the schema provides, resulting in a baseline score.

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 uses a specific verb ('Resume'), clearly identifies the resource ('paused print job'), and specifies the brand/context ('Bambu Lab printer'). It distinguishes well from sibling tools like 'pause_print', 'cancel_print', and 'start_print_job'.

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

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

No explicit guidance on when to use or not use this tool. It does not mention that the print must be paused beforehand, nor does it contrast with alternatives like 'cancel_print' or 'start_print_job'. The usage is only implied from the verb.

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, and the description lacks details about side effects (e.g., overwrites the file, creates a new file), required permissions, or output format. Only the unit (degrees) is mentioned.

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 that is concise and to the point, with no unnecessary words.

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 description is adequate for a simple tool with 4 well-documented parameters, but fails to explain whether the rotation modifies the file in-place or outputs a new file, which is relevant context.

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?

All parameters are documented in the schema with descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.

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 the action (rotate) and the resource (STL file) with specific angles, distinguishing it from sibling tools like scale_stl or extend_stl_base.

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 tool versus alternatives like blender_mcp_edit_model or when not to use it. No context about prerequisites or preferred scenarios.

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 must fully disclose behavior. It omits important details such as whether existing templates are overwritten, required permissions, or potential side effects. The description is minimal.

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 concise sentence that immediately conveys the tool's purpose. No unnecessary words or redundancy.

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

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

Given no output schema and no annotations, the description is moderately complete but lacks information about the return value or success/failure behavior. It sufficiently explains the operation for a simple file copy and registration.

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

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

Schema description coverage is 100%, so the description adds little beyond what the schema already provides. It repeats file types but does not clarify default behavior or constraints not already 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?

The description clearly states the action ('Copy and register'), the resource (3MF, JSON, or config file), and the target (local template registry under a template name). It effectively distinguishes from sibling tools like list_templates or slice_with_template.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., upload_file). It does not mention prerequisites, exclusions, or context where other tools are preferred.

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 disclose behavioral traits. It fails to mention whether the file is modified in-place, if a new file is created, or any side effects like overwriting. This is a significant gap for a transformation tool.

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 wasted words. However, it could include more useful details without becoming verbose, such as the effect of uniform scaling.

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 no output schema and no annotations, the description is incomplete. It lacks details on return values, error conditions, and the overall process (e.g., whether scaling is uniform or per-axis). This leaves the agent underinformed.

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

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

Schema coverage is 100% and all parameters have descriptions defining their roles (scale factors with defaults, file path). The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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

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

The description 'Scale an STL file by specified factors' clearly states the verb (scale), resource (STL file), and scope (by factors). It effectively differentiates from sibling tools like rotate_stl and extend_stl_base.

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 implies usage when scaling is needed, but provides no explicit guidance on when to use this tool over alternatives or what conditions warrant scaling. No exclusions or alternative tool names mentioned.

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 must disclose behavioral traits. It does not mention any side effects, prerequisites, or limitations (e.g., whether the mode change is immediate or reversible). This is a basic level of transparency.

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 sentence with no wasted words. It is front-loaded and to the point, though slightly ambiguous in phrasing ('Set H2/P2 airduct mode' could be read as a noun phrase but remains clear).

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 no output schema, the description covers the basic purpose but omits important context: the tool is specific to H2/P2 printers. A more complete description would clarify the target printer type and any 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?

The input schema has 100% description coverage, so the description adds no extra meaning beyond the schema. The schema already defines the mode enum and provides defaults for host, serial, and token.

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 the action ('Set') and the resource ('airduct mode') with specific values ('cooling or heating') and target hardware ('H2/P2'). It distinguishes itself from sibling tools like set_temperature or set_fan_speed.

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 is provided on when to use this tool versus alternatives or when not to use it. The description is minimal and does not differentiate usage from sibling tools like set_ams_drying.

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 implies a state-changing operation (drying cycle) but discloses nothing about duration, whether it blocks, whether it requires the AMS to be loaded, or any auth/connection requirements. The macOS/X2D sentence gestures at context but does not clarify behavior.

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

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

Two sentences with the core action front-loaded, so an agent gets the essence immediately. The trailing X2D/macOS sentence is cryptic and of uncertain value, which keeps it from a 5.

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 is too thin: it omits prerequisites, side effects, failure modes, and what the tool returns or changes. The one contextual sentence about the X2D/macOS route does not compensate for the missing operational detail.

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

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

Schema coverage is 100%, so the schema already documents all five parameters, including ams_id's 0-3/128 semantics. The description's mention of 'AMS-HT id 128' merely echoes the schema, adding no new meaning, so the baseline 3 applies.

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

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

The description states a clear verb pair and resource: 'Start or stop the AMS filament drying cycle.' No sibling tool operates on AMS drying, so the scope is unambiguous in practice, though the description never explicitly differentiates itself from neighbors like set_airduct_mode or set_temperature the way a 5 would require.

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 prerequisites (e.g., printer must be idle/connected), and no mention of alternatives. The only contextual sentence is about an 'X2D on macOS native official plug-in route,' which is opaque rather than actionable.

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 present, so the description bears the full behavioral burden. It does disclose genuinely useful context — X2D on macOS uses the networking plug-in without UI automation while other models use MQTT — but says nothing about failure behavior, reversibility, or the in-print confirmation flow (only the schema hints at 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?

Two tight sentences with the core purpose front-loaded and no filler. The model-routing detail is relevant, though it slightly interrupts the primary statement.

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 setter with no output schema, the description plus fully-covered schema give the agent enough to call it correctly. The model/macOS routing note covers the main behavioral quirk, though error and in-print confirmation behavior are only implied by the schema.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the enumerated fan choices and the confirm_during_print requirement. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

The first sentence gives a specific verb (Set) and resource (Bambu printer fan speed percentage), clearly separating it from siblings like set_print_speed, set_temperature, and set_light. It stops short of explicitly contrasting with those siblings, 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 description never states when to reach for this tool versus related setters (set_print_speed, set_airduct_mode) or about preconditions for changing fan speed. The model-specific routing note implies context but does not give the agent an explicit use/avoid condition.

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 provided. The description adds the MQTT mechanism and implies state mutation, but does not disclose side effects, required permissions, rate limits, or safety implications. More behavioral context would be beneficial.

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 that is front-loaded with the verb and resource. No redundant or unnecessary words, making it highly concise and to the point.

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 mutation tool with five parameters and no output schema, the description covers the basic functionality. Minor gaps include not specifying default behavior for optional parameters or failure results, but overall sufficient.

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

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

Schema coverage is 100% with descriptions for all five parameters. The description adds minimal extra meaning beyond the schema, such as the specific light node example and the enum values, but does not significantly enrich parameter understanding.

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 the verb 'Set', the resource 'Bambu printer light node mode', and the mechanism 'using the printer's MQTT LED command'. It effectively distinguishes from siblings like set_airduct_mode or set_fan_speed.

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 implies usage for controlling printer lights, but lacks explicit guidance on when to use versus alternatives, prerequisites, or exclusions. No when-not-to-use or alternative tool mentions.

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 bears the full burden of disclosing behavior. It only states the function without revealing any side effects (e.g., whether the change is instantaneous, if it affects ongoing prints, if authentication is required). The description is too terse to convey important behavioral traits for an agent invoking the tool.

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, well-structured sentence that immediately conveys the tool's purpose and lists all options. It wastes no words and is easy to parse.

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 setter tool with no output schema and no annotations, the description is moderately complete. It correctly identifies the parameter and values but lacks context about prerequisites or consequences (e.g., does this require the printer to be online? Can it be called mid-print?). Given the complexity (4 params, but only one is core), it is adequate but not comprehensive.

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

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

Schema coverage is 100% with each parameter described. The description adds marginal value by listing the symbolic mode names, but the schema already includes those as enum values. The 'host', 'bambu_serial', and 'bambu_token' parameters' meanings are not enhanced by the description. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the action ('Set') and the resource ('active print speed mode'), and enumerates the exact possible values ('silent, standard, sport, or ludicrous'). This is sufficiently specific to distinguish from other set_* sibling tools which target different parameters (airduct, fan, light, temperature).

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., printer must be connected or in certain state), nor does it indicate when not to use it. Sibling tools like 'pause_print', 'resume_print' suggest usage context, but the description itself lacks any usage direction.

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 preconditions (fresh telemetry, declared material for nozzles), that values are checked against model/component/material limits, and that temperature=0 disables the heater. It stops short of describing failure behavior, blocking semantics, or what happens when telemetry is stale beyond 'requires matching fresh'.

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 tightly packed sentences with zero filler, front-loading the primary action before the preconditions and the zero edge case. Every clause adds functional value.

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 8-parameter mutation tool with no annotations and no output schema, the description covers the critical gating behavior (telemetry freshness, material requirement, limit checks, zero=off). It does not clarify return/confirmation behavior or error handling, but the core operational contract an agent needs is present.

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

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

Schema description coverage is 100%, so params like material, bambu_model, and temperature limits are already fully documented in the schema. The description adds only the zero-disables semantics for temperature, which is a modest supplement. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (Set) and resource (bed or nozzle temperature) with clear scope. It distinguishes itself from siblings like set_fan_speed, set_light, and set_ams_drying by naming exactly what it controls, and even notes the zero case, so an agent needs no schema inspection to know what it does.

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 concrete conditions for use: positive heating requires matching fresh telemetry and, for nozzles, a declared material, while zero turns the heater off. This is clear context for when to invoke it as written, but it does not name or contrast any alternative sibling tools for temperature-adjacent tasks.

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 full burden. It mentions using MQTT (network) but does not disclose reversibility, permission requirements, or error handling. Minimal behavioral disclosure.

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 concise sentence with no unnecessary words. It is front-loaded but could be slightly more structured with separate sentences for different aspects.

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 no output schema and no annotations, the description provides the core purpose and parameter guidance, but lacks information on return values, errors, or side effects, making it minimally adequate.

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 schema covers 100% of parameters, and the description adds value for object_ids by referencing list_3mf_plate_objects. The host, bambu_serial, and bambu_token defaults are already in the schema, so limited added meaning.

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

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

The description clearly states the action (skip), the resource (object IDs during a running multi-object print), and the method (MQTT command). It distinguishes from sibling tools like pause_print or cancel_print.

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 specifies the context (during a running multi-object print) and guides the agent to use list_3mf_plate_objects to find object IDs. It does not explicitly state when not to use, but the context is sufficient.

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 flags the safety-critical requirement and the risk of damaging the printer with the wrong model, but it says nothing about the output artifact (where the G-code/3MF is written, what path is returned) or side effects, which matters for a tool whose whole job is producing a file.

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

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

Two sentences, zero waste, and the critical requirement is front-loaded with an IMPORTANT marker. It is tight and well-structured, though for a 32-parameter tool the extreme brevity leaves useful information unstated.

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?

This is a highly complex tool (32 params, 4 enums, no output schema, no annotations). The description never states what the call returns or where the sliced output lands, nor does it cover the interaction with sibling tools like upload_gcode. For this complexity level, the definition is too thin.

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

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

Schema description coverage is 100% across all 32 parameters, so the schema already documents every parameter, including the bambu_model warning the description repeats. The description adds no parameter meaning beyond the schema, which sets the baseline at 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?

States a specific verb+resource (slice an STL or 3MF) and the outcome (printable G-code or sliced 3MF). This clearly distinguishes it from siblings like scale_stl, rotate_stl, and slice_with_template, which share the domain but do different things.

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 hard prerequisite (bambu_model must be specified) and explains why (safe G-code for the correct printer), which is real usage context. However, it never routes the agent against alternatives such as slice_with_template or get_slice_settings, so the when-to-use-this-vs-another guidance is only implied.

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