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

With no annotations, the description still discloses meaningful behavior: credentials come from ~/.onshape-mcp/.env, each call consumes the user's Onshape API quota, and the default arrange=true re-arranges the bed afterwards. It does not say whether arranging disturbs existing objects on the bed or how partial failures behave, which keeps it short of a 5.

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

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

Core action is front-loaded in one sentence, followed by a compact args list where each line adds detail rather than repeating the schema titles. Slight redundancy in restating parameter names, 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?

An output schema exists so return values need no explanation, and the five parameters are fully covered. Missing only edge-case guidance such as behavior when a requested part name or bed name does not exist, which matters for a networked import that mutates bed state.

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

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

Schema coverage is 0%, yet all five parameters are explained with meaning the schema lacks: the accepted URL shapes (document or document/w/<id>/e/<part studio id>), that parts defaults to all solid parts and matches case-insensitively, that bed takes a name or "new", and copies/arrange defaults.

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 (download), source (Onshape part studio), output format (millimeter STL), and destination (a bed). The Onshape-specific framing plus the note that each download consumes API allocation makes it unmistakably distinct from the generic add_model 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?

Usage is only implied: the name and URL argument make clear this is the path for Onshape-hosted parts, but the description never says when to prefer it over add_model or what to do if a part name does not match. No exclusions or prerequisites are stated beyond the API-key requirement.

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

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

No annotations exist, so the description carries the full burden and does a decent job: it discloses that a 3MF with multiple objects adds each one, that arrange can spill non-fitting objects onto new beds, and that bed="new" inherits bed-1's profiles without overrides. It does not cover error handling, overwrite behavior, or whether existing bed contents 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?

The purpose sentence is front-loaded and the Args block is efficient, with every parameter line earning its place. The parenthetical-heavy style is slightly dense but not wasteful.

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. Combined with thorough parameter documentation and disclosed side effects, the definition is nearly complete for a 5-param mutation tool; only failure modes and interaction with existing bed contents remain unaddressed.

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 does: all five parameters are explained with meaning and defaults, including the non-obvious sentinel value bed="new" (inherits bed-1 profiles, no overrides) and the arrange spillover side effect. This is meaningfully more than the bare schema provides.

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

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

States a specific verb and resource ('Load a model file') and enumerates accepted formats (STL, 3MF, OBJ, STEP), plus the multi-object 3MF behavior. It doesn't explicitly contrast with siblings like add_from_onshape or copy_objects, but the file-loading scope is clear enough to separate it from 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?

Usage is implied through parameter defaults (bed defaults to first bed, arrange defaults to true), but there is no explicit 'use this when...' guidance or statement of when to prefer add_from_onshape over local file loading. The agent must infer the selection context from surrounding tools.

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

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

With no annotations, the description carries the behavioral burden and does well: it explains packing, centering, per-bed or all-bed scope, rotation up to 90 degrees about Z, and overflow spreading to a new bed with the same settings. It omits some mutation details, such as whether existing placements are overwritten 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?

The description is front-loaded with the core action, followed by a compact Args section that earns its place by clarifying each parameter. There is no redundant or filler text.

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

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

The tool has four optional parameters, no annotations, and an output schema, so return values need not be described. The description covers the core behavior and all parameters adequately, though it could be more complete about selection scope and side effects on existing bed layouts.

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 define the four parameters, and it does: bed scope/default, spacing as a millimeter gap, allow_rotate as 90-degree Z rotation, and spread as overflow behavior to a new bed. This adds meaning well beyond the bare schema names and defaults.

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: arranging objects on a bed, packed and centered. The phrase 'packed and centered' distinguishes it from simpler move/set operations, but it does not explicitly name sibling alternatives such as move_to_bed or transform.

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 purpose: use this to pack and center objects on one or all beds. However, there is no explicit when-to-use guidance, no when-not guidance, and no routing to alternatives like move_to_bed, set_bed, or transform.

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

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

With no annotations, the description carries the full burden. It discloses that copies inherit bed and settings and that `arrange` re-arranges beds afterwards, but says nothing about whether a job must be open first, whether copies get new ids/names, how objects are resolved on failure, or what happens to selection state.

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

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

The core behavior is front-loaded in the first sentence and the Args block is terse. The Args entries are not pure restatement of the schema, so they earn their place, though the numbered-list formatting is slightly noisy.

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 needn't be explained, but this is a mutation tool with zero annotation coverage and the description omits preconditions (open job), side effects beyond `arrange`, and failure modes. For a copy operation that duplicates geometry, the description is thinner than the operation's complexity warrants.

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 does add real meaning for all three params: `objects` accepts ids or names (the schema only says array of strings), `count` is copies of each (implying per-object duplication), and `arrange` re-arranges beds afterwards. The notes are terse and don't cover what `count: 0` does or how name/id collisions are handled, so it only partially closes the 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?

