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

With no annotations, the description carries the behavioral disclosure burden. 'Saves config and connects via MQTT' adds meaningful side effects beyond the schema. Still, it omits what happens with duplicate IDs, unreachable hosts, or invalid access codes.

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 concise sentences with no filler. The primary action is front-loaded, and the second sentence adds useful behavioral detail 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?

The description is adequate for a simple creation tool with fully documented parameters. However, with no annotations and no output schema, it lacks guidance on failure behavior, duplicate handling, or how to verify the printer was successfully added.

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 are already documented in the schema. The description adds no parameter-level meaning, but the baseline of 3 applies when the schema handles parameter documentation.

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 and resource: 'Add a Bambu Lab printer to the fleet.' This clearly identifies a creation/onboarding operation and differentiates it from siblings like remove_printer and reconnect_printer.

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 when to use it: when adding a new printer to the fleet. However, it does not explicitly state when not to use it or mention prerequisites such as network reachability or MQTT availability.

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 of behavioral disclosure, but it only states the intended result. It does not mention side effects, machine state changes, nozzle heating, printer availability requirements, or whether the operation is blocking.

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 extremely concise at one sentence and front-loads the verb and main object. It earns its place but is slightly too terse to cover usage and behavior without padding.

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

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

For a simple three-parameter tool with no nested schemas, the schema plus description is usable, but the lack of usage alternatives and behavioral context leaves gaps. There is no output schema to rely on, so a bit more context would make it fully complete.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description adds no extra parameter meaning beyond the overall tray-switching intent, so 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 names a specific verb ('Change') and resource ('AMS filament tray on a printer'), and the qualifier 'different' indicates selecting a non-current tray. This is specific enough to distinguish it from sibling operations like unload_filament.

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 given about when to use this tool versus alternatives, such as unload_filament or manual filament setup. The intended use is inferable from the verb, but the description does not state context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full burden. It discloses the main behavioral effects (deleting credentials, disconnecting cloud printers) and clarifies that LAN printers remain connected. This is adequate for a logout action, though it does not mention reversibility or failure 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?

A single sentence that front-loads the main action, followed by precise scope clarification. Every word earns its place with zero 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?

For a zero-parameter tool with no output schema, the description fully covers what an agent needs to know: what it does, what it affects, and what it leaves untouched. No additional information is required to call it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter-specific meaning since there are none 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 uses a specific verb ('Log out') and resource ('Bambu cloud') and names the concrete effects: deleting stored credentials and disconnecting cloud printers. It also explicitly states that LAN printers are unaffected, distinguishing it from network-level 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 provides clear context by specifying scope (cloud vs. LAN), implying when it is appropriate to call. It does not enumerate alternative tools or when-not-to-use conditions, but the unique purpose among siblings makes usage obvious.

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 clearly indicates a non-mutating read operation ('Show') and details what information will be reported. It does not mention error behavior or whether the tool performs a network round-trip, but for a status-read tool the disclosed contents are strong and sufficient.

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 wasted words. Every clause contributes specific value: the resource, the nature of the operation, and the exact data points 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?

Given there is no output schema, the description compensates by enumerating the key return values (account, region, token expiry, printer count). It does not describe the output structure or potential null/error states, but the tool is simple enough that the description is largely complete for invocation purposes.

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?

This tool has zero parameters, so the schema fully covers parameter documentation. The description usefully explains what the tool returns, which is more relevant than parameter semantics here. The baseline of 4 for no-parameter tools 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 states a clear verb ('Show'), a specific resource ('Bambu cloud login status'), and enumerates the exact contents returned (credentials existence, account, region, token expiry, connected cloud printers). This distinguishes it from siblings like cloud_logout, sync_cloud_printers, and get_status without needing to inspect schemas.

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

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

The description clearly implies when to use this tool: whenever an agent needs to verify Bambu cloud login state or cloud printer connectivity before performing cloud operations. It does not explicitly mention alternatives or exclusions, but the status-checking context is unmistakable given the enumerated outputs.

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 discloses the transport mechanism ('via FTP') and the destructive nature of 'delete', but it does not state that deletion is permanent/irreversible, what happens if the file is missing or in use, or the mass-deletion implication of passing 'all' as the printer parameter.

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 filler: the action verb leads immediately and 'via FTP' earns its place by adding mechanism. It is appropriately sized; the brevity trades away behavioral context, but that gap is captured in other dimensions rather than being a structural failure.

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

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

