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 does not state that the tool is read-only/non-mutating, whether it touches the filesystem or launches anything, or what happens when an installation is missing — all relevant for a local environment check.

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 key scope (what is checked) is front-loaded. Nothing is wasted or redundant.

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

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

With an output schema present, return-value detail is not required, and a zero-parameter tool needs little argument prose. However, absent annotations the description should still convey that this is a safe, non-mutating check and how failures surface; that gap keeps it at minimum-viable.

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 are no argument semantics to explain; the schema is empty and fully self-describing. 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 description gives a concrete verb ('Check') and names the three specific resources it inspects (local FreeCAD, OrcaSlicer, and profile locations), so an agent knows it is an environment/path validation tool. It does not, however, differentiate itself from sibling discovery tools such as find_profiles or list_user_profiles, which also touch profile locations.

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

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

There is no explicit guidance on when to call this versus alternatives, nor any stated prerequisites or follow-up actions. A reader can infer it is a preflight/diagnostic step, but the description never says so or routes to siblings.

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

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

With no annotations, the description carries the full load. It does disclose the single most important behavioral trait for a mutation tool: the original preset is left unchanged, so the operation is effectively non-destructive. However, it says nothing about permissions/auth requirements, where the derived copy is written or named, or what happens on a path conflict.

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 with the create semantics front-loaded and the non-destructive guarantee immediately after. Nothing is wasted, though the brevity borders on under-specification rather than deliberate concision.

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

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

An output schema exists, so return values need not be described, and the key safety trait is covered. But for a two-parameter mutation tool with a nested 'changes' object and zero annotation support, the absence of any detail on parameter format or the destination of the derived profile leaves meaningful gaps.

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

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

Schema description coverage is 0% for both parameters. 'With new settings' loosely maps to the 'changes' object, but the description never says it is a key/value override bag, and 'path' is entirely unexplained (source preset vs. destination for the copy). A nested-object parameter at 0% coverage needs much more compensation than this.

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 ('Create an isolated copy') and the resource it operates on ('OrcaSlicer preset'), so the agent knows this produces a derived, non-mutating profile artifact. It does not distinguish itself from siblings like read_profile or list_user_profiles, which the agent must infer from names alone.

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 when-to-use guidance and no named alternative. The agent must infer that this is the tool to reach for when it wants a modified profile without touching the original, rather than any of the read/list profile siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the CAD document is not altered, which is important safety context, but it omits file-write behavior, overwrite semantics, required document state, and any permission or selection prerequisites.

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 definition is a single front-loaded sentence with no filler or repetition. Every phrase contributes to purpose or scope.

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

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

Although an output schema exists, so return values need not be explained, the description is thin for a tool with no annotations and 0% schema coverage. It leaves both required parameters and the file-writing behavior largely undocumented.

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 explain the parameters, but it does not. It hints that object_name refers to a selected FreeCAD object, but the required path parameter is never described in terms of format, destination, or overwrite behavior.

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: export a FreeCAD object to STL. It also scopes the operation to one selected object and clarifies non-mutation of the CAD document. An agent can easily distinguish this from inspection, slicing, or setup 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?

It implies the tool is used to create an STL file, but gives no explicit when-to-use guidance, prerequisites, or alternatives. There is no mention of when to choose export_freecad_stl versus inspect_freecad_document, preview_slice, or run_slice.

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, and it discloses almost nothing: no matching semantics (substring vs exact, case sensitivity), no statement that it is read-only, no paging behavior. The output schema exists but covers only returns, not call behavior.

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

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

A single sentence with zero filler, front-loaded with the verb and resource and immediately bounded by scope. Appropriate size for a three-parameter lookup tool.

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

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

