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, and it discloses almost nothing: no indication that this is a mutating operation that attaches a modifier to an object, no mention of required state/permissions, reversibility, or how the modifier interacts with existing settings. Only 'v2' implies a versioned engine constraint, which is not actionable.

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?

It is a single short, front-loaded sentence with no padding, which is good, but it is concise by virtue of under-specification rather than editorial discipline. The parenthetical adds little information density.

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 4-required-parameter mutating tool with a nested settings object, zero annotation coverage, no output schema, and 0% schema documentation, this description is far too thin. An agent cannot determine accepted settings keys, range semantics, or the effect of the call.

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

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

Schema description coverage is 0% across four required parameters, so the description must compensate and does not. 'Height range' loosely maps to z_from/z_to, but object_id, the units/ordering of the range, and especially the open-ended 'settings' string map (nested object with additionalProperties) are completely undefined.

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 is a noun phrase fragment ('Different settings for a height range of an object') that restates the tool name rather than stating an action; the verb 'add' exists only in the name, and 'different settings' is ambiguous. It names the resource (object height range) but does not distinguish this tool from the sibling set_variable_layer_height, which also manipulates per-height behavior.

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

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

There is no guidance on when to use this tool, when not to, or how it relates to set_variable_layer_height or set_setting. The only hint is the parenthetical '(GUI engine, v2)', which is an environment tag, not a usage condition.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses return values ('returns its id and size') even though there is no output schema, which is genuine added context. However, it omits mutation side effects on plate state, error conditions for unsupported or missing files, and how copies are laid out.

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 compact sentence that front-loads the action, the accepted formats, and the return value. 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?

For a two-parameter mutation tool with no annotations and no output schema, the description covers input formats and the return shape but leaves meaningful gaps around 'copies' behavior and file-location requirements. It is adequate but 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 coverage is 0% and both parameters are bare in the schema. The format list partially clarifies what 'path' should point to, but 'copies' is completely undocumented and the description says nothing about path resolution (absolute/relative) or how multiple copies are positioned.

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 ('Add') and resource ('model file ... to the bed') and enumerates the accepted formats (STL, 3MF, OBJ, STEP, AMF), which sharply bounds what this tool consumes. It is clearly distinct from neighbors like remove_object, clear_plate, or transform_object, though it does not explicitly contrast itself with place_instance or explain its place in the slicing workflow.

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 says what the tool does but never when to use it versus siblings such as place_instance or transform_object, nor does it state prerequisites (does the file need to exist locally? must a plate be active?). The 'to the bed' phrasing hints at a pre-slicing step but leaves the agent to infer the workflow position.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it requires an existing sliced gcode file, what the output shape is, or any cost/limits. Only the vague word 'optionally' hints at optional behavior.

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

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

A single compact sentence with the output summary front-loaded and the optional capability trailing. Nothing is wasted, though the ellipsis-after-a-list style is slightly informal for a spec.

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% parameter documentation, the description is the only source of truth and is insufficient. An agent cannot tell what is required, what the parameters do, or what the result looks like, which is inadequate for a three-parameter analysis 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% across three parameters. The description only obliquely gestures at 'optionally the slowest layers', which loosely maps to include_layers and max_layers, but never names them, gives no defaults, and says nothing about the required gcode_path. It fails to compensate for the total lack of 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 resource and result: time and material broken down per move type (perimeters, infill, bridges, travel), with an optional layer breakdown. This tells an agent what the tool produces. However it offers no differentiation from the closely related sibling get_gcode_metrics, leaving ambiguity about which analysis tool to pick.

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

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

There is no explicit statement of when to use this tool versus alternatives such as get_gcode_metrics or find_print_risks, nor any prerequisite (e.g. gcode must already be sliced). Usage must be inferred from the sibling list, which is exactly the inference the description should spare 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 disclosure burden. It usefully reveals that fixed copies are left untouched and that positions are returned, but says nothing about whether existing unfixed objects are moved, whether the operation is undoable, or what happens on a crowded plate.

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 scope constraint first and the return value appended. No filler, no repetition of the tool name.

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

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

With no parameters, no annotations, and no output schema, the description covers the essentials: what is affected, what is skipped, and that positions are returned. It could still say more about side effects on previously placed objects, but it is adequate for a zero-argument convenience 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 zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.

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

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

States a specific verb (automatically place) and resource (every copy on the plate), with the scoping qualifier 'that the user has not fixed'. It is distinguishable from siblings like place_instance and transform_object, though it never names them. Clear but without explicit sibling differentiation.

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

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

No when-to-use guidance and no mention of alternatives such as place_instance (manual placement) or transform_object (repositioning). The only hint is the implicit condition that fixed copies are excluded, which the agent must infer from 'has not fixed'.

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?