"Add copies of objects (same bed, same settings)" names a specific verb and resource and clarifies the copy inherits placement and settings, which distinguishes it in spirit from add_model or move_to_bed. It never names a sibling explicitly, so the differentiation is inferential 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 guidance on when to use this versus add_model, transform, or move_to_bed, nor any prerequisites for calling it. Notably, the sibling tool `arrange` exists and the description mentions re-arranging as a side effect without ever saying when to use `arrange` directly instead.

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 add real context: results show each match's current value, scoped to a bed of the open job, defaulting to the first bed. However it omits what happens when no job is open, whether matching is substring/case-insensitive/regex, and whether results are capped, so the read-only and failure behavior must be inferred.

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?

Front-loaded with the core action and examples in the first sentence, followed by the value-reporting behavior and a compact Args block. No redundant or filler text; every sentence conveys usable 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?

An output schema exists, so return values needn't be explained, and the description covers scope, default bed, and both inputs. It stops short of covering the no-open-job case and result-set limits, which matter for a search tool whose scope depends on ambient job state.

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

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

Schema coverage is 0%, so the description must supply meaning, and it documents both parameters: query as "words to look for" and bed as "which bed's current values to show" including the default of the first bed. The query semantics remain slightly under-specified (matching rules, AND/OR behavior of multiple words).

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 ("Search PrusaSlicer setting names and descriptions") plus concrete example queries that make the resource domain unambiguous. It is clearly distinct from the mutation-oriented siblings such as set_object_settings or set_bed, since this one only reads and reports values.

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

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

Usage is only implied: an agent can infer you'd call this when you want to look up a setting, but the description never says when to prefer it over list_profiles or set_object_settings, nor does it state prerequisites. No explicit when-not guidance is 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 exist, so the description carries the full burden. The verb 'get' and the content listing imply a safe read, and it usefully discloses that slice status and problems (overlaps, off-bed objects) are included. However, it never states read-only semantics, cost, or whether this reflects stale state, which matters for a tool that presumably queries a live modeler.

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 dense sentence with no filler, and the two main groupings (beds, objects) are front-loaded. The fragmentary punctuation around the parenthetical lists is slightly harder to parse than a plain sentence would be.

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

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

With zero parameters and an output schema present, the description need not restate the full return shape, and it still names the key sections. Against a crowded sibling set it stops short of telling the agent how this differs from list_jobs or open_job, which is the one real gap.

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

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

The tool takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate. The enumerated return fields are a bonus, not a substitute for parameter documentation.

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

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

The description enumerates exactly what the call returns: the open job's beds (profiles, settings, objects, slice status, issues) and objects (id, name, bed, size, position, settings). That is specific enough to distinguish it from list_jobs or open_job. It reads as a return-value spec rather than an explicit verb statement, which keeps it from a 5.

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

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

There is no statement of when to call this versus list_jobs (all jobs) or open_job (open/create a job), despite both being siblings. The phrase 'The open job' implies a scope but gives no explicit routing guidance or preconditions.

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. '(newest first)' is useful ordering context beyond the tool name, but it does not disclose pagination, result limits, permissions, or whether all jobs are returned.

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

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

A single front-loaded sentence with no wasted words. The ordering detail is compactly placed in parentheses.

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 output schema covers return values and the zero-parameter schema is fully documented. However, for a list operation with no annotations, the description should at least clarify scope and whether results are paginated or limited.

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 baseline is 4. The description correctly adds no parameter details because there are none to explain.

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

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

States a specific verb and resource ('List print jobs') that an agent can distinguish from get_job or open_job. It does not explicitly name or differentiate itself from those siblings, 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 listing purpose implies when it is used, but there is no explicit guidance on when to choose this over get_job, open_job, or new_job. Alternatives and exclusions are left to inference.

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

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

No annotations are provided, so the description carries the full burden; it reveals only that profiles and filaments are involved. It does not say whether results come from the currently loaded printer vs. a global library, whether it is read-only, how many items are returned, or pagination behavior — significant gaps for a zero-annotation 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?