An output schema means return values need not be explained, and the description covers the core kind/query concepts. But with no annotations and 0% schema description coverage, matching behavior and the limit parameter are left undocumented, so an agent lacks enough to invoke it precisely.

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 does explain two parameters implicitly: 'machine, process, or filament' enumerates the kind values and 'by name' describes query. It says nothing about the limit parameter, leaving a third of the schema 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 (find) and resource (profiles) and scopes it to bundled or user OrcaSlicer machine/process/filament presets matched by name. This is more precise than a generic 'find', though it never explicitly contrasts itself with the sibling list_user_profiles or read_profile.

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 'by name' implies a name-based search, hinting that this is the lookup path versus listing siblings like list_user_profiles. However, no when-to-use condition, prerequisite, or alternative tool is named, so the agent must infer the routing.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'Read' does imply a non-mutating operation and the scope of returned state is named, but there is nothing about auth, rate limits, or whether this polls a live connection.

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 two pieces of returned state are front-loaded. Nothing in it is redundant against the name or schema.

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

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

For a zero-argument status read with a dedicated output schema, the description is nearly sufficient — the return shape is documented elsewhere and no parameters need explaining. The only shortfall is the missing routing against 'check_setup' and any hint about freshness or connection failures.

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 are no parameter semantics to explain; the baseline for a parameterless tool is 4. The schema's empty properties object is consistent with the description.

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

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

The description uses a specific verb ('Read') with two concrete resources ('Moonraker connection' and 'current print state'), so an agent knows exactly what data comes back. It does not, however, differentiate itself from the sibling 'check_setup', which plausibly overlaps with connection-state checking.

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 when-to-use or when-not-to-use guidance, and no alternative is named. The overlap risk with 'check_setup' is left for the agent to resolve on its own.

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. 'List' implies read-only inspection and it names returned data, but it does not state that the document is not modified, error behavior, or file access requirements. This is minimal but adequate for an inspect operation.

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

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

A single front-loaded sentence with no wasted words. It delivers the tool's purpose and scope immediately.

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

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

An output schema exists, so return values need not be explained in the description. The description covers what is listed and the file type to inspect; only path parameter semantics and explicit read-only confirmation are missing for this low-complexity 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% for the single required path parameter, and the schema only labels it 'Path' with no description. The description adds that the path refers to a FreeCAD .FCStd document but does not specify path format, extension expectations, or whether it must be absolute.

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

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

States a specific verb ('List') and resources ('solid objects, dimensions and validity') scoped to a FreeCAD .FCStd document. It is easy to distinguish from export_freecad_stl by the inspection verb, but it never references or differentiates from any sibling explicitly.

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

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

No explicit when/when-not guidance or alternatives are given. The intended use case (inspect a FreeCAD document) is implied by the verb and resource, so there is minimal but inferable 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 disclosure burden. "List" implies a read-only, side-effect-free operation, but it does not state that explicitly, nor does it mention auth requirements, rate limits, or whether the returned set is static or depends on the connected printer/profile.

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 verb and the resource arrive immediately. Nothing is redundant with the schema or could be cut.

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?

An output schema exists, so return structure need not be explained, and with no parameters there is little left to document. It could go slightly further by tying these settings to the slicing/profile workflow used by the sibling tools, but nothing critical is missing 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies when there are no parameters to document.

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

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

States a specific verb ("List") and a specific resource ("the validated print settings accepted by this server"), which distinguishes it from the other list_* sibling (list_user_profiles). It never names or contrasts with any sibling tool, so differentiation still requires the agent's own inference.

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 phrase "accepted by this server" hints this is the discovery step before submitting settings, but there is no explicit when-to-use rule, no prerequisite (e.g. must call check_setup first), and no named alternative. Adequate but with clear gaps.

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 not state that this is a read-only operation, whether results are paginated, or how 'local' presets differ from any remote/cloud set. Only the 'local' qualifier adds real behavioral information.

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 verb and resource lead. Slightly opaque jargon ('JSON presets') is the only cost, but it stays tight.

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?

An output schema exists, so return values need no explanation, and a zero-parameter list tool has a small surface. What is missing is routing guidance against the three profile-related siblings, which leaves the agent with a real ambiguity when deciding which profile tool to invoke.

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 per the rubric the baseline is 4. There are no argument semantics to explain and the description does not need to compensate for anything.

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

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

States a specific verb ('List') and a well-defined resource: local machine, process, and filament JSON presets. It even scopes the resource to those used for slicing. It stops short of distinguishing itself from the sibling 'find_profiles', which reads similarly, so it does not fully earn a 5.

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

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