destructiveHint=true already tells the agent this is a destructive operation, so the description is not carrying the full burden. It does add genuinely useful context beyond the annotation: an explicit user-confirmation requirement. But it omits key behavior for a destructive action — whether the job is recoverable, what happens to uploaded gcode, and how confirmation is actually obtained.

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, zero filler, with the destructive action front-loaded ahead of the precondition. Nothing needs to be cut and the important constraint is not 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 destructive tool with no output schema, 0% parameter coverage, and an undocumented confirmation_code field, the description is too thin. It leaves unresolved whether confirmation is a UI dialog or the code parameter, and gives no post-cancellation state information an agent would need before invoking it.

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 mentioned in the description. The required 'host' and the optional 'confirmation_code' are left entirely unexplained, and the description does not clarify how the 'explicit confirmation' it mentions relates to the confirmation_code parameter — a significant gap it should have filled.

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 (Cancel) and resource (the current print), making the operation immediately identifiable. It is distinguishable from siblings like pause_print/resume_print by the word 'cancel', but it never explicitly contrasts them (e.g., that cancel terminates rather than suspends the job), so it falls short of full sibling differentiation.

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

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

It gives one precondition — the user's explicit confirmation is required — which is real usage guidance. However, it does not say when to prefer cancel over pause_print/resume_print, nor what state the print must be in for cancellation to be valid, leaving usage largely implied.

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 a destructive bulk deletion. It never states that removal is irreversible, that there is no undo or confirmation, or whether all plates or only the active bed are affected.

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, appropriate for a zero-argument action. It is terse to the point of omitting operationally important detail, but nothing in it is wasted.

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

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

For a destructive, irreversible, no-argument bulk operation with no annotations and no output schema, the description is too thin. An agent cannot tell what exactly gets cleared, what state results, or how it differs from the single-object sibling.

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, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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?

Specific verb 'Remove' plus explicit scope 'every object from the bed' makes the operation immediately identifiable. It does not explicitly contrast with the sibling remove_object, so the agent must infer that this is the bulk variant.

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 and no exclusion or alternative named, even though the sibling remove_object handles the single-object case. The agent gets no signal about which of the two removal tools to pick.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the export captures objects, positions and configuration, but says nothing about whether an existing file at output_path is overwritten, what permissions or directory requirements apply, or what the tool returns on success/failure.

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 that front-loads the verb and resource with the clarifying parenthetical immediately after. No wasted words, though it is arguably too terse given what it omits.

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 export tool with no annotations and no output schema, the description adequately conveys the operation's purpose and content scope, but leaves path semantics and overwrite behavior unaddressed, which are the main things an agent would need to invoke it correctly.

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

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

Schema coverage is 0% for the single parameter, so the description must compensate and does not. It never explains output_path expectations such as format, required extension, or whether a directory must pre-exist.

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 ('Export') and resource ('the bed'), and clarifies the scope of what is exported (objects, positions and configuration) plus the output format (3MF project). This distinguishes it from siblings like upload_gcode or save_profile_as, though it never names those 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?

There is no guidance on when to use this tool versus alternatives such as slice, upload_gcode, or save_profile_as. No prerequisites, no indication of when a 3MF export is preferable to other export/save paths.

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 almost nothing behavioral: it does not say the operation is read-only, that it requires an already-sliced G-code file, how long an analysis may take, or what form the 'evidence' takes (line numbers? layer indices? severity?). 'With evidence' is a hint at output content but not a disclosure of 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?

One tight sentence that front-loads the outcome and parenthetically lists the concrete risk types, with no filler. It is slightly under-specified rather than verbose, and the trailing ellipsis leaves the enumeration open-ended.

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

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

No output schema and no annotations mean the description must stand alone, and it covers what the tool finds but not the prerequisite (a sliced G-code artifact) or the shape of the returned evidence. Adequate as a one-line summary, but not sufficient for an agent to invoke it confidently without inspecting the schema.

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

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

Schema description coverage is 0% and the description never mentions gcode_path at all, so the single required parameter is undocumented in both places. The agent gets no help on whether this is a filesystem path, a prior export artifact, or a path returned by another tool.

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

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

The description names a concrete analysis outcome (possible print problems) and enumerates the risk categories it detects — warping, overhangs, long bridges, flow/machine limits — which clearly separates it from slicing or metrics siblings. The verb is only implicit (carried by the tool name) and it never states the operation runs against the G-code file, but the resource and scope are 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 when-to-use guidance and no routing to alternatives, despite obvious candidates in the sibling list such as analyze_toolpaths and get_gcode_metrics. An agent cannot tell from this text whether to call this before slicing, after slicing, or instead of a toolpath analysis.

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 read that returns computed values, but says nothing about whether the file must already exist, whether the path is absolute or relative, whether parsing failures raise errors, or how large outputs are handled.

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

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

