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

No annotations, so the description carries the full burden. It usefully discloses the side effect (persisted to ~/.bambu-sentinel/config.json) and the LAN-mode constraint, but says nothing about behavior on duplicate serial, permission/auth needs, or failure modes, which matters for a mutation tool.

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

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

Three dense sentences, front-loaded with the action and followed by prerequisites and storage location. 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 no-annotation creation tool with 7 params, 43% schema coverage, and no output schema, this is minimally adequate. The persistence note is a plus, but undocumented params (id, name) and silent duplicate/error behavior leave real gaps.

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

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

Schema coverage is 43% (id, model, workshop_id documented). The description conceptually covers host/serial/access_code but leaves id and name undocumented in both schema and prose, so it only partially compensates for the coverage gap.

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

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

States a specific verb+resource ('Register a printer') with a mode qualifier ('LAN mode'). Siblings like discover_printers and remove_printer imply the lifecycle position, though the description does not name them explicitly.

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

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

Gives prerequisites (IP, serial, LAN access code) and tells where to find the access code (printer screen > Network). It does not say when to prefer this over discover_printers or what to do if the printer is already registered, so usage is implied rather than stated.

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

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

With no annotations, the description must carry the behavioral load. It does disclose the two checks performed and implies a read-only validation, but it says nothing about what the result looks like (per-printer pass/fail?), behavior on error, or whether it has side effects. Adequate but leaves real gaps for a validation 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 tight sentences, front-loaded with the precondition and then the concrete checks. No filler. The only mild cost is the conversational 'Before queueing:' preamble, which does double duty as usage 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?

No output schema, no annotations, and 0% parameter coverage, so the description bears the full burden. It explains what is checked but not the response shape, the treated plate, or failure semantics — not enough for an agent to consume the result reliably.

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

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

Schema coverage is 0% for both parameters, and the description never mentions 'plate' — which is consequential since plate selection determines what is actually checked in a multi-plate sliced file. 'This sliced file' only loosely maps to file_path. The description fails to compensate for the documentation gap.

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

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

States a specific check ('will this sliced file fit on each printer?') and the two conditions it verifies (matching filament loaded, enough grams in the spools). This is clearly distinct from spool_list or queue_add, though it doesn't name a sibling explicitly. The core purpose is unambiguous.

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

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

'Before queueing' gives a concrete workflow trigger and makes the intended call site obvious relative to queue_add. There is no explicit when-not guidance or named alternative, but the timing context is clear enough for an agent to place the call correctly.

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

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

With no annotations, the description carries the full burden. It does add real behavioral context: the wear formula and the fact that values are snapshotted at print end rather than re-applied retroactively, which matters for correctness. But it is silent on whether the call merges with existing settings or replaces them (all 6 params are optional), and on any permission or persistence behavior.

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

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

Two sentences, front-loaded with the action, then a dense enumeration of inputs and the one piece of timing semantics that an agent cannot infer. 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 6-param, no-annotation, no-output-schema tool with thin schema coverage, the description covers almost all parameters and adds the snapshot-timing rule. The notable remaining hole is update granularity (partial vs full replacement) and the currency parameter's format.

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 only 17%, so the description must compensate, and it largely does: it explains electricity_per_kwh, printing_watts, machine_wear_per_hour (including the price/life-hours + upkeep formula), per_print, and filament_price_per_kg keyed by type. Only 'currency' is left unexplained in both places.

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

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

States a specific verb+resource ('Set the cost model') and enumerates the cost inputs it governs. It is distinguishable from estimate_cost and cost_report, which consume rather than set these values, though the description never makes that contrast explicit.

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

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

Usage is implied by the enumerated inputs, and the closing sentence gives useful timing context ('costs are computed when a print ends, with the values in force then'). However, it names no alternative and gives no prerequisites or conditions for when a cost model must be configured versus queried.

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 behavior burden. It usefully discloses that changes should be rehearsed ('Always rehearse after changing'), implying persisted, consequential config. But it does not say whether changes apply immediately, affect a specific printer, or are reversible, and 'rehearse' is unexplained jargon.

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

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

Three sentences, front-loaded with the tool's purpose and free of filler. Every sentence carries tuning or safety guidance, though the jargon 'rehearse' slightly taxes comprehension.

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

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

For a 13-parameter configuration tool with no annotations, no output schema, and 15% schema coverage, the description is under-specified. Ten parameters are left to bare schema types with no units, defaults, or interaction rules, and the powerful use_layout/x_positions behavior is not addressed.

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 only 15% across 13 parameters, so the description must compensate heavily and does not. It names only yStart/yEnd and sweeperWidth (three of thirteen) and even mismatches the schema's snake_case naming (y_start/y_end). x_max, x_min, z_push, bed_max_c, feed_mm_min, x_positions, nozzle_max_c, z_travel_min, layout_margin_mm and use_layout get no explanation beyond the schema.

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

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

The description states a specific verb and resource: 'Tune the sweep profile (bed coordinates, mm),' which tells an agent this configures eject/sweep behavior. It is distinguishable from the action-oriented sibling eject_plate, though it never names that sibling explicitly. Clear purpose, no explicit sibling routing.

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 tuning guidance ('Calibrate yStart/yEnd so parts clear the bed edge into your bin') and a workflow rule ('Always rehearse after changing'), which implies context of use. However, it never says when to call this versus eject_plate or configure_watch, and offers no 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 and does disclose real behavior: what auto_pause reacts to ('overtemp, confident vision failure'), what vision_sampling actually does per snapshot, and the client capability it requires. It omits persistence semantics (does a call replace or merge existing config?), whether the watch loop restarts, and any 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?