One short sentence with no waste, but it is not front-loaded with the action verb and the phrase 'for the printer' is ambiguous about which printer. Brevity is fine; the ordering and precision are not.

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 shape needn't be explained, but the description omits the critical implicit-context detail: with zero parameters, the profiles must come from the currently loaded printer, and that is never stated. An agent cannot tell what state must be established before calling this.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly implies the scope is determined by ambient context rather than by arguments.

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 (print profiles plus their filaments) but uses a noun phrase rather than a verb, and never says it *lists/returns* them — the agent has to infer that from the tool name. It is distinguishable from siblings like find_setting or list_jobs only by the word 'profiles'.

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

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

No guidance on when to call this versus find_setting or get_job, and no statement of preconditions (e.g., that a printer/project must be loaded). The agent is left to guess the appropriate 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, yet it never states that objects are removed from their current bed (the core destructive consequence of a move), whether the operation is reversible, or what permissions are needed. It does add useful context that bed="new" clones the current bed's settings and that arrange triggers a re-layout, but the mutation profile stays opaque.

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 purpose sentence is front-loaded and the Args block is tight, with each line adding distinct information. Slightly mechanical formatting, but nothing wasteful.

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 all three parameters are covered. However, for an unannotated mutation tool, the description omits what happens to the source bed and whether the move is reversible, which an agent needs 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%, so the description must compensate, and it largely does: objects accepts ids or names, bed accepts a name or the special value "new" with defined semantics, and arrange is explained as re-arranging the target bed afterwards. Only the default of arrange and any constraints on list size are left unstated.

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 first line gives a specific verb and resource ("Move objects to another bed"), which distinguishes it from copy_objects, remove_objects, and set_bed at a glance. It does not explicitly name those siblings, but the operation is unambiguous.

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

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

There is no statement of when to use this versus copy_objects (which presumably keeps the originals) or set_bed, nor any prerequisite about the source bed. The only usage-like hint is the magic value bed="new", which is a parameter note rather than selection 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 burden. It usefully discloses that a folder is created with today's date prefix and that profiles default to PrusaSlicer's current selections, but it omits what happens to an already-open job, permission requirements, and other 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 purpose is front-loaded in the first sentence, followed by compact Args documentation. The docstring formatting is slightly verbose but every sentence adds 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?

Given a job-creation tool with no annotations, the description covers purpose and all parameters reasonably well, and the presence of an output schema means return values need not be explained. It still lacks context about how the new open job interacts with existing state and error conditions.

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 and it largely does: name is explained with an example and folder-date behavior, while print_profile and filament note 'bed-1' scope and PrusaSlicer defaults. Only valid-value formats and the relationship to list_profiles remain undocumented.

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

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

States a specific verb+resource: starting a new print job with one empty bed and making it the open job. This clearly implies distinction from open_job (which opens an existing job) and get_job, though no sibling is named 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 purpose statement: create a new job that becomes active. However, there is no explicit guidance on when to prefer this over open_job, no prerequisites beyond 'one empty bed', and no exclusions for existing open jobs.

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. 'Open ... to keep working on it' hints at session/active-state semantics but never says whether this mutates server state, requires exclusive access, fails if another session holds the job, or what 'open' does to an already-open job.

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

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

One short sentence with the action front-loaded and the pointer to list_jobs placed inline. Nothing 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?

The presence of an output schema relieves the description of explaining return values, and the list_jobs pointer covers discovery. Still, for a tool with no annotations and an undocumented required parameter, the description leaves the agent guessing about state effects and the accepted value format.

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

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

Schema description coverage is 0% and the single parameter 'name' is undocumented in both schema and description. It is unclear whether 'name' is a human-readable job name, an identifier, or a path, and the reference to list_jobs only weakly implies where the value comes from.

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 ('Open an existing job') and clarifies the intent ('to keep working on it'), which separates it from new_job and list_jobs. It does not, however, distinguish itself from the sibling get_job, leaving the open-vs-get boundary ambiguous.

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 parenthetical '(see list_jobs)' gives a discovery path for finding the job to open, which is genuinely useful. But there is no statement of when to prefer this over get_job, nor any prerequisite or exclusion guidance.

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

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

With no annotations provided, the description carries the full burden and does a good job disclosing side effects: it starts the viewer only 'if needed', opens it in the browser, shows the newest job, and follows new slices. It does not cover authentication, failure modes, or whether the viewer persists, but the core behavior is transparent.

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

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

Two short sentences, front-loaded with the action and side effect, with no unnecessary words. Every sentence adds useful 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?