One sentence with zero filler, front-loading the returned metrics. It is a noun phrase rather than a full clause, which slightly weakens the framing but wastes no 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?

With no output schema, the description usefully enumerates the return fields (including filament units), which is the right thing to do. It still omits the input parameter's name/semantics and any error or file-availability behavior, leaving moderate gaps for a simple read tool.

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

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

Schema coverage is 0% and the single parameter gcode_path is never mentioned by name, but the phrase 'of a PrusaSlicer G-code' does convey that the argument is a G-code file and constrains it to PrusaSlicer output. That adds real meaning over a bare string type, though it stops short of format or path expectations.

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 set (print time, filament in three units, cost, layers, profiles) drawn from a PrusaSlicer G-code, which clearly separates it from siblings like analyze_toolpaths or get_plate. It lacks an explicit verb such as 'reads' or 'returns', but 'metrics of a G-code' is unambiguous enough for selection.

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 statement of when to call this versus alternatives such as analyze_toolpaths (path-level detail) or slice (producing G-code). The only implicit guidance is that the input must already be a PrusaSlicer G-code, with no exclusions or prerequisites given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it has side effects, or what permissions are required—only what data is returned. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, front-loaded sentence fragment with no wasted words. It is appropriately sized for a simple getter, though the fragment form is slightly less direct than a full sentence.

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

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

Given the tool has no output schema, the description should be sufficient to understand the return value. It lists the main categories (profiles, overrides, objects/instances) but does not describe the response structure or format, leaving some ambiguity about what an agent will receive.

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

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

The tool has no parameters, so there is no parameter semantics to document. With zero parameters, the baseline score of 4 applies automatically.

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 content returned ('Current bed: selected profiles, setting overrides and objects with their instances'), which is specific but lacks an explicit verb like 'Retrieve' and does not differentiate from siblings such as get_slicer_info. An agent can infer it is a getter, but the purpose is not stated as a clear action.

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

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

No guidance is given for when to use this tool versus alternatives, and no prerequisites or exclusions are mentioned. The description is purely declarative with no usage context.

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

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

With no annotations, the description carries the full burden. It hints at the returned data (state, progress, current file, temperatures) but never states that this is a read-only operation, whether it contacts the printer live, what happens if the host is offline, or whether any auth is required. Significant behavioral gaps for the sole tool that probes a printer.

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 compact sentence that front-loads the returned content. No filler, though it is arguably under-specified rather than deliberately minimal.

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?

Reasonable for a simple one-parameter read tool with no output schema, and it enumerates most return fields. However, it leaves the 'host' identifier format and the failure/connectivity behavior unspecified, which an agent needs in order to invoke it correctly.

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

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

The single parameter 'host' has 0% schema description coverage and the description does nothing to clarify it beyond the phrase 'networked printer'. It does not say whether 'host' is an IP address, hostname, or a printer ID from list_print_hosts, which is exactly the ambiguity an agent needs resolved.

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

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

The description gives a specific verb ('State' – i.e., report) and resource (networked printer status) plus the fields returned (progress, current file, temperatures). It is clearly distinct from mutation siblings like start_print or cancel_print, though it does not explicitly name list_printers/list_print_hosts as 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?

There is no statement of when to use this vs. list_printers (which likely enumerates hosts) or list_print_hosts. Usage is only implied by the word 'status'. No prerequisites, no exclusions, no alternatives named.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the resolution order (session override first, then last slice effective value), but does not state whether the operation is read-only, what happens if the key is missing, or any permissions or side effects.

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

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

The description is a single compact sentence that front-loads the return value and its resolution rule. It avoids waste, though the sentence is somewhat fragmentary and could be slightly more self-contained.

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-parameter getter with no output schema and no annotations, the description covers the core resolution behavior but omits key semantics, error behavior, and explicit read-only nature. It is minimally adequate but leaves important 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 single key parameter has no description in the schema. The tool description does not explain the key's expected format, scope, or valid values, so it adds little beyond the parameter 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?

The description clearly states what the tool returns: the value of a setting, with fallback from session override to the last slice's effective value. It does not explicitly name sibling tools like set_setting or reset_setting, so it lacks full sibling differentiation, but the resource and behavior are clear.

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 set_setting, reset_setting, or other configuration-related siblings. The description explains what the returned value means, but not when an agent should call get_setting or what prerequisites exist.

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 disclosure burden. It does reveal the shape of the returned environment data (including whether printer control is enabled), which is useful context, but it never states that the operation is a harmless read with no side effects, nor anything about cost or failure modes. For a zero-parameter read this is a modest gap rather than a serious one.

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

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