The phrase 'available for slicing' hints at context, but there is no explicit when-to-use guidance and no mention of the closely named siblings (find_profiles, read_profile, derive_profile). An agent cannot tell from the description alone whether to call this or find_profiles first.

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 implies a mutation (writing exported geometry and a slice result), yet says nothing about where output lands, whether existing files are overwritten, what OrcaSlicer/FreeCAD executables must be installed, or that the 600s default timeout signals a long-running operation. Sibling check_setup exists precisely because environment prerequisites matter here, and the description never mentions them.

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 or repetition, and the core action leads. Its brevity is a virtue for scanning, though it tips into under-specification rather than tightness.

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?

An output schema exists, so return values need not be explained. For a multi-stage CAD-export-plus-slicing tool with 7 parameters, no annotations, and zero parameter documentation, the description omits the pipeline prerequisites, profile-parameter format, timeout semantics, and output location — a large gap given the tool's complexity.

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

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

Schema description coverage is 0% across 7 parameters, five of which are required, so the description must compensate and does not. 'Explicit OrcaSlicer presets' loosely gestures at machine/process/filament_profile, but cad_path, object_name, settings, and timeout_seconds get no clarification whatsoever — notably whether profile params take names, keys, or file paths.

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 sentence names two specific verbs (export, slice) and both resources (a FreeCAD solid, OrcaSlicer presets), so the compound end-to-end nature of the tool is clear. It does not, however, distinguish itself from the sibling pair export_freecad_stl + run_slice, which an agent could compose to achieve the same result.

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 statement, no prerequisite list, and no named alternative. The phrase 'explicit OrcaSlicer presets' faintly implies this is for callers who already have profile names rather than using find_profiles/derive_profile, but the agent must infer that entirely.

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

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

With no annotations, the description carries the full burden, and it does disclose the single most important behavioral trait: it validates and reports inputs, settings, and hashes without performing a slice, i.e. no side effects on the model. It is silent on auth needs, failure modes, or rate limits, but the critical safety profile is stated.

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 differentiating clause last and zero redundant text. 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?

An output schema exists, so return values need not be described, and the dry-run behavior is clear. But with five undocumented parameters, no annotations, and no explicit routing against run_slice, the definition leaves gaps the agent must guess around.

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 all five parameters, so the description would need to compensate, and it does not. 'Inputs, settings, and hashes' refers to the preview output, not to arguments like model, settings, machine_profile, process_profile, or filament_profile, none of which are explained.

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

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

The description gives a specific verb (validate) and resource (slice request) plus the scope-limiting clause 'without slicing', which tells the agent this is a dry-run counterpart to the write path. It does not name run_slice directly, so differentiation is implied rather than explicit.

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

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

'Without slicing' implies this is the safe pre-flight check before run_slice, which is usable guidance. However, it never states an explicit when-to-use/when-not-to-use rule or names the alternative, leaving the agent to infer the workflow ordering.

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 add real value by declaring which file formats are accepted and by hedging that metadata is only 'available' (fields may be absent), but it says nothing about permissions, error behavior on unsliced files, or cost.

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 naming the action, the returned data, and the accepted inputs, with zero 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?

With only one parameter and an output schema already present to describe return values, the description needs little more. It covers the input formats and the data returned; only the path semantics and usage routing are thin.

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 required 'path' parameter has no schema description. The description partially compensates by constraining the path to G-code or sliced 3MF artifacts, but it gives no format, relative-vs-absolute, 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 (read) plus the resource and the exact payload (print time, filament, layer metadata), and names the accepted inputs (G-code or sliced 3MF). It is clearly distinguishable from slicing siblings like run_slice or preview_slice, though it never names those siblings explicitly.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as preview_slice or get_printer_status. The only implicit signal is that a G-code/3MF artifact must already exist, which the agent has to infer.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that credential fields are redacted in the returned settings, which is a real behavioral trait, but says nothing about permissions, path resolution, or error behavior for an invalid 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 tight sentence with no filler, and the redaction caveat is attached directly to the action it modifies. Nothing to trim.

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?

An output schema exists, so return values need not be explained, and the redaction note covers the most surprising behavior. However, with an undocumented required parameter and no usage context, the definition is only minimally sufficient 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?