An output schema exists, so the description need not explain return values. For a zero-parameter tool, the description supplies sufficient behavioral context, though it leaves a small gap in not routing the agent explicitly between this and open_job.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The baseline for a zero-parameter tool is 4, and the description appropriately avoids inventing parameter details.

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 phrase ('Start the viewer ... and open it in the browser') and clearly identifies the resource and its display behavior. It partially differentiates from siblings by mentioning 'newest job' and 'follows new slices', but it never explicitly names open_job or explains how this differs from opening a specific job.

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

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

Usage is implied: this is the tool for launching a live view of the newest job. However, there is no explicit when-to-use guidance versus alternatives like open_job, preview, or slice, and no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden; it does disclose that the tool is a passive inspection aid producing images rather than modifying the model, and that object ids appear as labels. It does not say how the images are returned (content blocks? file paths?), whether rendering is expensive, or whether the bed must already contain objects, which are meaningful gaps for an image-producing tool.

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

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

The purpose and the usage hint are front-loaded in the first two sentences, and the Args block is minimal. Slightly wasteful to repeat a single-parameter signature, but overall 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?

For a tool whose entire output is imagery, with no output schema and no annotations, the description should say what the agent receives back. It conveys the view types and labels but stops short of the return mechanics, leaving the picture of how to consume the result 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 coverage is 0% and the schema's only description-free parameter defaults to null, so the description's "bed: bed name (default: bed-1)" genuinely adds meaning. However, it never says how bed names are discovered or what happens if the named bed doesn't exist, and the stated default (bed-1) differs from the schema default (null), which an agent may read as an inconsistency.

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 concretely what the tool produces: a rendered picture of a bed in top and iso views with objects labeled by id. That is specific enough to distinguish it from mutating siblings like slice or arrange, though the distinction from open_viewer (interactive view) is only 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?

"Use it to check orientation and layout" gives one positive use case, and "before slicing" implies a pre-slice timing. There is no guidance on when not to use it, and open_viewer — the obvious alternative for inspecting the scene — is never named or differentiated.

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 bed must be empty and that delete_objects controls whether contained objects are deleted, which signals a destructive side effect. It does not state irreversibility, required permissions, or what happens to the deleted objects.

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 wasted words. The core operation is front-loaded and the key constraint follows 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?

The output schema exists, so return values need not be explained. For a destructive two-parameter tool with no annotations and 0% schema coverage, the description gives the essential constraint but leaves gaps around the bed identifier format, permissions, and irreversibility.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of delete_objects and its interaction with bed emptiness, but the required 'bed' parameter is only implied as an identifier with no format or accepted values described.

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

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

The description states a specific verb and resource: 'Remove a bed.' This clearly identifies the operation and is distinguishable from siblings like set_bed or move_to_bed. However, it does not explicitly differentiate itself from related removal tools such as remove_objects, so it falls 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 sentence 'It must be empty unless delete_objects is true' provides an important precondition and implies when to set delete_objects. But it does not say when to use this tool versus alternatives like remove_objects, nor does it describe failure behavior or prerequisites such as permissions.

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

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

No annotations are provided, so the description carries the full burden. It implies a destructive mutation but does not say whether removal is permanent or undoable, whether it requires an open job or specific permissions, or what happens to dependent state such as slices or bed assignments.

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 short, front-loaded sentence with no filler, which is structurally fine. The brevity crosses into under-specification given this is a destructive operation with an undocumented parameter.

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 needn't be explained. But for a destructive tool with zero annotation coverage and an entirely undocumented parameter, the description leaves out the safety, prerequisite, and identifier information an agent needs 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% and the single parameter "objects" is undocumented, so the description needed to explain what the strings represent (IDs, names, paths) and whether removal is all-or-nothing. It adds nothing beyond restating 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 verb and resource are stated plainly ("Remove objects") and the scope is limited to "the job," which separates it from copy_objects. However, "objects" is never defined and there is no explicit differentiation from siblings like set_object_settings or move_to_bed that also act on object selections.

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 copy_objects or set_object_settings, and no stated preconditions such as whether the job must be open or the objects loaded. The agent must infer the entire invocation 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 burden and does disclose important behavior: clear drops all overrides, null values remove specific overrides, and bed="new" copies bed-1's profiles without overrides. It still omits permissions, side effects on existing jobs, and whether changes apply immediately, so it is strong but not complete.

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

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

The summary is front-loaded, followed by a compact Args section where each entry adds concrete meaning. There is no redundant or wasteful text.

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 seven-parameter mutation tool with no annotations, the description covers all parameters and key destructive semantics, and the output schema handles return values. It is mostly complete, with only permission and side-effect context missing.

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

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