A single front-loaded sentence with no filler; the most important scope information (version/paths/engine/control status) comes first and nothing is repeated. It is a fragment rather than a full sentence, but it wastes no 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?

With no output schema, the description's field enumeration is the only signal of return content, and it covers the major items an agent would need. Terms like "active engine" and "printer control" are left slightly ambiguous, but for a no-argument info tool this is close to 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?

The schema defines zero parameters, which per the scoring baseline yields a 4; there are no arguments whose semantics the description would need to clarify. No parameter meaning is added or needed.

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 enumerates exactly what the tool returns (version, paths, data directory, active engine, printer-control flag) for the named get_slicer_info resource, so the agent knows this is an environment/info read. It does not, however, contrast itself with nearby getters like get_setting or get_printer_status, so sibling differentiation is left implicit.

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 statement of when to call this tool, when not to, or which sibling to use instead. The only cue is that the returned content is environmental/diagnostic, which the agent must infer from the field list rather than from any explicit guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints at the effect ('as user profiles'), but says nothing about whether existing profiles are replaced, what overwrite defaults to, whether the operation is reversible, or what happens on a parse failure.

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 the verb and resource front-loaded and no filler. It is efficient, though the brevity is partly under-specification rather than pure conciseness.

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

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

For a file-importing mutation tool with no annotations, no output schema, and 100% of parameters undocumented in the schema, the description leaves too much unexplained — notably overwrite behavior and failure modes on a malformed bundle.

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 partially helps by describing the file content expected at 'path' (.ini with [print:…] sections), but says nothing about the 'overwrite' flag, which is the parameter with the most consequential semantics.

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

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

States a specific verb (Import) and resource (PrusaSlicer config bundle), and even names the expected file format with '[print:…]' sections, which distinguishes it from siblings like save_profile_as or use_config_file. It stops short of explicitly contrasting itself with those siblings, so it earns a 4 rather than a 5.

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

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

There is no statement of when to use this tool versus alternatives such as use_config_file, select_profiles, or save_profile_as, all of which live in the same profile-space. No prerequisites or preconditions are given either.

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 partially discloses return structure (each profile includes compatible filament profiles). The verb 'print/list' implies a read operation, but there is no confirmation of read-only safety, auth requirements, or pagination behavior.

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

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

A single well-formed sentence with no filler, and the resource is front-loaded. Slightly terse given the missing details, but efficient.

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

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

For a simple one-parameter list tool with no output schema, the description gives a usable picture of the result shape. However, the undocumented parameter format and total absence of usage context leave gaps an agent would need to resolve.

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 the single 'printer' parameter, so the description must compensate. It only restates that profiles are 'compatible with a printer' and never explains whether the value is a name, ID, index, or model string.

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/print) and resource (profiles compatible with a printer), plus clarifies that each result bundles its compatible filament profiles. It is distinguishable from list_printers and select_profiles, but does not explicitly name or contrast 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?

There is no guidance on when to use this tool versus alternatives like select_profiles or get_setting. Usage is only implied by the description; no prerequisites or exclusions are given.

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 useful scoping detail that both system and user profiles are included, but says nothing about whether this is a pure read, whether it can fail (e.g. no PrusaSlicer config present), or what form the results take.

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 scoping qualifier front-loaded. It is under-specified rather than bloated, so conciseness itself is good.

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

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

For a zero-parameter listing tool with no output schema, the description gives the essential scope but omits any return-shape or usage context. Adequate as a minimum-viable definition, but not complete against a sibling set full of profile-related tools.

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

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

