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 the action without disclosing behavioral traits. It doesn't mention if this is a destructive operation, requires specific printer states, has side effects, or involves rate limits. For a tool that likely interacts with hardware, this is a significant gap in 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple tool, with zero waste 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 annotations, no output schema, and a tool that likely performs a hardware operation (filament change), the description is incomplete. It lacks details on success/failure conditions, error handling, or what the tool returns. For a potentially complex action, more context is needed to ensure safe and effective use.

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 fully documents both parameters ('tray' and 'target_temp'). The description only mentions the tray parameter range (0-3), adding minimal value beyond the schema. It doesn't explain the relationship between parameters or provide usage context, so 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 ('Change to') and resource ('AMS filament tray'), specifying the tray range (0-3). It distinguishes from sibling tools like 'ams_unload_filament' by focusing on switching trays rather than unloading, though it doesn't explicitly contrast them. The purpose is specific but could be more detailed about what 'change' entails.

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

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

No guidance is provided on when to use this tool versus alternatives like 'ams_unload_filament' or other printer control tools. The description implies usage for filament switching but lacks context on prerequisites, timing, or exclusions. It's a basic statement without operational context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention potential side effects, safety considerations, or what happens after unloading (e.g., does it retract filament, require user intervention, or affect printer status?). This is inadequate for a tool that likely involves physical printer operations.

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 wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.

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 complexity of a physical printer operation, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral outcomes, error conditions, or what the tool returns, leaving significant gaps for an AI agent to understand how to use it effectively.

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

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