Schema description coverage is 0%, but the description documents all seven parameters with added meaning: supports values, support_angle threshold semantics, settings examples, and null-removal behavior. This compensates fully for the schema's lack of descriptions.

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: it changes a bed's print profile, filament, or settings, and creates a new bed when bed="new". The bed-level scope distinguishes it from object-level siblings such as set_object_settings, though it does not explicitly name alternatives.

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

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

Usage is implied by the mutation verbs and the special bed="new" case, and list_profiles is referenced for print profiles. However, there is no explicit guidance on when to use this versus set_object_settings, remove_bed, or other bed/job tools.

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 two behavioral facts: settings are persisted into the 3MF as PrusaSlicer object settings, and `clear` drops all of the object's own settings first (a destructive action). It does not say whether values are merged or replaced, whether the change requires a save/slice to take effect, or what happens if an object id is invalid — meaningful gaps for a mutation tool.

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

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

The opening sentence is front-loaded with purpose and the Args list is scannable, with every entry conveying distinct information. Slight overhead from the block-style parameter listing, but no wasted sentences.

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 all six parameters are documented in detail. What is missing is contextual rather than parametric: whether the job must already be open, and whether settings take effect immediately or only at slice time.

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 do all the work, and it does: it gives the accepted `supports` values (off | auto | build_plate_only | painted) where the schema only declares a bare string, explains `support_angle` units and the 0-means-automatic convention, shows a concrete `settings` payload with mixed value types and states that a null value removes one, and clarifies `name` renames while `clear` wipes existing settings.

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 verb+resource (per-object settings) and immediately scopes it relative to bed-level settings, with a concrete example ('supports only for one part, more perimeters for another'). It also states where the data lands ('3MF as PrusaSlicer object settings'), which an agent cannot infer from the name alone. It does not explicitly name set_bed as the sibling to use for bed-wide values, so differentiation is implied rather than stated.

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

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

The phrase 'on top of the bed's settings' plus the per-part example implies when to reach for this tool versus set_bed, but the routing is left to inference. There is no explicit 'use this when X, use set_bed when Y' and no statement of prerequisites (e.g. a job must be open, objects must 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?

With no annotations to lean on, the description does real work: parallel execution, per-bed settings, output written to the job folder, viewer opened only once per session, and an explicit 'does not print'. Missing is what happens on existing output (overwrite?) or failure, but the important side effects 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?

Two front-loaded sentences state the action and its limit before the argument notes. The Args block partially duplicates the schema but does add default semantics, so it earns most of its space.

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 prose, and both parameters are explained. What is under-specified is the implicit context — which job the slice applies to and whether re-slicing overwrites prior output.

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

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

Schema coverage is 0%, so the description must carry the parameters and it does: beds are bed names defaulting to all beds, and open_viewer starts and opens the viewer once per session. Minor gap is where bed names come from and what an empty/null beds value expands to.

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 (slice) plus resource (beds) and names the backend (PrusaSlicer) and the destination (job folder). The line 'Does not print anything' usefully bounds scope, though it never explicitly contrasts itself with the sibling tool preview, which would be the natural point of confusion.

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 negative statement ('Does not print anything') and by the default behaviours, but there is no explicit when-to-call, no prerequisites about an existing job/models, and no comparison to preview or arrange. The agent must infer when slicing is the right next step.

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 real behavior: deterministic step ordering and that reset restores orientation/size but keeps position. It omits whether changes are undoable, whether they persist to the job or only the session, and whether downstream preview/slice state is invalidated.

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

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

Purpose and ordering are front-loaded, and each arg line earns its place with units or examples rather than restating the field name. The docstring 'Args:' formatting is a little verbose for a tool description but wastes no sentences.

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 seven-parameter mutation tool with no annotations, the description covers every argument and the interaction between them; the existing output schema relieves it of explaining return values. It stops short of stating preconditions (objects must be loaded/selected) and side effects on slicing.

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 documents all seven parameters: accepted id/name forms plus the ["all"] shorthand, degree axes with concrete examples, scalar vs per-axis scale, mm units for move_to/move_by, and reset semantics. This adds meaning well beyond the bare titles in the schema.

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

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

Opens with a specific verb list (rotate, scale, lay flat, move) applied to a named resource (objects), which is far more precise than the bare name 'transform'. It is distinguishable from siblings like copy_objects, remove_objects and arrange, though the overlap with move_to_bed is left for the reader to infer.

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 stated execution order (reset, scale, rotate, lay_flat, move) is genuinely useful guidance for combining steps in one call. However, it never says when to use this tool instead of move_to_bed or arrange, nor whether a preview/re-slice is required afterwards — usage is implied rather than stated.

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