For a destructive tool with no annotations and no output schema, the definition is thin. It omits return/error behavior, prerequisites, reversibility, effect on active prints, and the mass-delete consequence of 'all'. The tool is simple, but a deletion operation warrants more than a bare action statement.

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 `printer` and `remote_path` have their own descriptions in the schema — so the baseline of 3 applies. The description adds no parameter nuance beyond the schema and notably does not flag the potentially dangerous semantics of `printer='all'` for a delete.

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 the specific verb 'delete' with a clear resource ('a file from a printer's SD card') and even names the transport mechanism ('via FTP'). This clearly distinguishes it from the file-related siblings (download_file, upload_file, list_files) and from remove_printer, which targets printers rather than 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g., FTP must be enabled, printer reachable), and no cautionary note about the `printer='all'` option the schema permits for a destructive operation. Usage is only implied by the tool's name and one-line purpose.

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 behavioral burden. It usefully discloses the direction, source/destination, and protocol, but it does not mention local filesystem side effects such as overwriting local_path, FTP connectivity/auth requirements, or whether the printer is left unchanged.

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, focused sentence that front-loads the action and context without filler. Every word 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?

The core call is understandable, but with no output schema or annotations, the description does not explain return behavior, how the optional printer parameter is resolved, or required prerequisites. These gaps require the agent to infer or discover details elsewhere.

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 only general framing ('SD card', 'local machine') rather than clarifying path syntax, the optional printer parameter, or how FTP endpoints are resolved.

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

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

States the exact operation: downloading a file from a printer's SD card to the local machine via FTP. This clearly distinguishes it from sibling tools like upload_file, delete_file, and list_files by transfer direction and source/destination.

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 usage scenario is implied by the action: use it when you need to retrieve a file from the printer. However, there is no explicit guidance on when not to use it, no alternatives mentioned, and no prerequisites like FTP availability or prior use of list_files.

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

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

With no annotations, the description carries the full disclosure burden and handles it well: it reveals the JPEG return format, live capture nature, LAN networking requirement, Liveview prerequisite, IP auto-detection, and the stored-config auth mechanism. It does not cover failure behavior when prerequisites are unmet, but the core operational traits are transparent.

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

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

Three dense sentences with the core action front-loaded, followed by compatibility constraints and auth/auto-detection behavior. Every sentence earns its place; there is no filler or redundant restating of schema fields.

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

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

For a tool with zero required parameters, no annotations, and no output schema, the description covers the essentials: return type (JPEG image), prerequisites, and auth flow. Minor gaps remain — error behavior when the printer is unreachable or Liveview is disabled, and selection behavior when multiple printers exist without the printer param.

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%, giving a baseline of 3. The description adds meaningful context beyond the schema: that ip is normally auto-detected (making the param an override), and that access_code has a lifecycle — set once via set_camera_access for cloud printers — which the schema descriptions do not fully convey.

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

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

The description opens with a specific verb and resource — 'Capture a live JPEG snapshot from a printer's chamber camera over the LAN and return it as an image.' This inherently distinguishes it from camera-setting siblings (set_camera_access, set_recording, set_timelapse), file tools (download_file), and status tools (get_status). The model compatibility list (A1/A1 Mini/P1P/P1S) adds further precision.

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 use conditions: supported printer models, same-network requirement, and 'LAN Mode Liveview' enabled. It also references the prerequisite auth flow via set_camera_access. It stops short of explicitly stating when-not-to-use it or naming alternative capture tools, so it earns a 4 rather than a 5.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only lists what status fields are shown and does not disclose that the default result is cached, that `detailed` triggers a fresh push request from the printer, or the output format behavior; 'current status' is also slightly misleading given the cached default.

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 entire description is one front-loaded sentence with no filler: it states the action, scope, and representative output fields immediately. The trailing 'etc.' is slightly vague but does not add bulk.

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 a low-complexity read operation with three optional parameters, all documented in the schema. The description captures the main output categories, and the schema covers the remaining invocation details, though the lack of any annotation or mention of cached-versus-fresh data leaves a small completeness gap.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already explains `format`, `printer`, and `detailed` clearly. The description adds no parameter-level meaning beyond the parenthetical option of querying all printers, which is already present 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 uses a specific verb and resource ('Get current status of a printer (or all printers)') and enumerates meaningful status fields (progress, temperatures, speed, AMS, lights), so an agent can tell it apart from sibling commands like get_version or list_printers. It doesn't name or explicitly contrast any sibling, so it stops one point short of full 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?

There is no guidance on when to use this tool versus alternatives; the description simply states the operation. It mentions 'all printers' as an option but never says when to use 'all' vs a specific printer, and it doesn't mention the cached-vs-fresh distinction that would inform choice of the `detailed` parameter.

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 carry the behavioral transparency burden. It only names the information returned (firmware/module versions) and gives no detail on behavior such as output format, handling of 'all' versus a specific printer, or whether any side effects could occur. 'Get' implies a read operation, but the description does not disclose anything beyond that.

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 filler or redundant phrasing. It conveys the action, the subject, and the scope efficiently.

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

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

For a simple read-only information tool with one optional parameter, the description plus the schema is mostly sufficient. The only notable gap is the lack of an output schema or any indication of the response structure, but the parameter semantics are clearly covered.

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

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

The input schema already documents the only parameter with 100% coverage: 'Printer ID, 'all', or omit for single printer'. The description adds no additional parameter-level meaning, 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 description states a specific action ('Get') and resource ('firmware and module version information from a printer'), which clearly identifies what the tool does. It does not explicitly differentiate from sibling tools like get_status or cloud_status, but the version-specific focus is distinct enough.

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 intended use is implied: call this tool when firmware or module version details are needed for a printer. However, it provides no explicit guidance on when to prefer it over similar status-related sibling tools, and it mentions no 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 behavioral disclosure burden. It states the access method ('via FTP'), the scope ('printer's SD card'), and the nature of the operation ('List files'), which semantically indicates a read-only action. It stops short of explicitly saying it makes no modifications or describing failure modes, but the core behavior is transparent.

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

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

Two short, information-dense sentences with no filler. The core action and expected content are front-loaded, making the description 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?

For a simple two-parameter list tool with no output schema or annotations, the description covers the essential details: method, scope, and content type. It does not describe the return format, but an agent can reasonably infer a list of file entries from the verb and examples. The schema handles parameter details, so the description is nearly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides for 'path' and 'printer'. It stays at a functional level without enriching 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 names a specific verb ('List') and resource ('files on a printer's SD card via FTP'), with examples of returned content ('cached print files, timelapse videos'). This clearly distinguishes it from sibling file operations like download_file, upload_file, and delete_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?

The description implies when to use this tool (whenever you need to see files on a printer's SD card), but it does not explicitly state when not to use it or name alternatives. The use case is clear, but no exclusions or alternative routing 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?

With no annotations, the description conveys that this is a read-only listing operation and mentions the output includes connection status. However, it does not disclose whether the status is live or cached, whether offline printers are included, or any potential failure modes. This is acceptable for a simple list tool but leaves some behavior implicit.

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 states exactly what the tool does without any filler or repetition. Every word contributes to the agent's understanding.

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 low complexity, zero parameters, and straightforward purpose, the description is nearly complete. It names the resource and the output attribute. It could be slightly richer by indicating the expected return shape (e.g., a list of printer objects), but this is not a critical gap for a simple list 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?

The tool has zero parameters and the schema has 100% coverage by being empty, so there is no parameter semantics burden on the description. Per the baseline rule for 0-parameter tools, a score of 4 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 uses a specific verb ('List') and a clear resource ('all configured printers'), and it identifies the key returned attribute ('connection status'). This clearly distinguishes it from sibling tools like add_printer, remove_printer, reconnect_printer, and list_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?

The description provides no explicit guidance on when to use this tool versus alternatives such as get_status or cloud_status. An agent must infer the appropriate context from the name and sibling list 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?

The description discloses the core state-changing behavior of pausing, but with no annotations it does not address side effects, idempotency, or behavior when no print is active. This is adequate for a simple operation but leaves some behavioral gaps.

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

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

A single concise sentence that front-loads the action and scope with no filler.

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

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

For a single-optional-parameter tool with full schema coverage, the description is essentially complete for invoking it correctly. It could be improved with usage guidance, 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?

The input schema already documents the only parameter fully (Printer ID, 'all', or omit for single printer). The description repeats the 'or all printers' scope but adds no semantics 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?

States a specific verb ('Pause') and a clear resource ('current print' on a printer). It is semantically distinct from sibling tools like resume_print and stop_print, so an agent can tell them apart.

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 choose pause over resume_print or stop_print, and no conditions such as requiring an active print are mentioned. Usage must be inferred from the tool's name rather than described.

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 does reveal the underlying behavior (re-reading config, re-establishing MQTT connections), which is useful, but it does not mention side effects, whether active prints are disrupted, idempotency, or any required permissions.

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

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

The description is a single compact sentence that states the action, scope, and mechanism with no filler. The key scoping information 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?

Given the tool's low complexity, one optional parameter, and no output schema, the description is mostly complete for invoking the tool correctly. It could be more complete with a note on return values or effects on ongoing prints, but for a simple reconnect operation it covers the essentials.

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 the lone parameter is fully described in the schema: 'Printer ID, 'all', or omit for all printers'. The description reinforces the all-printers option but adds no new parameter semantics 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 clearly states a specific verb ('Reconnect'), resource ('printer'), and scope ('or all printers'), plus the mechanism ('re-reading config and re-establishing MQTT connections'). This distinguishes it from sibling tools such as add_printer or list_printers.

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

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

The description implies the tool is used when printers need to be reconnected, but it does not explicitly state when to prefer this over alternatives like sync_cloud_printers or get_status, nor does it mention any exclusions or prerequisites. The context is understandable but 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 burden of behavioral disclosure. It does add meaningful context by stating 'Disconnects MQTT and removes from config,' which informs the agent of side effects. However, it does not mention permanence, whether associated data is deleted, or any permissions required, so the transparency is partial rather than complete.

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

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

Two short sentences front-load the primary action and then add the most relevant behavioral detail. There is no redundant wording, and every clause contributes useful information. This is an appropriately sized description for a simple one-parameter tool.

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

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

For a low-complexity tool with one well-documented parameter and no output schema, the description provides enough information to make a correct call: the agent knows the effect, the relevant side effects, and the required id. The only notable omission is an explicit statement about irreversibility, but the operation is a removal, so the context is largely complete.

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

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

Schema coverage is 100%: the id property is described as 'ID of the printer to remove.' The tool description adds no further parameter-level detail beyond what the schema already provides, so the baseline of 3 applies. It does not introduce confusion, but neither does it enrich 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 and resource: 'Remove a printer from the fleet.' It goes beyond a bare label by naming concrete side effects ('Disconnects MQTT and removes from config'), which clearly distinguishes it from siblings like add_printer, reconnect_printer, and list_printers.

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

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

The purpose itself implies when to use it—when a printer should be removed from the fleet. However, the description gives no explicit guidance about alternatives or exclusions, such as preferring reconnect_printer for transient connectivity issues. There is no misleading information, but the guidance is only implicit, not explicit.

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

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

With no annotations, the description carries the behavioral burden. It clearly identifies a state-changing action and target scope, but it does not disclose behavior when no print is paused, whether the operation is idempotent, or if resuming on 'all' skips printers with no paused job. This is a minimal viable disclosure, not a rich one.

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 filler. Every word contributes meaning: the action, the target state, and the scope.

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

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

For a one-parameter tool with no output schema or annotations, the description covers the basic purpose but leaves gaps around error handling, idempotency, and what happens with 'all'. The missing behavioral and usage context makes it adequate but not fully complete.

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

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

Schema description coverage is 100%, so the input schema already documents 'printer' as an ID, 'all', or optional. The description repeats the 'all' case but adds no new semantics, so the 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 uses a specific verb ('Resume') and resource ('paused print'), and it defines the scope ('on a printer (or all printers)'), which clearly separates it from sibling tools like pause_print, start_print, and stop_print. It is not a tautology and conveys the core action immediately.

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 'Resume a paused print' implies the tool should be used when a print is paused, but it does not explicitly state when to use it versus alternatives such as start_print or stop_print, nor does it mention 'all' as a bulk operation beyond the schema. This is adequate implicit guidance, not explicit routing.

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

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

With no annotations, the description carries the safety burden and does disclose that some dangerous commands are blocked and that delivery can target all printers. However, it does not disclose side effects of arbitrary G-code, reversibility, or execution/error behavior, so the transparency is partial.

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 filler, with the core action and scope front-loaded and the safety caveat in the second sentence. Every phrase contributes.

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 schema covers parameters richly and the description establishes the raw/safety context, which is enough for basic invocation. It is missing guidance on when high-level siblings should be preferred and what the tool returns or does on failure, leaving the agent to infer those.

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 well, including examples and the blocked list. The tool description adds framing ('raw', 'all printers') but no additional parameter-level meaning beyond what the schema provides, matching 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?

States a specific action ('Send a raw G-code command') on a clear resource (a printer, or all printers), and the word 'raw' distinguishes it from the high-level printer-control siblings. It conveys exactly what the tool does without needing to inspect the schema.

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

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

The description implies this is the low-level escape hatch for arbitrary G-code, while siblings like pause_print, stop_print, and set_temperature cover high-level operations, but it never states when to prefer those instead. It mentions blocks on dangerous commands but no explicit when-to-use/when-not-to-use guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clarifies that this is a persistent store operation affecting later get_camera_frame calls, and explains that the IP is normally auto-detected. It does not mention overwrite behavior, validation of the access code, or security implications, but the core side-effect is clear.

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 key action and purpose are front-loaded, and the clarifying detail about the 8-digit code is relevant and placed second.

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 3 parameters and no output schema, the description is largely sufficient: it explains what is stored, where the value comes from, and why it is needed. It could be slightly more explicit about invocation timing relative to get_camera_frame, but the current wording covers the essential 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 reinforces the access_code format and the optional nature of the IP, but it mostly restates what the schema already documents. It adds the authentication context, but little new parameter-level 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 uses a specific verb ('Store') and identifies the exact resource: the LAN access code and optional IP for a printer's chamber camera. It also names the dependent sibling tool (get_camera_frame), which clearly differentiates it from camera-related siblings like set_recording or set_timelapse.

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 clearly implies when to use this tool: before calling get_camera_frame, so that authentication can succeed. It does not explicitly state when not to use it or name alternatives, but the purpose clause gives strong contextual 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 behavioral burden. It discloses scope ('or all printers') and options (chamber/work light), but does not mention side effects, persistence, return behavior, or prerequisites for a mutating control operation.

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 short sentences with no filler. The core resource and scope are front-loaded, and the supported light types follow immediately.

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 command, the schema fully documents parameters and the description states the scope options. However, with no annotations and no output schema, details about operation semantics and effects are left unspecified, making it adequate but not complete.

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

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

Schema coverage is 100% and each parameter already has a clear description, including the default for light and the meaning of printer='all'. The description adds little beyond what the schema provides, so the 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 names the resource (LED lights on a printer) and scope (single or all printers), and lists the two supported light types. The verb 'Control' is somewhat generic, but the resource is specific enough to separate this from sibling set_* 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 intended use is implied by the resource, but no explicit guidance says when to prefer this over alternatives or when not to use it. There are no exclusions or sibling comparisons, so an agent must infer context from the tool name and schema.

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 only indicates a mutating 'Set' action and a profile-selection purpose, with no mention of permissions, persistence, validation, side effects, or what changes visibly.

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 starts with the verb and object and adds the purpose in a parenthetical. Every word earns its place and there is 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?

For a simple two-parameter setter with a complete schema, the description is minimally sufficient for an agent to call it with the required diameter. However, with no annotations and no output schema, it lacks behavioral context and side-effect disclosure, leaving some 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 already describes both parameters with 100% coverage, including units and the 'all' option for printer, so the baseline is 3. The description adds no new parameter meaning beyond restating the action.

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 ('Set') with a concrete resource ('nozzle diameter') and target ('printer'), and the parenthetical clarifies this is a profile-selection operation. It clearly states what the tool does, though it doesn't explicitly differentiate from sibling tools.

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

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

The phrase 'for profile selection' establishes a clear use context and distinguishes this from hardware-level or other printer operations. It doesn't name alternatives or state when not to use it, so it stops short of full exclusion 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?

Annotations are absent, so the description carries the full burden. It only discloses the basic state change (enable/disable) but does not mention side effects, whether the operation is reversible, prerequisites like camera availability, the effect of using 'all', or return/error behavior. For a mutation tool this is a notable 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?

One sentence with zero wasted words, front-loaded with the action and resource. The parenthetical scope is efficient and reinforces the optional 'all' behavior 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?

The tool is simple and the input schema is rich, but there is no output schema or annotations, and the description says nothing about return values, error handling, or asynchronous behavior. It is minimally adequate for a toggle operation but leaves some operational context unstated.

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

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

Schema description coverage is 100%, with both 'enabled' and 'printer' already fully described. The description's mention of '(or all printers)' merely restates what the schema's printer parameter already documents, adding no new semantic meaning beyond the structured input definitions.

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

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

The description clearly states a specific action ('Enable or disable'), a specific resource ('camera recording'), and a scope ('on a printer (or all printers)'). It distinguishes itself from camera-related siblings like set_camera_access (permissions) and set_timelapse (a different recording mode) by explicitly focusing on recording.

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 intended use is implied: use this when you want to toggle camera recording. However, there is no explicit guidance on when to use this tool versus alternative camera tools in the sibling list, such as set_camera_access or set_timelapse, and no mention of 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the operation scope (single printer or all printers) and the two input modes, but it omits side effects, persistence, immediate application to an active print, and permission requirements.

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

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

Two short sentences with no filler. The main action and scope are front-loaded, and the parameter mode guidance is immediate.

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 full parameter schema coverage, the description is adequate. However, there is no output schema and no annotations, so operational unknowns remain: what happens when neither percent nor profile is provided, and whether the change affects an active print.

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 the parameters, including the profile/percent priority rule. The tool description only restates the profile-vs-percent choice without adding new 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 names a specific action and resource ('Set print speed on a printer') and clearly includes the 'all printers' scope. This distinguishes it from related siblings like set_temperature and set_nozzle.

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 communicates when to use the tool: to set print speed on one or all printers. It also gives immediate usage guidance ('Use a profile name or a raw percentage'). There is no explicit alternative tool to exclude, but the context is clear.

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

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

With no annotations provided, the description carries the burden, and it does add a behavioral constraint via explicit safety limits (nozzle max 300C, bed max 120C). However, it does not disclose side effects like heater activation or impact on an active print, nor how out-of-range temperatures are handled.

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

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

Two short sentences with no filler. The main action is front-loaded and the safety limits are placed immediately in a compact parenthetical, making the definition highly scannable.

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 3-parameter command with full schema documentation, the description covers the action, target, and limits. The main gap is not stating how the tool reacts when a temperature exceeds the listed maximum, such as clamping versus returning an error.

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 met. The description adds value by encoding safety bounds for the temperature parameter that are not present in the schema. It does not add anything for target or printer, but those are already fully specified.

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 uses a specific verb ('Set') and names the exact resource ('nozzle or bed temperature on a printer'). It clearly conveys what the tool does, though it does not explicitly distinguish it from the similarly-named sibling set_nozzle.

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 use case is clear: changing nozzle or bed temperature on a printer. It provides no exclusions or alternative recommendations, but the context is unambiguous enough for an agent to select this tool for temperature 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the state change and scope, but does not mention whether the setting persists, whether it affects ongoing prints, required permissions, or what response the agent should expect.

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 filler. The action and scope are immediately clear and 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 two-parameter state toggle, the description and schema cover the core mechanics of setting the value and choosing a target printer. However, missing usage guidance and behavioral transparency leave gaps around when to use this tool and what side effects may occur.

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 both 'enabled' and 'printer' are already documented in the schema. The tool description only echoes the 'all printers' possibility without adding meaningful new parameter detail, warranting the baseline score of 3.

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

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

The description states a specific verb ('enable or disable'), a clear resource ('timelapse recording'), and the scope ('a printer or all printers'). It is clear enough to be understood at a glance, though it does not explicitly differentiate itself from sibling tools like set_recording.

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 about when to use this tool versus alternatives such as set_recording or other printer controls. The description only explains what the tool does, not which circumstances warrant choosing it or avoiding 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?

No annotations are provided, so the description carries the full disclosure burden. It reveals that this is a certificate-based signing operation for authentication, but it does not state what the tool returns, in what format, or any error/prerequisite 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 two tight sentences: the first states the core operation, the second adds the relevant firmware/authentication context. There is no filler or repetition.

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

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

For a single-parameter tool, invocation is mostly clear, and the auth purpose is helpful. However, with no output schema and no annotations, the description omits what the signing returns, which an agent would need to properly complete an authentication flow.

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 schema already describes 'message' as the payload to sign with the X.509 private key. The description reinforces the authentication context but adds no new parameter-level details such as encoding, size limits, or format requirements.

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

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

The description opens with a specific verb ('Sign') and resource ('a message'), names the exact credential (Bambu Lab X.509 certificate), and explains the authentication purpose. This clearly distinguishes the tool from the printer/cloud sibling 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 concrete use condition: authenticate with printers running firmware that requires certificate-based auth (post-January 2025). No alternative signing tool exists among siblings, so the context is clear even without explicit 'when not to use' guidance.

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

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

With no annotations, the description carries the disclosure burden. It does state a key behavioral effect—skipped objects will not be printed—which is useful. But it does not disclose whether skipping is reversible, whether it applies to objects already in progress, or whether any confirmation or state change is returned.

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

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

Two short sentences with no redundant wording. The first sentence states the action, and the second clarifies the outcome. Every word earns its place.

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

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

For a simple two-parameter tool with fully described schema fields, the description is mostly adequate. However, with no annotations and no output schema, it would benefit from clarifying whether the skip applies only before printing begins, whether it is reversible, and what state changes occur to the ongoing print.

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 new meaning beyond the schema beyond restating that specific objects are skipped. The schema already explains object_ids come from print status and that printer is optional, so the description does not need to compensate.

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 identifies the action ('skip specific objects') and the resource ('a multi-object print'), and it adds the consequence that skipped objects will not be printed. It is distinct from sibling print-control tools like pause_print or stop_print, though it does not explicitly name an alternative.

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 'during a multi-object print' provides an implicit usage context, implying this tool is for excluding certain objects from a multi-object job. However, it does not explicitly state when to use this instead of pause_print or stop_print, nor does it mention prerequisites such as whether the print must be active or whether skipping is allowed after an object has already started printing.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that the file must already be on the SD card and that only .3mf and .gcode are supported. However, it does not mention side effects such as whether an ongoing print is interrupted, whether the call is asynchronous, or what a successful response contains.

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

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

The description is two sentences with no filler. It front-loads the core action, then gives supported file types and a minimal workflow. Every sentence contributes useful guidance.

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

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

For a 13-parameter physical action with no annotations and no output schema, the description covers prerequisites and supported formats but omits return behavior, error conditions, and side effects on the printer. It is adequate for basic invocation but has meaningful gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: the 'already on SD card' constraint and supported formats are already reflected in the file and path parameter descriptions. It does not explain the more complex parameters like ams_mapping or bed_type.

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

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

The description states a specific action and resource: 'Start printing a file that is already on the printer's SD card.' It names supported file types and points to list_files and upload_file, which clearly distinguishes it from sibling tools such as upload_file, pause_print, or stop_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 gives explicit workflow guidance: use list_files to find available files or upload_file to add one first. It does not explicitly contrast with start_prints or the pause/resume/stop siblings, but the intended invocation context is clear.

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

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It only mentions parallelism and speed, but omits critical details like partial failure handling, whether jobs are started atomically, and what the return value or error response looks like. This is insufficient for a batch mutation tool that could fail partway through.

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 fluff. The purpose is front-loaded and the efficiency comparison is stated succinctly. Every word earns its place.

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

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

For a batch operation that starts multiple prints across printers, the description is thin. It lacks information about error behavior (what happens if one printer fails), whether the operation is all-or-nothing, and what output or state changes to expect. With no annotations or output schema, the agent would have to guess these details. This is a significant gap for a tool of this 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%, so the schema already documents the jobs array and its nested properties. The description adds no additional parameter semantics beyond what the schema provides, which matches the baseline of 3 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 ('Start multiple prints across different printers') and explicitly contrasts it with the sibling start_print, calling out that it is much faster than calling start_print multiple times. This unambiguously distinguishes the tool's purpose.

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 when to use it: when you have multiple prints across different printers, and it positions itself as the parallel alternative to repeated start_print calls. It doesn't explicitly state when not to use it or mention edge cases, but the context is clear enough for an agent to select it appropriately.

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 behavioral burden. It clearly discloses the critical irreversible consequence of the action, which is the most important behavioral trait. It does not describe what happens to the print job or printer state beyond cancellation, but the key danger is explicitly surfaced.

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

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

One concise, front-loaded sentence states the action and scope, followed by a short warning. No filler or repetition; every part earns its place.

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

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

For a one-parameter, no-annotation, no-output-schema tool, the description plus schema covers invocation and the main irreversible consequence. However, the absence of explicit guidance toward the safer pause_print alternative creates a meaningful context gap for an AI agent selecting between 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 description coverage is already 100%, documenting the printer parameter including 'all' and omit behavior. The description reinforces the 'all printers' option but adds little semantic value beyond what the schema already states.

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

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

The description names a specific verb, 'stop/cancel', a clear resource, 'the current print on a printer (or all printers)', and the explicit warning differentiates it from pause-like operations. This is immediately distinguishable from siblings such as 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?

The description implies when to use it: when you need to cancel or stop a print. The 'cannot be undone' warning obliquely suggests it should not be used if resumption is desired, but it never explicitly names pause_print as the safe alternative or states when-not-to-use 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 carries the burden and does add useful behavioral details: it connects via cloud MQTT, works remotely, and depends on a prior login. However, it does not disclose potential side effects of 'sync' (e.g., whether it can alter or remove printer bindings) or what happens on repeated calls, leaving some ambiguity for a state-changing setup 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?

Two terse sentences front-load the action and scope, then add the remote behavior, and end with the prerequisite. Every sentence contributes necessary information with no filler or repetition of the tool name.

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

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

For a no-parameter tool with no output schema, the description covers what it does, where it operates, and what must happen first, which is nearly all an agent needs to invoke it correctly. It is only slightly incomplete in not describing what the sync result looks like or whether the connection persists, but this is minor given the tool's simplicity.

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

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

There are zero parameters and the schema properties object is empty, so there is nothing to document; the baseline for no-parameter tools is 4. The only requirement mentioned, 'npm run login', is a precondition rather than a parameter and is appropriately stated in the description.

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

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

The description uses specific verbs ('Discover', 'connect') and identifies the exact resource: printers bound to the Bambu cloud account. It also distinguishes itself from LAN/local operations by explicitly saying it works remotely over the cloud MQTT broker, which separates it from sibling tools like add_printer/list_printers that don't have this cloud-connection behavior.

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

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

It gives clear context: this is for cloud-bound printers and for remote use off the LAN, plus an explicit prerequisite ('Requires npm run login first'). It does not name alternative tools or state a hard 'when not to use', but the scope and precondition are unambiguous enough for an agent to decide when to invoke 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 provided, the description carries the full burden of behavioral disclosure, but it only states the action and scope. It does not mention potential side effects such as filament ejection, whether heating is required, what happens if no filament is loaded, or how failures are handled on a per-printer basis for 'all'.

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 filler. The core action and the key scope qualifier are front-loaded, and every word contributes to understanding the 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?

For a tool with one optional parameter, no output schema, and no annotations, the description conveys the essential operation and scope. However, it omits behavioral consequences and usage conditions, making it minimally adequate rather than fully complete.

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

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

Schema description coverage is 100%, so the schema already fully documents the 'printer' parameter. The description's mention of 'or all printers' reinforces the schema but adds no new parameter semantics, so 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 uses a specific verb ('Unload') and clearly identifies the resource ('current filament from the extruder on a printer'). It also adds scope ('or all printers') to clarify multi-printer behavior. However, it does not explicitly differentiate from sibling tools such as change_filament, so it stops short of 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 implies when to use the tool (when filament needs to be removed) and provides context about operating on a single printer or all printers. There is no explicit guidance about when to prefer this over change_filament or any stated prerequisites, exclusions, or alternative 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 carries the behavioral disclosure burden. It adds useful behavior beyond schema such as FTP transfer and supported file types, but it does not mention overwrite behavior, authentication/connectivity requirements, or what happens when printing to multiple printers via 'all'.

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 concise sentences with no filler. The core action and destination are front-loaded, followed by format constraints and a clear next step. Every sentence earns its place.

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

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

For a flat 3-parameter tool with complete schema coverage and no output schema, this is largely sufficient: action, destination, supported formats, and next step are all present. Missing error/overwrite semantics and the behavior of the 'all' printer option are notable but secondary.

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 value by constraining local_path to supported file types and confirming the destination as an SD card, which helps the agent choose a valid file. It doesn't elaborate on remote_path formatting or multi-printer behavior, so not a 5.

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

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

States 'Upload a local file to a printer's SD card via FTP', naming the verb, object, destination, and transport. The supported formats (.3mf, .gcode) and the pointer to start_print make the tool's role clear and distinguish it from download_file and other 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?

Explicitly provides a workflow: 'Use start_print after uploading to begin printing.' This gives clear sequential context, but it does not state when to avoid this tool or mention alternatives like send_gcode for non-file commands, preventing a 5.

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