The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline for a parameterless tool. No additional semantic value is required or provided.

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 ('unload') and target resource ('current filament from the extruder'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ams_change_filament' which might involve filament handling, so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. For example, it doesn't specify if the printer must be in a certain state or if this should be used instead of other filament-related tools, leaving usage unclear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Enable or disable camera recording') but doesn't mention critical details like required permissions, whether this affects ongoing prints, latency, or error conditions. This is a significant gap for a tool that likely interacts with hardware.

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 that directly states the tool's function without any wasted words. It's front-loaded and appropriately sized for a simple tool with one parameter, earning a perfect score for 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 lack of annotations and output schema, the description is incomplete for a tool that modifies printer hardware state. It doesn't cover behavioral aspects like success/failure responses, side effects, or integration with other tools (e.g., 'printer_pause'), leaving the agent with insufficient context for safe and effective use.

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, with the 'enabled' parameter clearly documented. The description doesn't add any extra meaning beyond the schema, such as explaining side effects or default states, so it meets the baseline score of 3 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 tool's purpose with a specific verb ('Enable or disable') and resource ('camera recording on the printer'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'camera_timelapse', which might have overlapping functionality, preventing a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'camera_timelapse' or other camera-related tools. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention side effects (e.g., if enabling affects print performance), permissions required, or error conditions. This leaves gaps in understanding the tool's behavior beyond the basic function.

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, direct sentence that efficiently conveys the core function without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse quickly.

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 annotations and output schema, the description is incomplete for a tool that modifies printer state. It doesn't address what happens on success/failure, return values, or potential impacts on the print, which are important for safe and effective use in this 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?

The input schema has 100% description coverage, with the 'enabled' parameter clearly documented. The description doesn't add extra meaning beyond the schema, such as explaining default states or implications of toggling, but the schema adequately covers the parameter semantics, 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 ('Enable or disable') and the resource ('timelapse recording for the current print'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'camera_record', which might handle different camera functions.

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, such as whether it's specific to ongoing prints or if there are prerequisites like having a camera connected. It lacks context about timing or conditions for invocation.

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 discloses the protocol (FTPS) and port (990), which is valuable behavioral context. However, it doesn't mention authentication requirements beyond the password parameter, error handling, file size limits, or what happens on successful/failed uploads. For a file transfer tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

Two sentences with zero waste. The first sentence states the core purpose with key details (file types, destination, protocol). The second provides essential usage guidance. Every word earns its place, and information is front-loaded appropriately.

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 file upload tool with 4 parameters, no annotations, and no output schema, the description provides good purpose and usage context but lacks behavioral details about authentication flow, error conditions, or response format. The 100% schema coverage helps, but without annotations or output schema, more behavioral context 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 description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. It mentions file types (.gcode, .3mf, .stl) which relates to local_path but doesn't provide format validation details. Baseline 3 is appropriate when 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 specific action ('Upload'), resource ('.gcode, .3mf, or .stl file'), and destination ('to the printer SD card via FTPS (port 990)'). It distinguishes from sibling 'printer_print_file' by specifying that tool is for starting prints after upload, establishing a clear workflow relationship.

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 provides when-to-use guidance by stating 'Use printer_print_file to start the print after upload,' naming the alternative tool and specifying the sequential relationship. This gives clear context for when this tool should be used versus its sibling.

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 discloses the cloud API mechanism and authentication need ('requires cloud cookies'), which is useful context. However, it lacks details on rate limits, error handling, response format, or whether this is read-only (implied by 'Get' but not explicit). For a tool with no annotations, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get printer status') and includes essential context ('via cloud API (requires cloud cookies)'). There is no wasted verbiage, and every part adds 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?

Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what status information is returned, potential errors, or how the cloud API interacts with siblings like 'printer_get_status'. For a tool that likely returns complex status data, this leaves the agent with insufficient 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%, with the single parameter 'device_id' documented in the schema as 'Printer device ID'. The description adds no additional parameter information beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema handles the parameter documentation adequately.

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 printer status') and resource ('printer'), and specifies the mechanism ('via cloud API'). It distinguishes from sibling tools like 'printer_get_status' and 'printer_get_cached_status' by mentioning the cloud API requirement. However, it doesn't explicitly differentiate the scope or output from those siblings.

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

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

The description implies usage context by stating 'requires cloud cookies', which suggests authentication prerequisites. It doesn't provide explicit when-to-use guidance versus alternatives like 'printer_get_status' or 'printer_get_cached_status', nor does it mention exclusions or detailed 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not explain if this requires authentication, what data is returned, or any rate limits. This leaves significant gaps in understanding the tool's 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple tool.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but insufficient. It does not address behavioral aspects like authentication needs or return format, making it incomplete for effective use by an AI 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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter details, but this is appropriate given the lack of parameters, aligning with the baseline for 0 parameters.

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

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

The description 'Get Bambu Lab cloud account profile' clearly states the action (Get) and resource (Bambu Lab cloud account profile), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_printer_status' or 'printer_get_cached_status', which focus on printer data rather than user account information, so it lacks sibling distinction for a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., authentication needs) or context for retrieving user profiles compared to printer-related tools in the sibling list, leaving usage unclear.

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 mentions 'Control' which implies a write operation, but doesn't disclose behavioral traits such as required permissions, side effects (e.g., if turning off lights affects printing), or error handling. This leaves significant gaps for an agent to understand how to use it safely and effectively.

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 that directly states the tool's function without any fluff. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.

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's complexity (a write operation with no annotations and no output schema), the description is insufficient. It doesn't cover return values, error conditions, or practical usage context, leaving the agent with incomplete information to invoke the tool correctly in real-world scenarios.

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, with clear enums and descriptions for both parameters. The description adds no additional meaning beyond the schema, such as explaining what 'chamber_light' or 'work_light' refer to in practice. Since the schema does the heavy lifting, the 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 verb ('Control') and resource ('printer chamber or logo LED lights'), making the tool's purpose evident. However, it doesn't differentiate from sibling tools, as no other tools appear to control LEDs, so it's not misleading but lacks explicit distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives or in what context. It simply states what the tool does without mentioning prerequisites, timing, or related tools like 'set_temperature' or 'printer_set_speed' that might be used in similar printer control 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 carries the full burden. It states the tool lists printers but does not disclose behavioral traits like whether it requires authentication, returns paginated results, or includes offline printers. This leaves significant gaps for an agent to understand operational context.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.

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's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It lacks details on authentication needs, return format, or error handling, which are important for a list operation in a cloud context. The absence of an output schema increases the need for more 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could mention implicit context like account filtering. Baseline is 4 for zero parameters.

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

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

The description clearly states the action ('List all printers') and the resource ('registered to the cloud account'), making the purpose specific and unambiguous. It distinguishes itself from sibling tools like 'get_printer_status' by focusing on enumeration rather than status retrieval.

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 a full list of printers, but does not explicitly state when to use this tool versus alternatives like 'get_printer_status' or 'printer_get_cached_status'. It lacks guidance on prerequisites, such as authentication or account context.

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

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

With no annotations provided, the description carries full burden. It discloses the connection purpose and prerequisite behavior, but lacks details about connection persistence, error handling, timeout behavior, or authentication requirements beyond password. It doesn't contradict any annotations.

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 zero waste. The first sentence states the core purpose and method, the second provides critical usage context. Every word earns its place in this efficiently structured description.

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 connection tool with no annotations and no output schema, the description adequately covers the purpose and prerequisite context. However, it lacks information about what happens after connection (e.g., connection state management, error responses) which would be helpful given the tool's foundational role.

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 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score 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 specific action ('Connect to a Bambu Lab printer'), the method ('via local MQTT over TLS'), and the resource ('printer'). It distinguishes from siblings like mqtt_disconnect by specifying connection establishment rather than termination.

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

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

Explicitly states when to use this tool ('Required before any printer control commands') and implies when not to use it (after connection is established). It distinguishes from non-MQTT siblings by specifying the prerequisite for MQTT-based printer operations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not explain effects like whether it terminates active sessions, requires specific permissions, or handles errors. This is inadequate for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple tool.

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

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

Given no annotations, no output schema, and the tool being a mutation (disconnect), the description is incomplete. It lacks details on behavioral traits, error handling, or return values, which are crucial for safe and effective use.

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

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

The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add param details, but this is acceptable given the baseline of 4 for zero parameters, as it does not mislead or omit required info.

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 ('Disconnect') and the target resource ('from the MQTT printer connection'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling 'mqtt_connect', which is a minor gap.

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 or prerequisites. It does not mention if it should be used after 'mqtt_connect' or in specific error-handling scenarios, leaving usage context unclear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it returns cached data (implying potential staleness), is optimized for speed and low resource usage, and is suitable for polling scenarios. However, it doesn't mention potential limitations like cache expiration or error handling.

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 two sentences with zero waste: the first states the purpose and key constraint, the second provides comparative context and usage guidance. Every word earns its place, and information is front-loaded effectively.

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's simplicity (0 parameters, no annotations, no output schema), the description provides complete context for its intended use case. It explains what the tool does, when to use it, and how it differs from alternatives. The only minor gap is lack of detail about what 'cached status' includes or potential staleness implications.

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

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

The tool has 0 parameters with 100% schema coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and usage.

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 specific action ('Return the last cached printer status') and resource ('printer'), and explicitly distinguishes it from its sibling 'printer_get_status' by noting it's 'without requesting a new push.' This provides a precise verb+resource pairing with clear sibling differentiation.

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

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

The description explicitly states when to use this tool ('for frequent polling') and provides a direct alternative ('printer_get_status'), including comparative advantages ('Faster and lighter'). This gives clear guidance on usage context and exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it triggers a status push (not just retrieval), includes a rate limit warning ('not more than once every 5 minutes on P1P'), and specifies the scope of returned data (temperatures, print progress, AMS state, fan speeds, and more). This provides essential context beyond basic functionality.

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 efficiently structured in two sentences: the first states the purpose and key data returned, the second provides a critical usage constraint. Every sentence adds value without redundancy, making it front-loaded with essential information and appropriately concise.

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 no parameters, no annotations, and no output schema, the description does well by explaining what the tool does, what data it returns, and important behavioral constraints. However, it could be more complete by specifying the exact format of the returned status (e.g., JSON structure) or clarifying if the push is synchronous/asynchronous, which would help an agent 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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter-specific information (as none exist), but this is appropriate given the parameterless design. No compensation is needed since there are no parameters to document.

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 specific action ('Request a full status push') and resource ('from the printer'), distinguishing it from siblings like 'printer_get_cached_status' by emphasizing it's a fresh push rather than cached data. It explicitly lists key components included in the status (temperatures, print progress, AMS state, fan speeds).

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 clear context for when to use this tool (to get comprehensive, real-time printer status) and includes an important exclusion ('should not be called more than once every 5 minutes on P1P'). However, it does not explicitly compare it to alternatives like 'printer_get_cached_status' or 'get_printer_status', which could help differentiate usage 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 carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but does not specify if it requires authentication, has rate limits, or details the return format (e.g., structured data vs. raw text). For a tool with zero annotation coverage, this is a significant gap in 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, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently conveys the essential information, making it highly concise and well-structured.

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's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It explains what the tool does but lacks details on behavioral aspects like authentication or output format. For a read-only tool with no complex inputs, this is adequate but leaves gaps that could hinder agent usage.

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

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

The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, as there are none to document. A baseline score of 4 is appropriate for a parameterless tool, as the description adequately covers the absence of inputs.

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 ('firmware and module version information for the connected printer'), making the purpose specific and understandable. However, it does not explicitly distinguish this tool from potential siblings like 'get_printer_status' or 'printer_get_status', which might also provide version information as part of broader status data, so it lacks sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., printer connectivity), exclusions, or compare it to sibling tools like 'get_printer_status' that might offer overlapping functionality. This leaves the agent without context for tool selection.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Pause') but doesn't explain what pausing entails (e.g., whether it halts extrusion, maintains temperature, allows resumption), potential side effects, or error conditions. This leaves significant gaps for a mutation 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, clear sentence with no wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse for an AI agent.

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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what pausing does, success/failure responses, or dependencies (e.g., requiring an active print job), which are critical for safe and effective use.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no parameters are required, earning a baseline score above 3 for this scenario.

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 ('Pause') and the target ('the current print job'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'printer_stop' (which might have different semantics), so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'printer_stop' or 'printer_resume'. It lacks context about prerequisites (e.g., whether a print job must be active) or exclusions, leaving the agent with minimal 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Start printing') but does not describe what happens during printing, error conditions, permissions needed, or how it interacts with other printer operations (e.g., pausing with 'printer_pause'). This leaves significant gaps in understanding the tool's behavior beyond the basic 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?

The description is a single, efficient sentence that front-loads the core action and prerequisite, with zero wasted words. It directly communicates the purpose and usage context without unnecessary elaboration, making it highly concise and well-structured for quick comprehension.

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 complexity of a printing tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like error handling, state changes, or what the tool returns, which are critical for an AI agent to use it correctly. The description covers the basic action but fails to provide a complete operational 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 schema already documents all parameters thoroughly. The description does not add any additional meaning or context about the parameters beyond what the schema provides, such as explaining the implications of 'bed_type' choices or 'timelapse' effects. This meets the baseline for high schema coverage but does not enhance 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 specific action ('Start printing') and resource ('a file already on the printer SD card'), and distinguishes it from the sibling tool 'ftp_upload_file' by noting the file must be pre-uploaded via that tool. This provides precise differentiation and avoids confusion with file upload 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?

The description explicitly states when to use this tool: after a file has been uploaded via 'ftp_upload_file'. However, it does not mention when not to use it or alternatives for printing from other sources, which limits full guidance. The context is clear but lacks exclusions or comparisons to other printing-related tools like 'printer_send_gcode'.

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 of behavioral disclosure. It states the action (resume) but doesn't mention potential side effects (e.g., whether it requires specific printer states, if it affects print quality, or what happens on failure). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it highly efficient and easy to understand at a glance.

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's complexity (a mutation with no parameters) and lack of annotations and output schema, the description is minimally adequate. It states what the tool does but lacks details on behavioral traits, error conditions, or return values. For a tool that resumes operations, more context on prerequisites or outcomes 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?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline of 4 is applied as it meets expectations for a zero-parameter tool.

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 'Resume a paused print job' clearly states the specific action (resume) and target resource (a paused print job). It distinguishes from sibling tools like printer_pause (which pauses) and printer_stop (which stops completely), making the purpose unambiguous and well-differentiated.

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 context by specifying 'a paused print job', suggesting it should be used when a print job is already paused. However, it doesn't explicitly state when not to use it (e.g., if no job is paused) or name alternatives like printer_pause for pausing, though the context is reasonably clear from the wording.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it sends a single command, blocks dangerous commands for safety, and implies it's a write operation (sending commands). However, it doesn't cover aspects like error handling, response format, or rate limits, which would be helpful for a tool interacting with hardware.

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

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

The description is front-loaded with the core purpose in the first clause, followed by an example and safety note. It's only two sentences with zero waste, efficiently conveying essential information without redundancy or 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 the tool's complexity (interacting with a printer, potential safety risks), no annotations, and no output schema, the description is adequate but has gaps. It covers the basic action and safety, but lacks details on return values, error cases, or prerequisites. For a hardware control tool, more context 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?

The input schema has 100% description coverage, with the 'gcode' parameter documented as 'G-code command.' The description adds minimal value beyond this by providing an example ('G28' for home), but doesn't elaborate on syntax, constraints, or allowed commands beyond the safety warning. This 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 tool's purpose: 'Send a single G-code command to the printer' with an example ('G28' for home). It specifies the action (send) and resource (G-code command), but doesn't explicitly differentiate from siblings like 'printer_set_speed' or 'set_temperature', which might also involve sending commands. This makes it clear but not fully sibling-distinctive.

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 by mentioning 'Dangerous commands are blocked for safety,' which suggests when to use (for safe G-code commands) and hints at when not to use (for dangerous ones). However, it doesn't explicitly name alternatives (e.g., other printer control tools) or provide clear exclusions, leaving the guidance somewhat implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool sets print speed but doesn't mention whether this requires specific permissions, if changes are reversible, potential side effects (e.g., on print quality), or what happens on success/failure. This is a significant gap for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that front-loads the core action and immediately provides the two input options. Every word earns its place with no wasted text, making it highly concise and well-structured.

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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (e.g., safety, side effects), response format, or error handling, which are critical for an AI agent to use it correctly in context with sibling 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 schema already documents both parameters fully. The description adds marginal value by clarifying that 'speed' is a percentage (1-166) and that it's ignored if 'profile' is set, but these details are largely redundant with the schema's enum and description fields.

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

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

The description clearly states the action ('Set print speed') and the resource ('print speed'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'printer_pause' or 'printer_stop', which also control printer behavior but for different aspects.

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 by specifying the input options (profiles or percentages), but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'printer_send_gcode' for custom commands or other printer control tools. No context about prerequisites or exclusions is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Stop...immediately' implies an abrupt termination, it doesn't address whether this is reversible, what happens to the print job (e.g., lost progress), permission requirements, or error conditions. This leaves significant gaps for a mutation 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, direct sentence with no wasted words. It's front-loaded with the core action and efficiently communicates the tool's purpose without unnecessary elaboration.

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 insufficient. It lacks details on behavioral consequences (e.g., whether stopping is permanent), error handling, or return values, leaving the agent with incomplete operational 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?

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary 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?

The description clearly states the action ('Stop') and target ('the current print job immediately'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'printer_pause' or 'printer_resume', which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'printer_pause' or 'printer_resume', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.

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 for behavioral disclosure. It states the action ('Set') implying a write operation, but doesn't clarify if this requires specific permissions, affects print quality immediately, or has side effects (e.g., invalidating current print settings). For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes meaning, earning a top score for 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's moderate complexity (a single-parameter mutation), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral implications, usage context, or return values. This results in a score of 3, indicating it meets minimum viability but has clear gaps.

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

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

The input schema has 100% description coverage, with the 'diameter' parameter well-documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'printing profile selection,' which provides context but no additional parameter details. This meets the baseline of 3 when schema coverage is high.

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 ('nozzle diameter'), with additional context about its purpose ('for printing profile selection'). It distinguishes itself from siblings like 'set_temperature' by focusing on nozzle configuration rather than thermal settings. However, it doesn't explicitly differentiate from all possible alternatives, keeping it at a 4 rather than a 5.

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 doesn't mention prerequisites (e.g., printer must be idle), exclusions (e.g., not during active printing), or related tools (e.g., 'printer_set_speed' for other adjustments). This leaves the agent with minimal context for appropriate invocation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by mentioning validation against safe limits, which hints at safety checks and constraints. However, it doesn't cover other critical behaviors like error handling, response format, or whether this is a blocking command, leaving gaps for a mutation 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 that front-loads the core action and includes essential context (G-code method and validation). Every word earns its place, with no redundancy or fluff, making it highly concise and well-structured.

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 a mutation tool with no annotations and no output schema, the description is moderately complete. It covers the purpose and hints at safety, but lacks details on behavioral outcomes, error cases, or integration with sibling tools. For a 2-parameter tool, it's adequate but has clear gaps in guiding effective use.

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 clear descriptions for both parameters (e.g., 'Which heater to set' and temperature limits). The description adds minimal semantics by reinforcing the temperature limits in parentheses, but this mostly repeats schema info. Baseline 3 is appropriate as 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'), the resource ('nozzle or bed temperature'), and the method ('via G-code'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'set_nozzle' or 'printer_set_speed', which might have overlapping functionality in a 3D printing context.

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 like 'set_nozzle' or 'printer_send_gcode' (which could also handle temperature commands). It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage from the tool name alone.

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

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

With no annotations provided, the description carries full burden. It discloses the tool uses an extracted Bambu Connect certificate and bypasses firmware authentication, which are important behavioral traits. However, it doesn't mention security implications, error conditions, or what happens to the signed output.

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 zero waste. The first sentence states the core functionality, and the second adds crucial implementation context. Every word earns its place in this efficiently structured description.

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 cryptographic signing tool with no annotations and no output schema, the description provides adequate purpose and context but lacks details about the signing algorithm, output format, security considerations, or error handling that would be important for safe usage.

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 both parameters. The description adds context about the certificate source and authentication bypass, but doesn't provide additional parameter-specific semantics 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 specific action ('Sign a message'), the resource ('with X.509 certificate'), and the purpose ('for authenticated printer communication'). It distinguishes this tool from all sibling tools which involve printer control, camera operations, or file management rather than cryptographic signing.

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 context ('bypass firmware auth restrictions') but doesn't explicitly state when to use this tool versus alternatives. No sibling tools appear to offer similar signing functionality, so there's no direct alternative guidance provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'useful for excluding failed parts without stopping the entire print,' which implies it modifies the print job dynamically. However, it lacks details on permissions needed, whether the action is reversible, error handling, or how it interacts with other printer operations. This is a significant gap for a mutation tool with no annotation coverage.

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

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

The description is concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage. Every sentence adds value without redundancy, making it easy to understand quickly.

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's complexity (a mutation operation with no annotations and no output schema), the description is minimally adequate. It explains what the tool does and when to use it, but lacks details on behavioral aspects like side effects, return values, or error conditions. For a tool that modifies an active print job, more completeness would be beneficial.

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, with the parameter 'object_ids' clearly documented as an array of numbers. The description adds context by explaining that these IDs are for 'specific objects' to skip during printing, but does not provide additional semantics beyond what the schema already states, such as format examples or constraints. Baseline 3 is appropriate when schema coverage is high.

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's purpose: 'Skip specific objects during a multi-object print.' It specifies the verb ('skip'), resource ('objects'), and context ('during a multi-object print'), but does not explicitly differentiate from sibling tools like 'printer_pause' or 'printer_stop', which might also affect printing 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?

The description provides clear context for when to use this tool: 'Useful for excluding failed parts without stopping the entire print.' This implies it should be used instead of stopping or pausing the print when only specific objects need to be skipped. However, it does not explicitly mention alternatives or exclusions, such as when not to use it (e.g., for single-object prints).

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