The tool takes zero parameters, so the schema has nothing to document and there is no parameter semantics burden on the description. Baseline 4 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 fragment names the resource ('Printer profiles') and its scope (system and user profiles in the user's PrusaSlicer), so an agent can infer it returns the installed printer list. However, it is a noun phrase with no verb and no explicit differentiation from the nearby list_compatible_profiles tool, so purpose 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_compatible_profiles or get_setting. The agent must infer the calling context 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 burden. It reads as a read-only listing operation and explicitly discloses that no secrets are returned, which is a meaningful disclosure for a credentials-adjacent tool. It stops short of describing what connection data is included or whether any host state is required.

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 compact sentence, front-loaded with the resource and followed by the protocol scope. Nothing redundant, though the 'No secrets.' fragment is terse to the point of being cryptic.

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

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

For a zero-parameter, annotation-free list tool with no output schema, the description adequately covers scope and one behavioral caveat. Adding a brief note on what fields come back, or how it relates to list_printers, would close the remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 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 the resource precisely ('networked printers configured in PrusaSlicer') and enumerates the supported host protocols (OctoPrint, Moonraker/Klipper, PrusaLink), which tells an agent exactly what set is returned. It does not, however, distinguish itself from the sibling list_printers, which an agent could easily confuse with this tool.

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

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

There is no statement of when to use this tool versus list_printers, get_printer_status, or get_setting. The agent must infer from the name and the protocol list alone.

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

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

Annotations only declare destructiveHint=true; the description adds genuinely new behavioral context by disclosing that explicit user confirmation is required before the pause executes. It still omits what happens to the print job, whether it can be resumed, and what failure looks like if confirmation is missing.

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

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

Two short sentences with zero filler, and the action is front-loaded ahead of the confirmation constraint. Nothing could be removed without losing meaning.

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 with no output schema, the description covers the core action and the consent requirement but leaves key gaps: the meaning of the required host parameter, the confirmation flow, and the resulting print state. It is minimally viable rather than 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%, so the description carries the full burden, yet it only vaguely gestures at the confirmation_code parameter via 'explicit confirmation' and says nothing about the required 'host' parameter or the code's format/provenance. An agent cannot tell what to pass for either field.

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 current print), which cleanly separates it from siblings like resume_print, cancel_print, and start_print. It does not explicitly name those alternatives, but the verb alone is unambiguous.

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

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