Purpose is front-loaded in five words, then a compact gloss per flag with the higher-risk detail (vision_sampling's sampling requirement) called out inline. Efficient, though the list-style glossing stops short of the interval parameter rather than trimming anything unnecessary.

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?

All parameters are optional and there is no output schema, yet the description never states defaults, whether an omitted flag is preserved or reset, or what watch_interval_sec controls in practice. The prerequisite for vision_sampling is good, but a zero-required-param config tool needs to explain the omission semantics.

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 only 20% (just auto_eject), so the description must compensate for four booleans plus the interval. It meaningfully defines three of them, but auto_eject is left to the schema's terse note and watch_interval_sec (15-600s) is never mentioned at all, leaving a gap the agent must guess about.

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?

'Configure background supervision' gives a specific verb and resource, and the per-flag glosses make clear this tunes the watch loop rather than the printer itself. It is distinguishable from configure_eject/configure_cost by subject matter, though it never names those siblings explicitly.

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

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

The glosses imply when each flag matters (auto_pause on overtemp, vision_sampling for periodic judgement), and it usefully flags the MCP-sampling prerequisite. But there is no explicit when-to-use/when-not guidance, no mention of how this relates to configure_eject (which owns auto_eject) or to queue_dispatch, so routing is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses a real side effect (immediate queue dispatch when auto_dispatch is on) and the consequence of omission. It stops short of covering idempotency, permissions, or failure behavior for what is a state-mutating call.

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

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

Three short sentences, front-loaded with the action and followed by the operational consequence and the conditional side effect. Every sentence carries distinct information with no 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 one-parameter, no-annotation, no-output-schema tool, the description supplies purpose, timing, and downstream effect, which is nearly everything an agent needs to call it correctly. It leaves open edge cases like repeat invocation or error handling, but those are minor here.

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?

One optional parameter with 100% schema description coverage, so the schema already explains printer_id and its single-printer omission rule. The description adds no further meaning, which is the expected baseline when the schema does the work.

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

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

States a specific verb and resource — informing the scheduler that the build plate was emptied — and goes further by describing the mechanism (the queue will not advance without it), which distinguishes it from the sibling queue_dispatch that it implicitly triggers.

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

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

Gives a clear trigger condition ('after the last print') and a strong reason to use it ('Without this the printer is never given a new queued job'). It does not, however, name or exclude near-neighbor siblings such as eject_plate, configure_eject, or save_empty_plate_reference, so the agent must infer the boundaries.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only aggregation and discloses the returned metrics, which is helpful, but it never states that the operation is non-mutating, says nothing about permissions or cost of execution, and does not explain behavior when no prints exist in the window.

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

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

A single front-loaded sentence that opens with the core concept before listing metrics. Dense but every clause carries information; only the long enumeration risks readability.

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

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

With no output schema, the description usefully enumerates the return metrics, which is good compensation. But with no annotations and zero parameter documentation, an agent still lacks the mutability profile and the meaning of printer_id, so it is not fully self-sufficient.

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

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

Schema description coverage is 0%, so both printer_id and since_days (default 30, max 3650) are undocumented. The description flirts with printer_id via 'per printer' but never says whether it filters to one printer or adds a per-printer breakdown, and 'over a period' does not tell the agent how to set that period.

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

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

The description gives a specific resource (spending over a period drawn from print history) and enumerates the exact metrics returned: total cost, wasted money on failed/cancelled prints, grams, energy, and average cost per finished print. That distinguishes it in substance from estimate_cost (forward-looking estimate) and configure_cost (settings), though it never names those siblings explicitly.

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

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

Usage is implied by 'from the print history' and 'over a period', which positions this as a retrospective reporting tool, but there is no explicit when-to-use statement, no mention of when to prefer estimate_cost instead, and no 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?

The destructiveHint=true annotation already signals the safety profile. The description adds the explicit confirm requirement, but this is largely redundant with the schema, which marks confirm as required. It does not disclose permissions, irreversibility, or error behavior.

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

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

Two short sentences, front-loaded with the action and immediately followed by the critical precondition. Every sentence earns its place 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 destructive mutation tool with incomplete parameter documentation and no output schema, the description covers the core action and confirmation requirement. However, it leaves important invocation details (e.g., remote_path format, printer_id omission semantics) to the schema, which only partially documents them.

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 only 33% (only printer_id has a schema description). The description clarifies the expected value for confirm (true), but says nothing about remote_path format or printer_id behavior. With a low-coverage schema, the description fails to compensate for the undocumented parameters.

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

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

The description states a specific verb ('Delete') and resource ('a file from the printer storage'), making the operation clear. It does not explicitly differentiate from sibling tools like list_printer_files or upload_file, but the action is unambiguous.

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

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

It states a prerequisite ('Requires confirm=true'), which is useful invocation guidance. However, it gives no context on when to use this tool versus alternatives, nor does it mention any exclusions or related workflows.

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

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

With no annotations, the description carries the full load and does well: it discloses the SSDP-then-probe order, the MQTT/TLS port 8883 with certificate reading, that the access code is never broadcast, that only private ranges are touched, and that timeout_sec bounds only the SSDP listen. It does not say how long a full /24 probe takes, whether it is rate-limited, or what the overall result set looks like.

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

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

Four sentences, purpose front-loaded, each carrying operational information an agent needs (fallback logic, port, range restriction, pairing handoff). Slightly dense but nothing is padding; the 'read it on the printer (Settings > Network)' aside is the only mildly expendable clause.

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

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

No output schema exists, so the description must cover results; it names the SSDP fields (IP, serial, model) but not what a subnet probe returns or the merged shape, which is a gap for a tool an agent must parse. Everything else needed to invoke it correctly — cost, scope, safety — is present.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it defines the scan='always' trigger that the schema only implies, scopes subnet to private ranges, and clarifies that timeout_sec applies specifically to the SSDP listen phase rather than the whole call. It leaves scan='never' undefined in both places.

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?

Opens with a specific verb and resource: 'Find Bambu printers on the local network.' No sibling tool does discovery, and the description makes clear this is the entry point before add_printer, so an agent can place it correctly among 50+ 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?

Explains the two-phase behavior (SSDP first, subnet probe as fallback or forced), names the scan='always' condition that selects the expensive path, and routes the LAN access code to add_printer, implying discovery precedes pairing. It never explicitly states when not to use it or what alternatives exist, so it falls short of a full 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?

Beyond the destructiveHint annotation, it discloses rich behavior: it destroys/sweeps parts, waits for bed cooldown, only runs when idle/finished, aborts on a new print, and rehearses at +25mm with nothing touched. These are exactly the safety-critical traits an agent needs before a destructive call.

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

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

Purpose is front-loaded, then the safe workflow, then preconditions, then the fallback. Five dense sentences with no filler; each one carries operational information an agent must act on.

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, 9-parameter tool with no output schema and only a destructiveHint annotation, the description covers mechanism, sequencing, preconditions, timing (cooldown), and the manual verification fallback. Nothing needed to call it safely is missing.

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

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

Schema coverage is high (89%), so the schema documents most params. The description still adds value by explaining the relationship and staging between dry_run, rehearsal, and confirm, and by tying cool_down to the cooldown behavior, going a step past the schema's field-level text.

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

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

The description gives a concrete verb+resource+mechanism: sweep finished parts off the plate with the toolhead, then verify with the camera, plus how the motion physically works (bed in Y, toolhead low). This is clearly distinguishable from siblings like confirm_plate_cleared and configure_eject.

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 lays out an explicit staged workflow (dry_run to inspect G-code, rehearsal to run 25mm higher, confirm for the real sweep), states preconditions (printer idle/finished, waits for cooldown, aborts if a print starts), and names the follow-up tool (confirm_plate_cleared) with the condition that triggers it.

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

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

With no annotations, the description carries the full burden, and it delivers real behavioral context: it discloses the cost model (spool price when a spool occupies the matching slot, otherwise per-type price; electricity derived from print time and configured power draw; machine wear; failure-rate-adjusted cost per good part). It does not cover error cases such as a missing printer or unmapped spool, but the computation semantics are unusually well exposed.

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 posing the core question, followed by the cost breakdown in a parenthetical. Dense but every clause carries information; the nested parenthetical slightly hampers scanning but does not waste words.

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

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

There is no output schema, so the description effectively stands in for return-value documentation by enumerating the cost components included in the estimate. It is complete enough for an agent to know what it will get back at a conceptual level, though units, currency, and the shape of the result are 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 coverage is only 25% (only printer_id is documented), so the description must compensate. It does add meaning for printer_id (which price source is used) and for file_path (must be a sliced file), but plate and quantity are never mentioned, leaving half the parameters unexplained in both places.

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 precise verb+resource+scope: estimating the print cost of a specific sliced file. It is clearly distinguishable from siblings like cost_report or configure_cost, which report or configure rather than estimate for one 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?

Usage is implied by the framing question ('What will this sliced file cost to print?'), which tells the agent this is a per-file pre-print estimate. However, it never states when to prefer it over cost_report, nor any prerequisites such as the file needing to be sliced or a printer needing to be selected.

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

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

With no annotations, the description carries the full burden. It does add real value by disclosing the granularity (one line per printer) and the fields returned, which implies a safe read-only summary. It does not confirm read-only behavior, whether results are live or cached, or how an empty fleet is 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?

A single front-loaded sentence with a parenthetical enumeration of returned fields. Every element earns its place; nothing is padded or repeated.

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

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

There is no output schema, so the description must convey return values, and it does so by listing the per-printer fields. For a zero-parameter read-only summary tool this is close to sufficient; minor gaps remain around freshness and behavior with no configured printers.

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

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

The tool takes zero parameters, which is the baseline-4 case. The parenthetical field list describes output content rather than inputs, but no parameter explanation is required here.

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 resource (every configured printer) and the shape of what is returned (one-line status with state, progress, temps, plate-cleared flag). The scope word 'every' implicitly distinguishes it from the single-printer sibling printer_status, but that sibling is never named, so the differentiation is left to inference rather than stated.

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

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

Usage is only implied: an agent can infer this is the fleet-wide summary to reach for instead of calling printer_status per machine. There is no explicit when-to-use, when-not-to-use, or named alternative, and no preconditions (e.g. whether printers must first be configured/discovered).

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 enumerates event categories, which is genuinely informative, but says nothing about the default 120-minute lookback, the 50-item limit, whether results are paginated, or the read-only nature of the call. For a tool with zero annotation coverage this leaves the agent guessing on several practical points.

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

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

A single front-loaded sentence that enumerates the payload compactly with no filler. It is terse to the point of omitting useful context, but there is no wasted verbiage.

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

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

With no annotations, no output schema, and four undocumented parameters, the description leaves significant gaps: no filtering instructions (printer_id, types), no time-window explanation, and no result-size guidance. It is adequate as a label for the tool but incomplete as a usage specification.

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 4 parameters at 0% schema description coverage, so the description must compensate and it largely does not: limit, types, printer_id, and since_minutes are never mentioned. The only faint signal is 'recent', which loosely gestures at the since_minutes window but gives no syntax or units.

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 (printer events) and enumerates the event categories returned (print started/finished/failed, pauses, HMS errors, anomaly alerts, auto-pauses), so an agent can tell what data comes back. It stops short of naming a verb or differentiating itself from neighbours like get_history or hms_active, which also surface printer timeline data.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as get_history or hms_active. The word 'recent' hints at a recency scope but the agent gets no trigger conditions for choosing this tool over its siblings.

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

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

No annotations are provided, so the description bears full behavioral burden. It hints at return content (outcomes, a success summary) but says nothing about scope (per-printer vs global), ordering, pagination beyond the limit param, or whether the history is bounded.

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

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

A single tight sentence with no filler, front-loaded on the resource. It is concise, though this brevity contributes to the specification gaps noted elsewhere.

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

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

With no annotations, no output schema, and two undocumented parameters, this short description is insufficient for an agent to call the tool correctly or know what it will get back.

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?

Two parameters exist with 0% schema description coverage, so the schema does not compensate. The description never mentions 'limit' or 'printer_id' — notably it does not say the history can be scoped to a single printer, which is a meaningful omission.

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 verb-ish resource, 'print history', with a hint at content ('outcomes and a success summary'). But it does not distinguish this from sibling history/diagnostic tools such as get_events, inspect_print, or get_snapshot, and 'print' is ambiguous between a verb and a 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?

There is no guidance on when to call this versus alternatives like get_events or printer_status, nor any prerequisite or context. The agent is left to infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a non-destructive read by nature of 'capture a frame,' but says nothing about the return format (image/blob?), resolution, latency, or whether a live printer connection is required. For an unannotated tool this is a significant gap.

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

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

A single, front-loaded sentence with no wasted words that clearly names the action and the target. It is efficient, though minimal enough that it could have afforded one more clause of useful context.

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

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

For a simple one-optional-parameter tool this is close to adequate, and 'camera frame' gestures at the return type despite there being no output schema. Still, it leaves the agent guessing about the actual response shape and any connection requirements.

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 single printer_id parameter is already documented as optional when only one printer is configured. The description adds nothing about the parameter beyond what the schema states, so the baseline 3 is appropriate.

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

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

States a specific verb (capture) and resource (live camera frame from the printer), so an agent immediately knows the action and target. It does not explicitly contrast with siblings, but no sibling overlaps this function, so the differentiation is implicit rather than stated.

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

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

The phrase 'live camera frame' implies the tool is for visually inspecting a printer's current state, giving implied usage. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g. printer must be online), and no named alternative for the closely related printer_status.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the returned content (text, severity, reprint advisability), but says nothing about read-only nature, permissions, rate limits, or behavior when no errors exist.

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

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

A single front-loaded sentence with no filler that efficiently conveys scope and payload.

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

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

With no annotations and no output schema, the description partially covers the return payload but omits the parameter's meaning and any behavioral context. Minimally adequate for a simple read tool but leaves gaps.

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

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

Schema description coverage is 0% and the description never mentions the sole parameter printer_id. It is reasonably self-evident for a printer-scoped tool, but the description adds no meaning beyond the bare schema property.

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 resource (active HMS errors) with a clear scope qualifier (currently active, on a printer) and names the decoded payload fields. This distinguishes it from hms_lookup/hms_import, though it never explicitly routes against those siblings.

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

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

The phrase 'currently active' implies when this is appropriate versus historical error lookups, but there is no explicit when-to-use, when-not, or named alternative despite the presence of hms_lookup and hms_import.

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

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

With no annotations, the description carries the full burden and discloses two real behavioral facts: the persistent side effect (data is saved to ~/.bambu-sentinel/hms.json) and the downstream effect of the 'retry' field on automatic reprints. It still omits whether an existing dictionary is merged or overwritten and what happens on malformed input, so it is not fully transparent.

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

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

The action is front-loaded and packed into two sentences with the format examples, destination, and field semantics all earning their place. The nested JSON notation is dense but compact rather than redundant.

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

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

For a mutation tool with no annotations, no output schema, and one parameter, the description covers input format and side effects but leaves gaps an agent would want: overwrite/merge behavior on the target file, error handling for invalid JSON, and any indication of the result. 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 0% and the schema only says file_path is a string, so the description must compensate - and it does by spelling out the two accepted JSON shapes and the meaning of the 'retry' values inside the file. It stops short of clarifying path resolution or file-size limits, but it substantially enriches the single parameter.

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

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

States a specific verb and resource ('Import an HMS dictionary') and pins down the exact file formats accepted plus the destination, making it unmistakable against read-oriented siblings like hms_lookup or hms_active. An agent knows precisely what this tool does without opening the schema.

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

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

The description never says when to use this versus hms_lookup, hms_active, or the other HMS-related siblings, nor does it state prerequisites. There is no when-to-use or when-not-to-use guidance at all.

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

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

With no annotations, the description carries the whole burden. It usefully discloses a real behavioral limitation (the built-in table is tiny), but says nothing about what a decode produces, whether misses are errors or empty results, or any permission/latency traits.

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

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

Two sentences, zero filler, with the accepted formats front-loaded and the sibling cross-reference last. Every clause earns its place.

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

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

No annotations and no output schema, so the description is the only source of truth, and it omits what a successful decode returns (error name, severity, remedy) and how failures surface. Adequate for invocation, incomplete for interpreting results.

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

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

Schema coverage is 0% and the single param 'code' is bare, but the description compensates by giving concrete accepted grammars: '0700_8000_0002_0001', 16 hex digits, or an 8-hex-digit print_error. That is real input-format meaning beyond the schema, short of full completeness.

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 (decode) and both accepted resource forms (HMS code, print_error), and it explicitly distinguishes itself from the sibling hms_import. An agent can pick this tool over hms_active or hms_import without opening any schema.

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

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

It states the condition that selects the alternative ('The built-in table is tiny; load a full one with hms_import'), which is genuine routing guidance. It never states when not to use lookup or what happens if the code is absent from the tiny table, so it falls short of full when/when-not coverage.

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

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

With no annotations, the description carries the full load, and it does partially pay off by enumerating the returned data (plates, estimated print time, filament weight/types/colours), which compensates for the absent output schema. It says nothing about failure modes (unsliced/corrupt file), path resolution (local vs server path), or read-only/safety semantics.

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: verb+resource first, then the concrete fields returned after the colon. No filler, nothing repeated from the name or schema.

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 single-parameter read tool with no output schema, the description adequately covers what comes back, but it omits the two things an agent actually needs to call it successfully: what 'path' means and what happens on an invalid/unsliced file.

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

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

There is one parameter, 'path', at 0% schema description coverage, and the description never mentions it — not whether it is a server-local path, an uploaded-file reference, or how relative paths resolve. The one ambiguous input is left entirely undocumented.

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

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

States a specific verb (Read) and resource (sliced .3mf) and even enumerates the extracted fields (plates, print time, filament weight/types/colours). However it never distinguishes itself from the sibling 'inspect_print', which an agent could easily confuse it with when deciding how to inspect a print job.

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

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

Usage is only implied by the phrase 'sliced .3mf' — an agent can infer this is for interrogating a slice file before printing, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., inspect_print vs inspect_3mf).

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

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

