Control the printer cooling fans
| Name | Required | Description | Default |
|---|---|---|---|
| speed | Yes | Fan speed from 0 (off) to 255 (full speed). Use 0 to turn fans off. | |
| macros | No | Predefined macro names, sent as one G-code block in this order. Either gcode, macro, macros, or snippet_id is required. | |
| printer_id | Yes | The printer IDs (comma-separated for multiple) | |
| snippet_id | No | ID of a gcode snippet to send. Either gcode, macro, macros, or snippet_id is required. |
Changes observed during successful MCP inspections.
Input schema / properties / macrosAdded value: +{
+ "description": "Predefined macro names, sent as one G-code block in this order. Either gcode, macro, macros, or snippet_id is required.",
+ "items": {
+ "enum": [
+ "is_start",
+ "is_end",
+ "is_cancel",
+ "is_pause",
+ "is_resume",
+ "move_axis",
+ "change_print_speed",
+ "change_flow_rate",
+ "is_home",
+ "set_tool_temperature",
+ "set_bed_temperature",
+ "set_chamber_temperature",
+ "motors_onoff",
+ "fans_onoff",
+ "baby_stepping",
+ "z_offset_cal_start",
+ "z_offset_cal_nudge",
+ "z_offset_cal_save",
+ "is_autoprint_clear",
+ "is_autoprint_on_end"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / snippet_id / descriptionPrevious value: -"ID of a gcode snippet to send. Either gcode, macro, or snippet_id is required."New value: +"ID of a gcode snippet to send. Either gcode, macro, macros, or snippet_id is required."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so safety framing is partly covered, but the description adds nothing about what happens on the printer. Critically, it does not explain how the speed parameter relates to the parallel macros/snippet_id payload options listed in the schema, or whether one overrides the other on a hardware mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler, so nothing is wasted. The brevity is efficient but also leaves the definition under-informative, which is penalized in the other dimensions rather than here.
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 hardware mutation with four parameters, two required, and no output schema. The schema also references gcode and macro payloads that are not present as properties, and the description does nothing to resolve that ambiguity or explain what a successful fan-speed change returns.
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 speed documented as 0 (off) to 255 (full) and macros described as an ordered G-code block, so the baseline of 3 applies. The description contributes no additional parameter meaning, leaving the relationship between speed, macros, and snippet_id entirely to 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?
"Control the printer cooling fans" names a resource and an action, so an agent can place it in the hardware-control family alongside set_printer_temperatures and set_printer_motors. But "control" is vague about what is actually done, and the sentence largely restates the name set_printer_fans and the title "Set printer fans" rather than refining them.
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 prerequisite conditions, and no mention of alternatives such as send_gcode for arbitrary fan commands. The agent must infer usage entirely from the tool name and the speed parameter's enum-like 0-255 range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.