The single required parameter 'path' has 0% schema description coverage, and the description does not explain what the path points to (preset file, profile directory, etc.) or its expected format. The schema does no work here, and the description only obliquely implies the path identifies a preset.

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

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

States a specific verb (Read) and resource (a preset's settings) and adds a scope qualifier about redaction. It implicitly separates itself from list_user_profiles and find_profiles by reading a single preset, but never names or contrasts those siblings explicitly.

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

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

No when-to-use statement and no routing guidance among the many profile-related siblings (find_profiles, list_user_profiles, derive_profile). The agent must infer that this is the tool for fetching one profile's contents by path.

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

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

With no annotations, the description carries the full burden and does disclose two useful traits: output goes to a unique folder (avoiding collisions) and the result is artifacts plus logs. It stays silent on runtime expectations, permission/auth needs, whether prior outputs are overwritten, and failure behavior for a tool that shells out to a slicer.

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 the output behavior appended; nothing is padded or redundant.

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

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

An output schema exists, so return values need no explanation, but for a 6-parameter, annotation-free execution tool the description leaves the argument space entirely undocumented and gives no guidance on when to prefer it over preview_slice.

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% across 6 parameters, so the schema explains nothing, and the description adds no meaning for model, settings, the three profile arguments, or timeout_seconds. The only faint signal is 'stock' implying defaults, which does not compensate for the complete gap.

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

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

States a specific verb ('Slice') plus the engine (stock OrcaSlicer) and its write behavior (unique output folder, returns artifacts and logs). It does not distinguish itself from the close siblings preview_slice and prepare_print_job, so an agent must still infer which slicing-stage 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 when-to-use guidance and no explicit alternative named, despite preview_slice and prepare_print_job sitting in the same family. The 'stock OrcaSlicer' phrasing only loosely implies this is the real/full slice rather than a preview.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose one real behavioral trait — a readiness/idle gate before starting — which is useful for an action tool. It omits what happens on failure (does it error, queue, or silently abort), whether the call blocks until the print starts, and whether the action is reversible, all of which matter for a physical printer operation.

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

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

A single tight sentence with the action front-loaded and the precondition attached as a subordinate clause. No filler, nothing to trim.

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?

An output schema exists, so return values need not be explained. But for a hardware-mutating action with no annotations and an undocumented required parameter, the description is thin: it says nothing about failure modes, blocking behavior, or printer-state errors that an agent must anticipate.

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 upload_id parameter, so the schema adds no meaning on its own. The description partially compensates by indicating the id refers to a previously uploaded G-code file, but it gives no format, provenance, or example of the id, leaving a real 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?

Specific verb+resource: 'Start an uploaded G-code file' names both the action and the target, and 'uploaded' implicitly scopes it to a file already on the device, distinguishing it from upload_print_file and prepare_print_job. It does not explicitly name or rule out any sibling, so it stops short of a 5.

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

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

The phrase 'after checking the printer is ready and idle' implies a precondition that routes the agent toward get_printer_status first, which is genuine usage context. However, it never explicitly says when to use this instead of prepare_print_job or upload_print_file, nor what to do when the check fails.

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 two key facts — the print is NOT started and an upload ID is returned — but omits auth requirements, storage location, and overwrite/duplicate handling, leaving meaningful gaps for an upload 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 tightly-worded sentence with the non-start constraint and return value front-loaded. 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?

An output schema exists, so the return value ('upload ID') need not be explained, though the description mentions it anyway. The remaining adequacy gap is the undocumented 'path' parameter plus no annotation coverage; the core purpose is otherwise clear.

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 0% schema description coverage, and the description never explains it (remote path? local file? filename only?). The description gives upload context but does not compensate for the undocumented parameter.

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

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

States a specific verb+resource ('Upload G-code to Moonraker') and immediately scopes it with 'without starting the printer', which cleanly separates it from the sibling start_uploaded_print. An agent can distinguish its role without opening any schema.

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

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

The clause 'without starting the printer' conveys the when-not condition and implicitly routes the agent to start_uploaded_print for the actual print step. It does not explicitly name that alternative or state prerequisites, so it stops short of a 5.

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