No annotations exist, so the description carries the full burden, and it does disclose meaningful behavior: it is a non-destructive read ('check'), it aggregates several data sources, and the older comparison frame is conditionally present. It omits any note on capture latency, resource cost, or that it is side-effect free, which keeps it short of a 5.

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

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

One dense sentence with the operative framing ('Supervision check:') front-loaded and no redundant filler. The nested list of returned artifacts is long but each item carries distinct information.

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

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

With no output schema and no annotations, the description correctly takes on the job of enumerating what comes back and even flags the human-judgment guidance included in the payload. It is nearly complete for a one-optional-param read tool; only timing/cost expectations are absent.

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 there is a single optional parameter with its own schema description, so the baseline is 3. The description adds nothing about printer_id or the single-printer default behavior, but the schema already covers it.

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 and resource: a supervision check that returns a live frame, comparison frame, telemetry, anomalies, and recent events. This is clearly distinguishable from get_snapshot, get_events or printer_status by its composite diagnostic nature, though it doesn't name any sibling explicitly.

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

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

Usage is implied by the stated goal of 'judging whether the print is failing', and the phrase 'when available' signals a conditional path. However, it never says when to prefer this over get_snapshot, printer_status or get_events, nor any exclusions — the agent must infer routing from sibling names.

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

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