The description implies usage by stating a prerequisite (the user's explicit confirmation), which tells the agent this is not a fire-and-forget action. However, it gives no explicit when-to-use vs. resume_print/cancel_print guidance and no conditions under which pausing is appropriate or unavailable.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether this mutates plate state, what happens on out-of-bounds coordinates or invalid instance indices, whether placement is absolute or additive, or what coordinate origin the bed uses. Only the unit (mm) and the fact that x/y refer to the object's centre are disclosed.

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 zero waste, but it is under-specified rather than genuinely concise. The core information (unit and centre-anchor) is front-loaded correctly.

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 four-parameter, all-required mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It omits coordinate origin, error behavior on bad indices, and how the call relates to sibling object-manipulation tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: it clarifies that x/y are in millimetres and denote the centre rather than a corner, and it implies 'instance' selects one copy of a multi-instance object. It says nothing about object_id lookup semantics or valid ranges, 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?

States a verb ('Fix the centre') and a resource ('one copy of an object on the bed'), which is enough to infer a placement operation. However, 'Fix the centre' is loose phrasing, and nothing distinguishes this from siblings like transform_object or arrange_plate, which also move objects on the plate.

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 transform_object, arrange_plate, or add_model, and no prerequisites or preconditions are stated. The agent must infer the usage context entirely 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?

With no annotations, the description must carry full behavioral disclosure. It reveals that this is a GUI engine v2 live-preview operation, which is useful context, but it omits whether the GUI must be running, whether the action is reversible, what happens with an invalid layer index, or any side effects on the current view.

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. It immediately states the action and the operational 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 GUI-control tool with no annotations, no output schema, and no schema descriptions, the definition is too sparse. It lacks the layer indexing convention and runtime prerequisites an agent would need 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 0% for the single layer parameter, so the description must compensate. It only repeats that a 'given layer' is shown, adding no index base, valid range, or meaning beyond the schema's own parameter 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?

The description states a specific verb (Show) and resource (a given layer) in a precise context (live preview, GUI engine v2). It is clear what the tool does, but it does not distinguish itself from the sibling show_in_slicer or other preview tools.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no comparison to alternatives such as show_in_slicer. The description only implies usage through its purpose statement.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a destructive mutation ('Remove') but does not state whether the removal is permanent, what permissions are needed, or what happens if the object_id is invalid. It provides minimal context beyond the action itself.

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

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

The description is a single, front-loaded sentence with no wasted words. However, it is too sparse for a destructive tool with no annotations and an undocumented parameter. The conciseness is good, but the structure is under-specified for the tool's complexity.

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

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

Given no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It identifies the core action and target but omits critical details about the parameter, side effects, and alternatives. For a mutation tool with such gaps, more context is needed.

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

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

The input schema has one required parameter (object_id) with 0% description coverage, so the description must compensate. It does not mention object_id at all, nor explain how to identify the object to remove. This leaves the parameter completely 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 ('Remove') and resource ('object') with the scope 'from the bed'. However, it does not distinguish this tool from sibling alternatives like clear_plate, which also removes objects. Per the rubric, this is clear but lacks sibling differentiation, so a 4 is appropriate.

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 no guidance on when to use this tool versus alternatives such as clear_plate or other removal tools. There is no mention of preconditions, exclusions, or typical scenarios. The description simply states the action without advising the agent on selection.

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavior: a session-scoped override is removed rather than the underlying setting changed. However, it says nothing about idempotency, what happens if no override exists, whether other sessions are affected, or whether confirmation is returned 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?

A single tight sentence with the action front-loaded and the consequence trailing. No padding or redundancy; 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?

For a low-complexity one-parameter tool with no annotations or output schema, the description conveys the semantic effect adequately, but it omits the parameter's meaning entirely and gives no failure-mode context for a mutating call. It is minimally sufficient rather than complete.

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

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

Schema description coverage is 0% for the single 'key' parameter, so the description must compensate and it does not. It never states what form the key takes, which keys are valid, or how it maps to the override being removed, leaving the agent to guess.

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 session override') plus the resulting effect ('so the profile value applies again'), which is more than a restatement of the name. It differentiates itself conceptually from get_setting/set_setting by naming the session-override layer, though it never names 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 implied by the phrase 'so the profile value applies again' — an agent can infer this is for reverting a temporary override. There is no explicit when-to-use guidance, no mention of the alternative set_setting for changing an override instead of removing it, and no prerequisites.

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 annotation destructiveHint=true already signals a potentially impactful operation. The description adds valuable context beyond that by stating 'Needs the user's explicit confirmation,' which tells the agent a confirmation step is required before execution. It does not detail what happens to the print state, but this is a meaningful addition.

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 followed by the critical prerequisite. No wasted words.

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

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

For a destructive tool with two parameters and no schema descriptions, the description is too sparse. It omits any explanation of the required 'host' parameter, the 'confirmation_code' parameter, and does not mention alternatives or post-resume behavior. While the destructive annotation covers safety, the definition remains incomplete for correct invocation.

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% for two parameters. The description only vaguely implies the confirmation_code parameter via 'explicit confirmation' and says nothing about the required 'host' parameter, its format, or how to obtain a confirmation code. It fails 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 and resource: 'Resume a paused print.' This unambiguously distinguishes the tool from its siblings pause_print, start_print, and cancel_print without needing to name them.

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

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

The phrase 'Resume a paused print' implies the tool is used when a print is paused, and the confirmation requirement is a useful prerequisite. However, it does not explicitly say when to choose this over pause_print or cancel_print, nor does it describe handling of non-paused prints.

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 but omits key behavioral facts: the existence and default of the `overwrite` flag is never mentioned, nor is what happens when a profile of that name already exists. 'One per affected kind' is left unexplained, so the agent cannot predict the side effects of a save.

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 compact sentence with the action front-loaded and no filler. It is efficient, though the trailing clause 'inheriting the selected ones' is dense enough to blur meaning rather than sharpen it.

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 3-parameter mutation tool with 0% schema coverage, no annotations, and no output schema, the description is too thin. It neither documents the parameters nor explains the resulting profile set or the overwrite path, leaving the agent under-informed.

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, but it only alludes to `name` and vaguely to `keys` via 'inheriting the selected ones'. The `overwrite` parameter is never addressed, leaving a third of the inputs semantically undefined.

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 (save) and resource (user profiles), and clarifies the source is the session overrides rather than arbitrary data. It is reasonably distinguishable from siblings like import_profile_bundle or select_profiles, though it never names an alternative to disambiguate.

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: the agent can infer it is for persisting current session overrides into named profiles. There is no explicit when-to-use, no prerequisites, and no comparison against profile-related siblings such as import_profile_bundle or list_compatible_profiles.

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

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

With no annotations, the description carries the full behavioral burden. It adds one useful constraint ('by exact name', implying no fuzzy matching), but says nothing about whether the selection replaces or appends to existing state, whether it is validated against the printer, or what happens on an invalid name.

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 action and resources, and the parenthetical constraint lands at the end where it is easy to scan. 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 3-required-param tool with zero schema descriptions, no annotations, and no output schema, the description covers purpose and name format but leaves error handling and the source of valid names unspecified. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so the description must compensate: it names all three parameters (printer, print_profile, filaments) and specifies the exact-name format, which is meaningful. It still omits whether multiple filaments must be ordered, whether 'printer' is a profile name or a printer model, and cardinality rules.

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 ('Select') and names all three resources (printer, print, filament profiles), plus the downstream purpose ('to slice with'). It is distinguishable from siblings like save_profile_as or import_profile_bundle, though it doesn't explicitly contrast with list_compatible_profiles, which is the nearest discovery-oriented sibling.

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?

'to slice with' implies this is a pre-slicing configuration step, so the usage context is inferable. However, it never says where valid profile names come from (e.g., list_compatible_profiles) or what happens if a name is wrong, so no alternatives or exclusions are given.

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 one genuinely useful behavioral trait — the override is session-scoped and therefore not persisted — but says nothing about invalid key handling, whether the key must already exist, or when the change takes effect relative to slicing.

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, scope, and two illustrative examples packed in without waste. Nothing could be removed 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 two-parameter mutation tool with no annotations and no output schema, the description covers the essentials of what it does and how values look, but omits how to discover valid keys and what happens on failure. Adequate but with clear gaps for a state-changing 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 schema gives no help on the two required parameters. The inline examples ('fill_density=20%', 'layer_height=0.15') do reveal the key naming convention and that values are passed as strings, which partially compensates, but there is no guidance on valid keys or accepted value formats.

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 ('Override a PrusaSlicer setting') plus a scope qualifier ('for this session'), which clearly separates it from get_setting and reset_setting. It never names a sibling explicitly, so it falls short of the 5 bar for sibling differentiation, but the 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?

The phrase 'for this session' implies the usage condition — temporary in-memory overrides rather than persistent profile edits (save_profile_as) — but this is left for the agent to infer. There is no explicit statement of when to prefer this over editing a config file or profile, and no exclusions.

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

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

Annotations are absent, so the description carries the full disclosure burden, and it delivers nothing: no indication that this mutates object state, whether it is reversible, whether it requires a sliced/selected object, or what '(GUI engine, v2)' implies for behavior. This is an inadequately disclosed 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?

It is short, but the brevity comes from under-specification rather than economy. The parenthetical '(GUI engine, v2)' consumes part of a single fragment without adding actionable meaning.

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?

A state-changing tool with no annotations, no output schema, undocumented parameters, and multiple related siblings. An agent cannot safely call this correctly from the given information.

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 two parameters. The description never mentions object_id or quality, nor the range/meaning of the quality value (default 0.5) or whether object_id must reference an object on the plate, so nothing compensates for the schema 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?

The description is a noun-phrase restatement of the tool name (set_variable_layer_height -> 'Adaptive variable layer height for an object') with no verb indicating what is actually done. It names the resource but does not distinguish this tool from the sibling add_height_range_modifier, which touches the same feature area.

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, prerequisites, or alternative-tool guidance is given. With siblings like add_height_range_modifier and slice in the same list, the agent gets no help deciding when this tool is the right one.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a UI side effect (opens a window in the user's environment) and that the target window depends on file type, but it says nothing about whether PrusaSlicer must already be running, whether the call blocks, or what happens on a missing/unsupported path.

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 front-loaded sentence that names the action, the two input categories, and the two destinations. 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?

For a simple one-parameter tool with no output schema, the core behavior is covered, but the description omits prerequisites (running instance), failure behavior for invalid paths, and any hint about the result of the call. Adequate but with clear gaps.

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

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

The single 'path' parameter has no schema description (0% coverage), so the description is the only source of meaning. It does imply the accepted file kinds (model/3MF or G-code), which is useful, but gives no format, relative/absolute path, or extension guidance.

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

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

States a specific verb ('Open') and the resources it handles (model/3MF, G-code), plus the distinct destinations (PrusaSlicer window vs G-code viewer). This clearly separates it from siblings like add_model, which load geometry onto a plate rather than open a file in a GUI, though the description never names a sibling to reinforce the distinction.

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

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

The description gives real selection context by branching on input type: model/3MF goes to the slicer window, G-code goes to the viewer. It does not state exclusions or point to alternative tools (e.g. when to prefer add_model over opening a file), so it falls short of a full when/when-not 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?

With no annotations, the description carries the full burden; it does add real value by disclosing the outputs (G-code path, metrics, warnings, placements, config check). However it omits key behaviors for a potentially long-running, file-writing operation: whether it writes to disk, whether it overwrites existing files, expected duration, and what failure 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?

Two compact sentences with the action front-loaded and the return payload enumerated second. No filler, though the return list is packed rather than prioritized.

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 does cover return values, which is its main job here. But it leaves gaps around the lone parameter's behavior, write semantics, and prerequisites, so an agent could invoke it without knowing whether it will clobber files or fail on a missing plate setup.

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 output_path has null default and 0% schema coverage, and the description never mentions it. It is unclear whether omitting it means no file is written, a default path is used, or an existing file is overwritten — a meaningful gap given the tool writes G-code.

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 ('Slice the bed') and enumerates what the operation produces (G-code path, metrics, warnings, placements, config check). It clearly reads as the slicing action, distinct from read-only siblings like get_gcode_metrics or analyze_toolpaths, though it never names a sibling to route against.

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 slice versus when to inspect existing results, and no prerequisites are stated (e.g. models loaded on plate, profiles selected). An agent must infer all preconditions 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?

Annotations already declare destructiveHint=true, so the safety profile is partly covered. The description adds the confirmation requirement, which is real behavioral context, but it does not explain the confirmation flow or what happens to the job once started. Adds some value beyond annotations but leaves the mechanism unexplained.

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 core action is front-loaded before the confirmation constraint. Nothing 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 destructive mutation with no output schema, the description mentions confirmation but not how confirmation_code is supplied or what the caller should expect. Safety context is present but the operational flow is incomplete.

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% on 3 parameters, so the description must carry the burden and largely does not. 'Already uploaded file' loosely maps to the remote parameter, but host and especially confirmation_code (which ties to the stated confirmation requirement) are left 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+resource (start printing) and scopes it with 'an already uploaded file', which implicitly differentiates it from upload_gcode and from pause/resume/cancel siblings. It is clear, though it doesn't explicitly name a sibling it replaces.

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 prerequisite 'already uploaded file' and 'Needs the user's explicit confirmation' give implied usage context, but there is no explicit when-to-use vs. alternatives guidance (e.g., relative to upload_gcode or resume_print). 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 behavioral burden. It does disclose one useful trait — that rotation is 'absolute' rather than relative — but says nothing about what happens to unspecified axes, whether copies duplicates the object destructively, whether the object must already exist, or whether the operation is reversible.

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 zero filler, front-loaded with the verb and the three transform categories. Every clause maps to a parameter group.

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 six parameters, 0% schema coverage, no annotations and no output schema, the description is too thin. It omits the required object_id entirely, does not explain per-axis null defaults, and gives no sense of the mutation's side effects on the plate.

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 adds real value by supplying units (degrees for rotate_x/y/z, percent for scale_percent) that the schema lacks, and it names 'number of copies'. However, it never mentions object_id, the one required parameter, and doesn't explain that null defaults leave a property unchanged.

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

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

States a specific verb ('Set') and the resources it acts on (absolute rotation in degrees, scale in percent, number of copies) of 'an object'. It is clear what the tool does, though it never distinguishes itself from siblings like place_instance or arrange_plate that also reposition objects.

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

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

There is no guidance on when to use this tool versus alternatives such as place_instance for positioning or add_model for new objects. No prerequisites or exclusions are stated; the agent must infer usage from the name alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the upload is non-destructive (does not start the print) and that a remote path is returned, but says nothing about overwrite behavior, permissions, size limits, or failure modes on unreachable hosts.

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

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

Two short sentences with zero waste; the action and its key constraint are front-loaded, and the return value is mentioned last where it belongs.

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

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

The return value is covered inline since no output schema exists, and the non-starting behavior is stated. However, for a two-parameter tool with no annotations and 0% schema coverage, missing parameter formats and error/overwrite semantics 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 description coverage is 0% — neither 'host' nor 'gcode_path' has any description, format, or example. The description only echoes the concepts ('G-code', 'networked printer') and adds no syntax such as host format, path being local vs remote, or accepted file types.

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), resource (G-code), and target (networked printer), plus the crucial scope boundary 'without starting it'. That boundary implicitly separates it from start_print in the sibling list, so an agent can pick it 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 phrase 'without starting it' implies the use case (stage a file for later printing) but never states when to choose this over start_print or a direct print flow, nor any preconditions such as the printer being reachable or idle. Usage is inferable rather than explicit.

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

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

With no annotations, the description carries the full burden. It does disclose one useful behavioral trait, that bundles are rejected, but says nothing about whether this replaces an existing profile selection, whether it mutates persistent state, or whether the file must exist locally. Partial disclosure only.

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

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

A single front-loaded sentence with no wasted words, delivering the key distinction immediately. It reads as a fragment without an explicit subject, but nothing is padded.

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

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

For a config-selection tool with no annotations and no output schema, the description covers the main differentiator but omits how it interacts with select_profiles state and whether slicing follows automatically. Adequate but with clear gaps.

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

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

Schema coverage is 0% for the single 'path' parameter, so the description must compensate. It does imply the path targets a flat .ini file rather than a bundle, which adds real meaning, but gives no format, extension, or absolute-vs-relative guidance.

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: use a flat PrusaSlicer .ini config for slicing, explicitly contrasting it with named profiles and bundles. This differentiates it from siblings select_profiles and import_profile_bundle. Minor ambiguity remains about whether this tool itself performs the slice or only sets the configuration source, given the separate 'slice' sibling.

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 selecting condition clearly: use this instead of named profiles, and notes bundles are rejected, which implicitly routes agents away from import_profile_bundle. No explicit when-not guidance or note that a subsequent slice call is still required.

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