With no annotations, the description carries the full behavioral burden. 'Over FTPS' is a useful transport detail, but it omits everything else an agent needs for a network-bound operation: authentication expectations, behavior when the printer is offline, error/timeout semantics, and whether the listing is recursive or limited to the target directory.

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

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

A single, front-loaded sentence that contains no filler or repetition. It is efficient, though the brevity contributes to the missing usage and behavioral detail noted elsewhere.

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 read tool with no output schema, the description is minimally viable: it conveys the operation and transport. It falls short on what the listing returns (names only vs. size/date metadata) and on the omitted-printer_id case, which an agent must resolve to call it correctly.

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

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

Schema description coverage is 50%: printer_id is documented in the schema, but 'dir' has no description and defaults to '/'. The description does not clarify that dir is a path on printer storage, whether it is relative or absolute, or what happens when printer_id is omitted with multiple printers configured.

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 (list) and resource (files on the printer's storage), which is clearer than a tautology and clearly distinct from delete_printer_file or upload_file. However, it never names or contrasts those sibling tools, so differentiation is only implicit from the noun '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 when-to-use or when-not-to-use guidance, no prerequisite that a printer must be configured/reachable, and no pointer to sibling tools like upload_file or delete_printer_file that operate on the same storage.

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 a mutation ('Move') but does not describe side effects, required permissions, whether the machine must be idle, what happens if the workshop is invalid, or any return behavior.

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

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

The description is a single, front-loaded sentence with zero wasted words, making it structurally efficient. It is arguably under-specified, but for the conciseness dimension itself, it performs well.

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

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

For a mutation tool with two required string parameters, no schema descriptions, no annotations, and no output schema, the definition is far too sparse. An agent lacks essential context about prerequisites, side effects, and expected outcomes.

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

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

Schema description coverage is 0% and neither parameter is named or explained in the description. The words 'machine' and 'workshop' loosely map to printer_id and workshop_id, but there is no syntax, format, or identifier guidance to compensate for the missing schema 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 states a specific verb (Move) and resource (machine) with a clear destination (another workshop), which is more precise than a tautology. However, it does not differentiate itself from siblings like workshop_update or add_printer, so it cannot earn 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?

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The sentence 'Move a machine to another workshop' merely restates the action without adding contextual routing information.

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

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

With no annotations, the description carries the full behavioral burden and largely fails it. It does not say whether the paused state is retained for resume_print, whether the tool errors when no print is active, or what permission is needed. 'Pause' vs 'stop' semantics (reversible vs terminal) are left for the agent to guess.

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

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

A single short sentence with no wasted words, front-loading the action. It is efficient but thin, so it does not earn a 5.

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

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

For a one-optional-parameter action tool with no output schema and no annotations, the description is minimally viable. It omits the resume relationship and error conditions that would matter when an agent is choosing between pause_print, stop_print, and resume_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 coverage is 100% and the single printer_id parameter is already documented, including the note that it may be omitted when only one printer is configured. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb (pause) and resource (the running print), so the action is immediately clear. It does not, however, differentiate itself from the closely related siblings resume_print and stop_print, which is the only thing keeping it from 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?

There is no guidance on when to prefer pause over stop_print or resume_print, nor any prerequisite context (e.g., that a print must be actively running). The agent must infer the usage scenario entirely from the tool name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It enumerates the returned data fields, which is useful, but never states that this is a read-only operation, whether it hits the network/live hardware, latency, or failure modes when the printer is offline. For a tool with zero annotation coverage, that is a meaningful gap.

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

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

A single front-loaded sentence with no filler; the content list is the information, not 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?

With no output schema, the description takes on the job of describing the return payload and does so by naming the state categories included (temps, fans, layer, HMS errors, AMS trays). It is nearly complete for a one-optional-param read tool; only the read-only/behavioral framing 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?

There is a single optional parameter whose semantics are fully documented in the schema ('may be omitted when only one printer is configured'). The description adds nothing about printer_id, but with 100% schema coverage the schema already carries the load, so baseline 3 applies.

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

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

The description names a specific resource (one printer) and enumerates the payload (temps, fans, layer, HMS errors, AMS trays), so an agent can distinguish it from aggregate siblings like fleet_overview. It never names a contrasting sibling or states the action verb explicitly, but the scope is unambiguous.

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

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

The word 'live' implies this is for current-status polling rather than historical lookup (get_history) or snapshot capture (get_snapshot), so usage is inferable. However, no sibling is named and no when-not condition is given, leaving the agent to guess at alternatives.

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

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

With no annotations, the description carries the full burden. It usefully discloses the asynchronous dispatch model, automatic free-printer selection, filament matching, and priority ordering — real behavioral value. But it omits what happens on submission (does it return a queue id?), the retry/give-up behavior implied by max_attempts, and any permission or file-state requirements, which are significant gaps for a queue mutation.

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

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

Three short sentences, front-loaded with the action, and each sentence adds new information (what it does, how dispatch works, how priority orders runs). 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 an 8-parameter tool with no annotations and no output schema, the description covers the conceptual model but not the operational details: whether the file must already be uploaded, how printer_id pins versus the default scheduler behavior, what max_attempts means in practice, and what the caller receives back. 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 only 38%, so the description must compensate, and it partially does: 'Higher priority runs first' gives meaning to the undocumented priority parameter, and the filament-matching sentence explains the filaments requirement. However, name, notes, plate, file_path, and the printer_id/max_attempts interaction with the scheduler remain unexplained in both schema and description.

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

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

The description states a specific verb and resource ('Add a sliced file to the print queue') and clarifies the deferred-dispatch model, which separates it in spirit from immediate actions like start_print. It does not, however, explicitly name a sibling it is not (e.g. start_print, queue_dispatch, upload_file), so the differentiation is implied rather than stated.

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

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

It supplies useful context about how the queue works ('the scheduler later picks a free printer that has the right filament loaded'), but never states when to use queue_add versus start_print, upload_file, or queue_dispatch, and gives no prerequisites or exclusions. Usage is inferable from the queue framing rather than spelled out.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it discloses only that the job is removed. It does not say whether the removal is reversible, whether it requires confirmation, what error results if the job is already dispatched/printing, or what permissions are needed for this mutation.

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

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

Two short sentences, front-loaded with the core action and followed immediately by the disambiguation rule. No filler, and the most decision-relevant clause comes first.

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 action and the key alternative but leaves the parameter's provenance and the mutation's failure/reversibility behavior unstated. Adequate but with clear gaps an agent would need filled.

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

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

Schema description coverage is 0%, so the description must compensate for job_id, but it only implies the job is queued. It never states the parameter's format or origin (e.g., an id obtainable from queue_list), leaving a required parameter effectively undocumented.

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

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

States a specific verb and resource ('Remove a queued job') and explicitly differentiates itself from the sibling stop_print by the job's state (queued vs. already printing). An agent can place this against queue_list, queue_dispatch, and stop_print without opening any 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?

Gives an explicit when-not condition ('For a job already printing') paired with the alternative to use instead ('use stop_print'). That is the exact routing decision an agent needs for this family of print-control siblings.

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

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

No annotations, so the description carries the full burden. It discloses two useful behaviors: the plate-clear precondition and the reporting-only semantics of dry_run. However, it says nothing about the mutating effect (actual print starts), reversibility, or any permission requirements, leaving significant gaps for a write tool with zero annotation coverage.

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

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

Two sentences, no waste, with the action and scope front-loaded and the dry_run detail following. Every clause 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?

Covers purpose, precondition, and dry_run for a tool with no output schema. But with no annotations and no return description, it omits max_starts behavior and the concrete effect of dispatch, leaving it only minimally sufficient for a mutating tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains dry_run semantics well (preview of printer assignment and rejection reasons), but max_starts is never mentioned, leaving half the parameters undocumented in both schema and description.

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

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

States a specific verb and resource ('Start queued jobs on free printers') with a clear scope that distinguishes it from start_print (single print) and queue_add (enqueue only). The parenthetical precondition further sharpens the meaning.

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

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

Gives clear context: this is the dispatch step, requires the plate to be confirmed clear, and offers dry_run as a preview. It does not name explicit alternatives (e.g., start_print) or state when-not-to-use, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and it discloses the core behavioral trait: the estimation methodology (slicer 3MF estimate, then past runs of the same name, then a 60-minute fallback) and that running prints count with remaining time. It does not explicitly state that the tool is non-mutating or note any permission requirements, which is a minor 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?

Two tight sentences, purpose front-loaded ahead of the fallback heuristic details. Every clause earns its place 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?

There is no output schema, so the description must convey return values, which it does clearly (printer assignment, start/end, overall completion). It omits any caveat about estimate reliability or determinism, but covers what an agent needs to interpret the output.

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 two parameters (job_id, changeover_minutes) are already fully documented in the schema. The description adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb and resource ('Forecast the queue') and enumerates exactly what the forecast yields: printer assignment, start/end times, and completion time. It is clearly distinguishable from siblings such as queue_list (which lists) and queue_dispatch (which acts).

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 implies when to use it (to get timing forecasts), but there is no explicit when-to-use guidance or named alternative relative to queue_list or queue_dispatch. Usage is left to inference from context.

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

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

No annotations are provided, so the description carries the full disclosure burden. It notes the default filter (queued and printing) but says nothing about ordering, pagination behavior, permissions, or what the response contains. Too thin for a read tool with zero annotation coverage.

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

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

A single short sentence with the scoping detail front-loaded inside the parenthetical. No waste. It is appropriately sized, though brevity here reflects under-specification rather than tight editing.

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

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

With no annotations, no output schema, and 0% param coverage, the description is the only source of behavioral detail and it omits pagination, ordering, result shape, and the meaning of 'limit'. More is needed for an agent to call it confidently in a queue workflow.

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

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

Schema coverage is 0%, so the description must document both parameters. It partially compensates for 'status' by revealing the default (queued and printing), which the schema does not state, but 'limit' is left entirely unexplained (units, max, effect on results). Half the parameters remain undocumented.

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

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

States a specific verb+resource ('List queue jobs') so an agent knows it reads the print queue. The parenthetical narrows the default scope usefully. It doesn't distinguish itself from sibling get_history (which likely covers past/done jobs) or spool_list, leaving some ambiguity.

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

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

No indication of when to use this versus get_history, queue_eta, or the other queue_* tools. The only contextual hint is the default status filter, which is behavioral rather than a usage rule. An agent gets no guidance on when this is the right call.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutation but does not state whether the job must be queued (not printing), whether it requires specific permissions, whether it triggers re-scheduling, or what the response looks like.

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

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

Single efficient sentence, front-loaded with the action. Slightly under-specified rather than verbose.

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

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

With a mutation tool, no annotations, 0% schema description coverage, no output schema, and two undocumented parameters, the definition is too thin for an agent to call it correctly without guesswork about priority semantics and required job state.

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

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

Schema description coverage is 0%, so the description must compensate. It names 'priority' but provides no meaning: valid range, ordering convention, default, or whether higher means sooner. job_id is implied but not explained.

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

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

States a specific verb (change) and resource (queued job's priority) clearly. It is distinguishable from siblings like queue_add or queue_cancel, though the title is null and it doesn't explicitly contrast with siblings in text.

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 when-to-use guidance, no prerequisites, no mention of alternatives like queue_cancel or queue_dispatch. The agent must infer context entirely.

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 supplied, the description carries the full burden and does a good job: it discloses that this is a non-total removal (history is kept) and that the operation is blocked while printing unless force=true. It omits auth/permission requirements and what happens to the printer's configuration, but the key behavioral traits are 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?

Two tight sentences with zero waste. The removal semantics lead, and the force-override constraint follows immediately. Nothing could be cut without losing information.

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

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

For a 2-parameter tool with no annotations and no output schema, the description covers the important facts: what is destroyed (the printer, not its history) and the guard condition with its override. Only minor gaps remain, such as return behavior and re-addability.

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

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

Schema coverage is 0%, so the description must compensate. It successfully explains the non-obvious 'force' parameter (default refusal, override with true), but 'printer_id' gets no meaning beyond what its name implies. Partial compensation for the coverage gap earns a mid score.

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

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

States a specific verb+resource: 'Forget a printer.' An agent can tell this is the removal counterpart to add_printer. It doesn't explicitly name the sibling, but the operation is unambiguous.

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

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

Gives the operating condition ('refused while it is printing unless force=true'), which is genuinely useful guidance for invoking it. However, it never names alternatives or says when to prefer this over related tools like printer_status or add_printer; usage is implied rather than directed.

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

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

No annotations are supplied, so the description carries the full burden and adds nothing beyond the action itself. It does not state what happens if no print is paused (error vs no-op), whether the printer must be idle/connected, or what the result looks like.

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

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

A single front-loaded sentence with zero filler, appropriate for a simple action tool. Brevity is not achieved through vagueness here, though it leaves gaps that other dimensions penalize.

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

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

For a state-mutating tool with no annotations and no output schema, the definition omits preconditions, failure behavior, and confirmation of the resulting state. The schema covers the lone parameter, but the description is too thin to call the definition 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 printer_id is already documented there, including the 'may be omitted when only one printer is configured' behavior. The description adds nothing further, so the baseline 3 applies.

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

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

States a specific verb and resource ('Resume a paused print'), which is unambiguous and clearly pairs against siblings pause_print and stop_print. It does not explicitly name or route to those siblings, but the action is unmistakable.

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 versus pause_print/stop_print/start_print, and no mention of the precondition that a print must actually be paused. An agent gets the what but not the when.

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 meaningful precondition that the plate must be empty and the downstream use, but says nothing about whether an existing reference is overwritten, whether a printer/camera must be online, or how failure is handled for what is inherently a state-changing capture.

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-loaded with the action, then the precondition. No filler and nothing redundant with the name or schema.

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

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

For a two-parameter tool with no output schema, the description covers the action, the precondition, and the purpose. The main gap is overwrite/state semantics of the stored reference, which is minor but non-trivial for a capture tool.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The phrase 'make sure the plate is really empty' loosely reinforces the plate_is_empty flag but adds no new semantic detail, and printer_id is not addressed in the description. Baseline 3 applies.

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

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

States a specific verb and resource: 'Store the current camera frame as the known-empty plate.' An agent can tell this captures a reference image, distinct from confirm_plate_cleared or get_snapshot. It stops short of explicitly contrasting with those siblings.

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

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

Provides one precondition ('Make sure the plate is really empty first') and a purpose ('used to verify sweeps'), which implies the context. It never names the alternative actions (e.g., confirm_plate_cleared) or states when not to use it, so routing is left partly to inference.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful constraints: a 20-line cap, an allowlist of accepted command classes, and a state-dependent restriction during printing. It stops short of stating what happens on rejection or what the response contains.

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

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

Two tight sentences with the payload limit and allowlist front-loaded ahead of the printing-state exception. Every clause constrains behavior; nothing is 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 an un-annotated mutation tool with no output schema, the description covers safety constraints well but omits permissions/authorization context and any indication of success/failure behavior. It is adequate for a low-complexity two-parameter call but leaves gaps.

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

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

Schema coverage is 50%: printer_id is documented in the schema, while gcode has no description. The description partially compensates by implying multi-line G-code input ('up to 20 lines'), but it doesn't define formatting for the gcode parameter or clarify the printer_id default beyond what the schema already says.

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

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

States a specific verb and resource ('Send... G-code') and immediately scopes the payload ('up to 20 lines'). This clearly distinguishes it from siblings like set_speed or set_temperature, which achieve narrow effects declaratively rather than by raw G-code.

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

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

Provides a concrete when-not rule: 'Not allowed during a print unless it is a temp/fan/speed command.' That negative condition is valuable, but it never routes the agent to the sibling tools (set_speed, set_temperature, set_light) for cases that fall outside the allowlist.

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 but discloses almost nothing beyond the action itself. It doesn't state whether the operation is idempotent, whether it requires the printer to be idle, what it returns, or any permission requirements. For a simple state-set tool the risk is low, but the disclosure is still essentially absent.

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

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

A single short sentence that is front-loaded and wastes no words. It is efficient, though its brevity is also the source of the missing context noted elsewhere.

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 two-parameter toggle with no output schema and no annotations, the description is minimally adequate. It doesn't explain the effect of omitting printer_id, return behavior, or whether the set persists, leaving small but real 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 50%: printer_id is documented in the schema, while 'on' has no schema description. The description's phrase 'on or off' implicitly maps to the boolean 'on' parameter, partially compensating, and printer_id's optionality is covered by the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('turn on or off') and resource ('work light'), making the operation immediately clear. No sibling tool controls lighting, so no differentiation is strictly needed, but the description also doesn't mention scope (per-printer vs global), which the printer_id parameter implies.

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, no prerequisites, and no mention of alternatives. The description only restates the action; an agent gets no help deciding context such as whether the light can be toggled during an active print.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it only labels the levels. It does not disclose whether the change affects a currently running print, whether it is persistent, or any side effects of switching profiles during a job.

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 the resource first and the value mapping immediately after; every word earns its place with zero waste.

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

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

For a simple two-parameter setter with no output schema, the value mapping makes it largely callable. However, with no annotations and no behavioral notes, an agent still lacks context on the effect on running prints and persistence, leaving a real gap.

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

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

Schema coverage is only 50%, but the description compensates strongly by enumerating all four meanings of the required 'level' parameter (silent/standard/sport/ludicrous), which the schema itself does not document. The optional printer_id is covered by the schema. The description adds genuine value 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 gives a specific verb+resource ('Print speed profile') and enumerates what each level value means, so the agent knows exactly what the tool sets. It does not explicitly differentiate from siblings like set_temperature or set_light, but the target resource is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisite context (e.g., whether it applies to an active print or persists across jobs). The agent is left to infer all usage 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 full burden. It does disclose two genuinely useful traits: model limits are enforced (a safety guardrail) and celsius=0 turns the heater off (a non-obvious semantic). However it omits what happens when a value exceeds limits (rejected vs clamped) and any prerequisites such as printer connection or required state.

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

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

A single front-loaded sentence with the action first and the two constraints in a compact parenthetical. No wasted words and nothing important buried.

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

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

For a simple three-parameter mutation tool with no annotations and no output schema, the description covers the core behavior but omits failure/limit-handling semantics and any state or connection prerequisites. Adequate but with clear gaps for a write operation that has zero annotation coverage.

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 only 33% (only printer_id is documented), so the description must compensate and partly does: 'nozzle or bed' clarifies the target enum and '0 turns the heater off' gives meaning to celsius beyond a bare number. It still does not clarify units or valid range for celsius, leaving the two required parameters partially covered.

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

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

States a specific verb and resource ('Set ... target temperature') and enumerates the two scopes it acts on ('nozzle or bed'), matching the enum in the schema. An agent can distinguish it from set_speed or set_light, though it does not call out the overlap with send_gcode, which could also set heater temperature via G-code.

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

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

Usage is implied by the name and purpose rather than stated: nothing explains when to prefer this over send_gcode for temperature changes, or whether the printer must be idle/connected. The one operational hint ('0 turns the heater off') is a behavioral detail rather than when-to-use guidance, so this stays at the implied-usage level.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses downstream behavior (the scheduler checks fit and subtracts usage after each print) and that slot loading is an optional immediate side effect. It omits permissions, idempotency/duplicate handling, and persistence scope, which for a 9-parameter write tool is a real 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?

Two tightly written sentences with zero filler. The primary action is front-loaded and the optional slot behavior is correctly relegated to a trailing clause.

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

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

With no output schema and no annotations, the description must carry more weight. It covers purpose and downstream effects adequately but leaves undefined what happens on duplicate registration, whether slot assignment fails independently, and any permission requirements for a tool whose side effects reach the print scheduler.

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 78%, so the schema already documents most parameters (slot ranges, weight units, RRGGBB color). The description adds only a high-level note about weight and slot loading, contributing little semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Register a filament spool') and goes further by naming its downstream purpose: the scheduler uses the weight to check job fit and to decrement usage. It does not explicitly distinguish itself from the nearby spool_update / spool_assign siblings, which is the only thing keeping it out of the 5 range.

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 clause 'Optionally load it into a printer slot right away' implies when to pass a slot versus not, which is useful implied guidance. There is no explicit statement of when to use this tool instead of spool_update or spool_assign, so usage remains inferred rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the two modes (assign vs unload via clear=true), which is genuinely useful, but says nothing about permissions, what happens to a previously assigned spool, or whether the change is reversible. Moderate disclosure against a high burden.

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

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

Two compact sentences, front-loading the primary action before the unload variant and the usage cadence. No wasted words, though the phrasing 'Say which spool' is slightly informal rather than imperative.

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

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

For a mutation tool with no annotations and no output schema, the description covers the core action and the clear flag but omits the printer_id/slot relationship and side-effect details an agent would want. Adequate but with visible gaps.

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

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

Schema coverage is only 25% (only 'slot' is documented, richly so, with AMS/external slot semantics). The description compensates by explaining clear=true as an unload, but leaves spool_id (required) and printer_id unexplained, and never clarifies how printer_id relates to slot.

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

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

States a specific verb and resource: assigning (or clearing) a spool-to-printer-slot mapping. An agent can tell this sets filament/spool location. It doesn't explicitly distinguish itself from sibling spool_update, which could also touch spool data, 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?

"Do this whenever you change spools" gives a clear triggering condition, and the parenthetical explains the unload variant. No explicit when-not guidance or naming of alternative tools (spool_update/spool_add), 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, the description carries the full burden. It does disclose useful behavior beyond the name — that results include remaining grams, load location, and a low-filament flag — but says nothing about authentication needs, how archived spools are treated, or result ordering/size.

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

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

One sentence, front-loaded with the verb and resource, with the returned fields and the flagging behavior packed in without waste. Nothing is padded or redundant.

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

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

For a simple list tool with no output schema and no annotations, the description covers what comes back at a high level, but the sole parameter is left undocumented, so an agent cannot tell how archive visibility is controlled or what the default behavior is.

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

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

The single parameter include_archived has 0% schema description coverage and the description never mentions it at all, leaving the agent to guess what it controls. The description adds no meaning beyond the bare schema property name.

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

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

Specific verb + resource ('List spools') plus the payload it returns (remaining grams, loading location) and a distinguishing behavior (low-filament flagging). It is clearly separable from spool_add/spool_update/spool_assign/check_filament through the verb alone, but it never names or contrasts a sibling explicitly.

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

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

Usage is only implied: an agent can infer this is the inventory-read call used before assigning or replacing filament, but the description states no when-to-use condition, no exclusions, and no mention of alternatives such as check_filament or spool_assign.

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

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

With no annotations, the description carries the full behavioral burden, and it omits key traits: whether this is a partial update (unspecified fields preserved) or a replace, whether archived can be un-set, and what permissions or side effects apply. Only the archive-implies-empty hint gives any behavioral signal.

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 three parallel clauses and no filler. Compact and readable, though the parenthetical example sits mid-sentence rather than leading.

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 five-parameter mutation tool with no annotations, no output schema, and zero schema descriptions, this is thin. It communicates the main operations but leaves update semantics, required spool_id handling, and all result/error behavior unspecified.

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

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

Schema description coverage is 0% across five parameters, so the description must compensate. It conceptually covers three of them (remaining_g via weighing, price_per_kg via 'price', archived via 'archive') but says nothing about 'name' or the required 'spool_id', leaving real gaps.

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 (spool) and three concrete operations it performs: correcting values, changing price, archiving. That is specific enough to separate it from spool_add and spool_assign, though 'correct a spool' is slightly soft phrasing for what is really a field update.

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 three concrete use contexts — after weighing, price changes, archiving an empty spool — which tells the agent when this tool applies. It does not explicitly name alternatives (e.g. use spool_add to create, spool_assign to bind to a printer), so the guidance is contextual rather than exclusionary.

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

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

With no annotations, the description carries the full burden. It usefully discloses that filament slots are auto-matched against loaded AMS trays and that plate_cleared must be true, but omits that this is an irreversible machine-starting mutation, any permission/auth requirements, and how failure surfaces.

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 tight sentences, front-loaded with the action and format, followed by the auto-matching behavior and the hard precondition. 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 9-parameter, no-annotation, no-output-schema mutation tool, the description covers the essential precondition and AMS behavior but leaves half the parameters and the safety/reversibility profile unaddressed. Adequate but with material gaps.

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

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

Schema coverage is only 44%, so the description should compensate more. It adds real meaning for filaments/ams_mapping ('matched automatically') and local_path (accepted formats), but leaves plate, flow_cali, timelapse, bed_leveling, and printer_id entirely unexplained in both places.

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 compound action: upload a local .3mf/.gcode.3mf and start printing immediately. This distinguishes it from upload_file and queue_add by the 'start it now' framing, though it does not explicitly name those siblings.

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

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

Gives a clear precondition ('You must confirm the build plate is empty (plate_cleared=true)') and the implicit timing context ('now') that separates it from queued workflows. It stops short of explicitly naming queue_add as the alternative for deferred 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?

Annotations only declare destructiveHint=true; the description goes further by spelling out the concrete consequence ("the part is lost"), labeling the action irreversible, and disclosing the confirm=true gate. That is exactly the extra behavioral context a destructive tool needs.

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

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

Three short sentences, zero filler, with the action stated first and the two critical constraints (irreversibility, confirmation) immediately following. Every clause carries information.

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

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

For a no-output-schema destructive action, the description covers the essential facts: what is destroyed, that it cannot be undone, and the required confirmation. It does not mention side effects on the print queue or whether the printer returns to idle, a minor omission.

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, but the description adds value by elevating confirm from a documented field to a hard precondition ("Requires confirm=true"). printer_id semantics remain schema-only, which is fine given the schema documents them.

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?

"Cancel the current print" is a specific verb+resource pair, and the word "current" scopes it to the active job, distinguishing it from queue_cancel in the sibling list. An agent can tell what it does without opening the schema.

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

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

Usage context is implied rather than stated: the irreversibility warning hints that pause_print (also a sibling) may be preferable, but no alternative is named and no condition for choosing between them is given. Adequate but with a clear gap.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the default remote destination (/cache/<name>), which is real behavioral context beyond the schema, but it omits whether an existing file is overwritten, size or format limits, and any 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?

A single short sentence with the destination default front-loaded in parentheses. Efficient, though extremely terse for a mutation tool with three parameters.

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 write/mutation tool with no annotations, no output schema, and only 33% param coverage, the description is too sparse. It should at least state overwrite behavior and error conditions so an agent can invoke it safely.

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

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

Schema coverage is only 33%, so the description must compensate. It clarifies the default destination path behavior relevant to remote_path, but leaves local_path (the required param) and the optional printer_id semantics largely unexplained.

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

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

States a specific verb (upload) and resource (a local file) with a clear destination (the printer). This distinguishes it from sibling tools like list_printer_files, delete_printer_file, and inspect_3mf, though it doesn't explicitly name those siblings.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when-not to use it. The context (uploading files to a printer) is only implied by the description.

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 implies a write operation but doesn't disclose permissions required, whether names must be unique, what happens on duplicate names, or any side effects. Only the minimal 'creates' semantics is conveyed.

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 efficient sentence with no waste. It is front-loaded, though it errs toward under-specification rather than over-verbosity.

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

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

For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin. It omits uniqueness constraints, required vs optional params, and any indication of the returned workshop identifier needed for follow-up tools like machine_assign_workshop.

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

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

Schema description coverage is 0%, so both parameters are undocumented. The description adds no meaning beyond the parameter names 'name' and 'description' — it doesn't state whether 'name' must be unique, whether 'description' is optional, or any format constraints.

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?

Clear verb+resource: 'Create a workshop to group machines' states the action and the entity, plus the grouping purpose. It distinguishes itself from workshop_list/update/delete siblings by being the creation primitive, though it doesn't explicitly name alternatives.

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 when-to-use guidance, prerequisites, or routing to alternatives like machine_assign_workshop for adding machines afterward. Usage must be inferred from the name and sibling list.

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

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

The destructiveHint annotation already signals this is a mutation, and the description adds genuinely new context beyond that: machines are reassigned to the first remaining workshop, and the operation fails on the last workshop. It still omits whether deletion is reversible, what confirmation or permissions are required, and what a success response contains, so it is not fully 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 short sentences, front-loaded with the action and immediately followed by the two consequences an agent most needs. No filler, no restatement of the title, nothing wasted.

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

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

For a single-parameter destructive mutation with a covering annotation and no output schema, the description supplies the essential side effect and the failure condition. The remaining gap — reversibility and required authorization — is partly covered by destructiveHint, but an agent would still benefit from knowing whether this is undoable.

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

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

Schema description coverage is 0% and the single parameter (workshop_id) is never mentioned in the description, so no format, ID-source, or lookup guidance is provided. The parameter's meaning is inferable from the tool purpose, but the description adds no semantics the bare schema does not already 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+resource pair ('Delete a workshop'), so the action is unambiguous. It does not reference any sibling tool by name, so it earns a 4 rather than a 5, but nothing here could be confused with workshop_create, workshop_update, or machine_assign_workshop.

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 a concrete precondition for when the tool will not work ('The last workshop cannot be deleted'), which is the closest thing to a when-not rule for a tool with no true alternative. It does not spell out when deletion is appropriate versus restructuring with workshop_update, so it falls short of a full when/when-not/alternatives treatment.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose something valuable beyond structured fields: that the response pairs workshops with their member machines. However, it never states that the operation is read-only, whether results are paginated or ordered, or how large the list may be — gaps that matter more given the absence of annotations.

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

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

A single sentence with the resource front-loaded, the concept clarified in a parenthetical, and the return content appended. No filler and nothing that fails to earn 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?

With zero parameters and no output schema, the description is nearly sufficient: it names the entity and hints at the returned structure. Only the read-only/safety framing and any scale or ordering behavior are missing, which are minor for a simple list tool.

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

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

The tool takes no parameters, so the schema imposes nothing to document and the baseline of 4 applies. The description adds no parameter-relevant content, which is acceptable here.

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

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

States a specific verb and resource ('List workshops') and adds a clarifying gloss ('groups of machines') plus the returned relationship ('which machines are in each'). It is clear what the tool does, but it does not distinguish itself from nearby read tools like fleet_overview or discover_printers, 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?

Usage is only implied by the verb 'List' and the domain concept; there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling list/overview tools. For a zero-parameter tool whose purpose is self-evident, implied usage is the minimum viable but leaves routing to the agent.

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

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

No annotations are provided, so the description carries the full behavioral burden for what is clearly a mutation. It does not state whether a rename requires ownership or admin rights, whether the change is reversible, whether an omitted field (e.g. name) leaves the existing value untouched, or what happens if workshop_id is invalid. For a write tool with zero annotation coverage this is a significant gap.

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

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

A single short sentence with no filler, and the core action is front-loaded. It is efficient, though the extreme brevity is part of why so much behavioral information is missing rather than a sign of disciplined concision.

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

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

For a mutation tool with no annotations, no output schema, zero schema description coverage, and a required identifier, the description is not complete enough. An agent cannot tell how to identify the workshop beyond guessing at workshop_id, what permissions are needed, or what the result of a successful update looks like.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partially does. It conveys the meaning of 'name' (rename) and 'description' (change its description) but says nothing about 'workshop_id', which is the sole required parameter and the key that selects the target workshop. One of three parameters is effectively undocumented in both the schema and 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 gives a specific verb and resource: renaming a workshop or changing its description. It clearly implies an update of an existing workshop, which separates it from workshop_create and workshop_delete in the sibling list. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

There is no guidance on when to use this over workshop_create, workshop_delete, or the unrelated spool_update/machine_assign_workshop tools. No prerequisites, no exclusions, no context about when an agent should reach for this tool. Usage must be inferred entirely from the name.

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