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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: units are world millimetres, thickness is sampled geometry rather than mechanical strength, and the overhang angle is a downward-face threshold from horizontal in 0..90. The side effect of 'save SVG previews' sits a bit uneasily with readOnlyHint but is plausibly a non-project byproduct, not a contradiction.

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, then three short semantic notes with no filler. Every sentence earns its place, though the units/thickness/angle notes could be slightly compressed.

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

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

No output schema exists, and the description does not indicate what the measurement returns (metrics? file paths for the SVGs? summary stats), which an agent would want before calling. Given the complexity and the 0% schema coverage on the inputs, the definition is adequate but leaves a notable return-shape gap.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does this well for overhang_angle (defines the angle, valid range 0..90, default implied by schema) but says nothing about project_id or revision, including how a null revision resolves. Partial compensation for a 3-param, undocumented 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?

Specific verb (measure) plus the resources measured: geometry, sampled thickness, contact regions, overhang regions, and it notes it saves SVG previews. The scope is clear and no sibling in the list (which are mostly project/settings/slicing controls) overlaps with it. It stops short of explicitly differentiating from siblings, so a 4 rather than 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 run this versus alternatives (e.g., before start_slice or instead of compare_candidates), no prerequisites, and no exclusions. Usage is only implied by the nature of the measurement.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is known. The description adds genuinely useful behavior beyond that: the batch is atomic (all-or-nothing), it writes to a new revision, and it 'never overwrites the source.' It does not mention validation failure behavior or any permission requirements, so this is solid added context but not rich.

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

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

The action and its atomicity are front-loaded, and each subsequent sentence carries a distinct value rule (JSON types, percent strings, scope semantics, source preservation). It is dense but every sentence earns its place; there is no filler.

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

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

For a mutation tool with nested objects, 0% schema coverage, no output schema and no annotations about return shape, the description covers atomicity and value-type rules well. It leaves gaps on the meaning of target/revision/project_id and on what a successful or failed apply returns, which an agent calling a batch-apply tool would benefit from.

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 all five parameters carry only titles, so the description must compensate. It partially does: it explains scope-dependent value semantics (filament scope selects one existing filament_index, project scope requires complete vector arrays) and percent-string rules. However, target, revision and project_id go unexplained and are never mapped to 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 uses a specific verb+resource: 'validate and apply an atomic batch to a new revision.' That clearly frames a mutation against a revision and is distinguishable from the read-oriented sibling get_settings and from restore_revision. It stops short of describing what 'settings' are, but the action and scope are unmistakable.

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

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

There is no explicit when-to-use statement and no naming of alternatives such as get_settings (to read) or restore_revision (to roll back). The constraints given are correctness rules for values, not routing guidance, so an agent gets no help choosing between this and its siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description adds one genuinely useful trait beyond the annotations: it states that Studio subprocesses are terminated, which is behavior an agent would not infer from 'destructiveHint: false' (a hint that arguably undersells the irreversible, work-aborting nature of a cancel). It says nothing about idempotency, partial results, or what remains of the job afterwards.

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

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

A single sentence that front-loads the action and resource and then appends the side effect. Every clause earns its place; nothing is padding.

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

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

For a one-parameter action tool with annotations and no output schema, the description covers the action and its main consequence, which is close to sufficient. It stops short of what an agent would want before committing an irreversible operation: whether cancellation is idempotent, whether it can be undone, and what the caller receives. The mismatch between 'terminate subprocesses' and destructiveHint=false is left unexplained.

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 is documented only by its type and the title 'Job Id'. The description never mentions job_id, where it comes from, or its format, so it does not compensate for the coverage gap. The parameter is self-evident from the tool name, which keeps this from being a 1, but the description adds no meaning.

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

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

States a specific verb (cancel) plus the resource (job) and narrows the scope to jobs that are queued or running, and it names a concrete side effect (terminating Studio subprocesses). No sibling tool (get_job, start_slice, open_in_studio) performs cancellation, so the agent can place it unambiguously.

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 'queued or running' implicitly defines which jobs this tool is valid for, which is light usage guidance. There is no explicit when-to-use statement, no mention of alternatives or prerequisites (e.g., permissions, whether the caller must own the job), and no guidance about what to do instead for already-completed 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?

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds meaningful behavior beyond that: asynchronous job creation with a poll requirement, and the important caveat that strength/finish results remain unverified. It does not describe failure modes or job lifetime, so not 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?

Front-loads the core comparison purpose, then layers workflow, constraints, and caveats in compact sentences. Dense but each clause carries information; minor run-on feel in the constraint/caveat 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?

With no output schema, the description does the work of explaining the return contract (persistent job, poll get_job, time/material estimates and tradeoffs) plus the reliability caveat. Missing constraints-object detail and any error/expiry behavior keeps it below 5.

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 carries the full burden. It usefully documents the candidate item shape ({name, changes} or {name, revision}) and the numeric constraint keys (max_time_seconds, max_filament_g), but leaves project_id, revision, and the constraints object's overall semantics unexplained.

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

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

States a specific verb and resource ('Compare unchanged baseline with 1..7 alternatives') and even pins the cardinality of the candidates argument. It names related siblings (edit_regions, get_job) rather than the tool it competes with (e.g. analyze_geometry), so differentiation is present but not a direct 'use X instead of Y' contrast.

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

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

Gives real workflow guidance: it returns immediately and the caller must poll get_job, and spatial candidates require revisions produced by edit_regions. It lacks explicit when-not-to-use conditions or a direct alternative to pick between, which keeps it short of a 5.

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

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

Annotations only give the coarse safety profile (readOnly=false, destructive=false, openWorld=false); the description adds genuinely new behavior: edits are atomic, they produce a new revision rather than mutating in place, and paint mutates a shared mesh resource so every instance is affected. That last point is exactly the kind of side effect an agent must know before calling. Missing permission/error behavior keeps it from 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?

Four short lines, front-loaded with the core behavior and the scoping constraint, then the action vocabulary, then the one dangerous side effect. Nothing is repeated from the schema and nothing is padding.

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

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

For a mutation tool with no output schema and three undocumented required parameters, the description covers atomicity and the shared-resource caveat but omits prerequisites, how the resulting revision is identified/returned, and undo semantics. The external resource pointer mitigates this somewhat but the definition alone is not sufficient to call the tool confidently.

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 edits array is schemaless (additionalProperties: true, no enum), so the description carries real weight by enumerating the valid action names for that array and routing the agent to a resource URI for exact shapes. However project_id and revision — both required strings — are left completely undefined, so the compensation is only partial.

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 ('Apply spatial edits') plus the scope constraint ('atomically to a new revision'), and enumerates the six supported action types. It is unambiguous against every sibling, none of which touch geometry regions, though it never names an alternative or explicitly contrasts itself with 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 only implied: the agent learns which action names are valid and is pointed to the bambustudio://spatial-edits resource for shapes. There is no statement of when to use this versus e.g. analyze_geometry or open_in_studio, and no prerequisites such as whether a project must be open or how a revision is chosen.

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

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

Annotations state readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered structurally. The description adds that a job_id must be a succeeded job to get slicing artifacts, which is useful context, but it says nothing about overwrite behavior on an existing destination or permissions.

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

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

Two short sentences with no filler, and the key job_id constraint is front-loaded. Slightly awkward wording ("Export to a new filename") but structurally efficient.

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

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

For a 4-parameter mutation tool with no output schema and no schema descriptions, the description is thin: it omits destination/revision semantics and the export result. It covers the trickiest parameter (job_id) but leaves the agent under-informed about the rest.

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 carry parameter meaning. It only clarifies job_id (must be a succeeded job); it says nothing about revision, project_id, or what destination format means, leaving most of the 4 parameters unexplained beyond their self-evident names.

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?

"Export to a new filename" gives a clear verb+resource when combined with the name export_project, and the second sentence narrows the scope. It does not explicitly distinguish itself from any sibling, but no sibling in the list is a competing export path, so ambiguity is low.

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

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

It gives one conditional guideline: supply a succeeded job_id to export that exact revision with slicing artifacts. This implies when to pass job_id, but there is no guidance on when to export without a job_id, when to prefer restore_revision or open_in_studio, or any prerequisites.

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

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

Annotations already declare readOnly=true, destructive=false, and closed-world, so the safety profile is covered. The description adds that it returns 'honest configuration coverage,' hinting that it discloses the degree of config completeness, but it never explains what that coverage means or what the response looks like.

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

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

One front-loaded sentence with no padding, listing the four reported items up front. The phrase 'honest configuration coverage' is slightly unusual but does not bloat the 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 zero-argument, read-only tool with no output schema, the description usefully enumerates the fields returned, which is exactly what an agent needs to decide relevance. The only gap is the undefined notion of 'configuration coverage.'

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4.

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 clear verb ('Report') and enumerates the specific resources returned: Studio runtime, supported version, profiles location, and configuration coverage. It does not distinguish itself from the sibling get_settings, which an agent could easily confuse with an environment/config report.

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

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

There is no statement of when to call this versus alternatives like get_settings, list_options, or inspect_project, and no prerequisites or exclusions. The agent must infer usage purely from the field list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely new context by disclosing what data is returned (log tail, estimates, output locations) and that status is persistent. It omits whether the call blocks or must be polled, and whether completed jobs remain readable.

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

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

One dense sentence with the verb and return payload front-loaded and no filler. The comma-separated return list is efficient, though slightly run-on.

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

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

With no output schema, the enumeration of returned fields is valuable and mostly fills that gap. However, the definition leaves out how to obtain job_id and what happens for an unknown or expired job id, which matters for a single-required-parameter lookup tool.

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

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

Schema description coverage is 0% and the single parameter job_id has no description anywhere. The tool description never mentions job_id, where to obtain it (presumably from start_slice or compare_candidates), or its format, so it fails to compensate for the complete schema gap.

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

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

Uses a specific verb ("Read") and enumerates the resources returned (status, log tail, estimates, output locations), but never clarifies what a "job" is or that jobs are produced by start_slice/compare_candidates. The link to siblings is only implicit in the phrase "slice or comparison status", so an agent can infer but not confirm the distinction from the description 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?

No when-to-use statement, no prerequisites, and no named alternatives. The description doesn't say this is the polling companion to start_slice/cancel_job, nor when to prefer it over inspect_project or list_options. Usage must be inferred entirely from the name.

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

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

Annotations already give readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: output is deterministic, and it explicitly does not infer physical quality from the supplied declarations. It stops short of saying how much is returned, whether any project state is mutated, or how mismatch severity is expressed.

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

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

Two compact sentences with no padding, and the return-value summary is front-loaded. The caveat sentence earns its place. Slightly hurt by the vague referent 'selected concerns' appearing before the resource that defines it.

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

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

With no output schema, the description must carry return semantics, and it partially does by listing the three result categories. However the required project_id is never explained, the concerns-selection instruction has no corresponding parameter, and there is no indication of the shape or volume of results. Adequate but with a real hole for a tool whose only required input is 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 coverage is 0%: project_id and revision are undocumented in the schema and entirely unmentioned in the description. Worse, the description directs the agent to 'select concerns' while no concerns parameter exists in the schema, so the stated input contract doesn't map onto the actual inputs. The agent gets no help understanding what project_id or revision should be.

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 'Return' and the three output categories (missing-input questions, context/settings mismatches, sourced rules) give a rough sense of what comes back, and it names the quality-guide resource as the source. But 'selected concerns' and 'sourced rules' are undefined vocabulary, and the description never states plainly that this is a read-only diagnostic lookup over a project. Against siblings like get_settings or inspect_project the agent cannot easily tell which one it wants.

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 does give one actionable usage cue: select concerns from bambustudio://quality-guide, plus a caveat that inputs are user declarations and no physical quality is inferred. What's missing is any when-to-use framing versus siblings such as get_settings, inspect_project, or list_options, and no prerequisites or exclusions 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?

Annotations already establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description still adds real behavior context beyond that: target resolves to 1-based plate/0-based filament indices, and Studio-normalized settings only appear after a completed slice job, which materially affects interpretation of results.

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 paragraphs with the core purpose front-loaded, then scope/target/key semantics in tight order. The dense target line earns its space as the only place that parameter's mapping is documented; nothing is padded.

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

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

For a read-only tool with annotations covering safety and no output schema, the description supplies what an agent needs: valid scopes, target mapping, key filtering, and the slice-job caveat. Return shape and revision semantics are the only remaining gaps, and neither blocks a correct call.

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

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

Schema description coverage is 0%, so the description must carry the parameters, and it largely does: it documents the scope values, explains that target selects plate_index/object_id/volume_id/min_z/max_z/filament_index, and describes keys as a response bound. Only revision is left unexplained, which keeps it from a 5.

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

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

"Read settings and their origin" gives a clear verb+resource, and the enumerated scopes (project, plate, object, volume, height_range, filament) sharpen exactly what settings are covered. It never explicitly names the write-side sibling apply_settings, but "Read" vs a mutating tool is inferable, leaving it just short of full sibling differentiation.

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

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

"Use keys to bound the response" is a genuine usage hint, and the scope list implies which selection to make. However, there is no explicit statement of when to prefer this over apply_settings, restore_revision, or inspect_project, and no prerequisites or when-not guidance beyond a passing note that normalized settings come from completed slice 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. Beyond that the description discloses nothing: no pagination, no output shape, no indication of what 'inspect' actually returns or whether a revision other than the latest changes results.

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

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

It is a single tight sentence with no filler, which is good, but the brevity comes at the cost of specificity — it is under-specified rather than genuinely concise.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it does not. A read-only inspection tool with two undocumented params and a null revision default needs more than a noun list to be callable with confidence.

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. The description never mentions project_id (the required scoping key) or revision (its format, how to obtain one, or what leaving it null does), so it fails to compensate for the schema gap.

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

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

The description pairs a verb ('Inspect') with an enumerated list of resources (objects, volumes, resource IDs, instances, plates, bounds, revision history), so the general purpose is inferable. However, it never says this operates on a project, and the sprawling resource list reads more like an inventory dump than a scoped statement of what the tool returns, so it does not clearly separate itself from siblings like get_environment or restore_revision.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The description includes 'revision history' while a sibling restore_revision exists, yet nothing tells the agent whether this tool reads history or is the correct entry point versus open_project/get_environment.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond annotations: it does not run G-code, unknown firmware branches and mappings remain unknown, and reported targets are not actual temperatures or speeds. It does not describe return shape or permission requirements, but that is a minor gap given the annotations.

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

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

Three short sentences, front-loaded with the core purpose, followed by mode selection and then key limitations. There is no obvious filler or repetition, and the structure helps an agent parse the main behavior quickly.

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

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

For a read-only inspection tool, the description says what is inspected and adds important limitations about firmware mappings and temperature/speed targets. But with 0% schema coverage and no output schema, it leaves required project_id semantics and revision behavior undocumented and does not describe the shape of returned inspection data.

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 parameter meaning. It clarifies that job_id selects an exact succeeded revision and that otherwise the saved project is inspected, and it hints at revision behavior. However, it never explicitly explains the required project_id parameter or whether revision can be used independently or what its default behavior is, so compensation is only partial.

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, 'inspect,' and concrete resources: embedded G-code targets, object layers, and feature feeds. It also distinguishes job_id mode from saved-project mode, but does not explicitly name sibling tools like inspect_project as alternatives, so it falls short of maximal sibling differentiation.

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

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

Clearly explains when to use job_id (to inspect an exact succeeded revision) versus otherwise inspecting the saved project, including older sliced imports. It also sets expectations about unknown firmware branches and that targets do not establish actual temperatures or speeds. It lacks explicit when-not-to-use guidance or named alternative 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?

Annotations already declare the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs incremental context. It adds that the catalog is versioned and what attributes are inspectable, but says nothing about pagination behavior despite limit/offset parameters, which is a trait annotations do not cover.

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 and the semicolon-clause adds the payload summary. Efficient, though the second clause is packed and could have traded some attribute listing for usage information.

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

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

For a four-parameter search tool with no output schema and no annotation coverage of result shape, the description omits how query matches, how results are paged, and how scope narrows the catalog. An agent can guess the intent but not call it correctly on the first try.

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 all four parameters (limit, query, scope, offset) are undocumented in both structured fields and the description. The only faint hint is the word 'scopes' in the list of attributes, but query semantics, default vs max limit, and offset paging are entirely unaddressed.

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 clear verb (Search) plus resource (versioned FFF configuration catalog) and enumerates what the results expose (types, units, ranges, defaults, scopes). That distinguishes it from get_settings/list_profiles, though it never names a sibling explicitly and 'FFF' is unexplained jargon.

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

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

There is no guidance on when to call this versus get_settings, get_environment, or list_profiles. The word 'Search' implies a lookup intent, but the description never states the condition that selects this tool over its catalog-reading 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?

Annotations already establish that this is a safe read-only, non-destructive, non-open-world operation. The description adds the scope of profile kinds and a usage hint, but it does not disclose filtering behavior, return format, or any other behavioral traits beyond what the annotations provide.

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

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

Two short sentences with no filler. The purpose is front-loaded, followed by the most actionable usage note.

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

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

For a simple two-parameter read-only listing tool with annotations and no output schema, the description is minimally adequate. It covers what is found and one usage tip, but with 0% schema coverage it should do more to clarify the optional kind/query parameters and whether query is exact or substring-based.

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

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

Schema description coverage is 0%, so the description must compensate. It names the likely kind values ('machine, process, or filament profiles') and indicates that the query accepts exact names or paths, which adds meaning beyond the bare schema. However, it never explicitly ties these to the 'kind' and 'query' parameters, leaving the mapping inferential.

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

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

The description states a clear verb and resource: 'Find machine, process, or filament profiles.' It specifies the profile subtypes, but it does not distinguish this tool from siblings like list_options or get_settings, which also list/retrieve configuration information.

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 offers an implied usage context ('Use exact names or paths when importing models'), but it does not state when to use list_profiles versus alternatives or provide any exclusions. The agent must infer the selection criteria.

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

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

Annotations mark this as non-read-only but non-destructive, and the description usefully adds that it does not synchronize or replace unsaved GUI state — a real side-effect boundary that the hints alone don't convey. It still omits anything about permissions, whether opening changes server-side state, or what happens if a Studio session is already open.

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

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

Two tight sentences, action first, caveat second, with no filler. Every clause carries information the agent needs.

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 key behavioral nuance (no GUI-state replacement) is covered and no output schema exists to explain, but with zero parameter documentation the agent lacks enough to know what revision to pass or what a successful launch returns.

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

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

Schema description coverage is 0% and the description mentions neither project_id nor revision, so the agent gets no help on the meaning of "revision" or what a null revision defaults to. With two parameters entirely undocumented in both schema and prose, the description fails to compensate.

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

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

Specific verb ("Launch") plus a specific resource ("the saved revision in Studio"), so the action is unambiguous. It only partially differentiates itself from siblings such as restore_revision or open_project; the negative clause about GUI state helps but no sibling is named.

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?

"for review" implies the intended context, and the second sentence sets a boundary (this is not how you push or replace GUI state). However, it never says when to prefer this over restore_revision, open_project, or inspect_project, leaving the routing decision 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?

Annotations already declare destructiveHint=false and openWorldHint=false, so the safety profile is known; the description usefully adds that the project is copied into an isolated workspace, implying the original is preserved. It still omits what happens to an existing workspace, whether Studio must be running, and what the result looks like.

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

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

A single front-loaded sentence with no filler; the core action ('Copy a saved 3MF') comes first. The trailing 'through Studio' clause adds ambiguity rather than value, keeping it from a 5.

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

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

For a four-parameter mutating tool with no output schema and no schema descriptions, the description should carry more weight than it does. It establishes the isolation/copy semantics but leaves the profile-override behavior and observable outcome under-specified.

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 schema gives no parameter meaning at all and the description must compensate. It only gestures at 'explicit profiles' and a saved 3MF, without clarifying that machine_profile, process_profile, and filament_profiles are optional overlays or how they relate to path.

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 specific actions on a definite resource: copying a saved 3MF into an isolated workspace, or importing a model with explicit profiles. It is clear what the tool does, but it never distinguishes itself from siblings such as open_in_studio or inspect_project, and the dual 'or' behavior leaves which mode applies to the agent.

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, no when-not-to-use, and no named alternative despite siblings like open_in_studio and export_project that a caller could confuse with this. The two modes hint at scenarios but never say which parameters or conditions select them.

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

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

Annotations declare non-read-only but non-destructive, and the description adds substantive context beyond them: it is a replace (overwrite) operation, it does not write the 3MF, observations are scoped to a single revision, and job_id must reference a succeeded slice. What it does not clarify is what happens to previously declared context when replaced.

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

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

Four short sentences, front-loaded with the verb and scope, with constraints following. Slightly dense but every sentence adds information; 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?

No output schema exists, so the description need not explain returns, and the scope/boundary statements are strong. But for a tool whose only substantive parameter is an undocumented free-form object, deferring entirely to an external resource leaves the definition incomplete on its own.

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 context parameter is a free-form nested object, so the description carries the full burden — yet it explains none of project_id, revision, or context. It only mentions an optional job_id (not visible in the top-level schema) and defers the input shape to an external resource URI, which is a pointer rather than an explanation.

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 (Replace) and resource (user-declared print context) and enumerates the content covered: hardware, filament, calibration and physical observations, scoped to a project. It is clear enough to separate from settings/geometry siblings, though it never names an alternative tool 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?

It gives useful negative guidance — 'records declarations, not verified measurements' and 'does not edit the 3MF' — which tells the agent what this tool is not for. However, it never says when to prefer this over siblings like apply_settings or edit_regions, so routing still requires 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?

Annotations already declare readOnlyHint=false and destructiveHint=false; the description reinforces this by promising "preserve all previous revisions," telling the agent the operation is additive rather than destructive. It also discloses the concurrency-protection purpose of the revision parameter, which is genuine behavioral context. It stops short of describing failure behavior on a stale head or auth requirements.

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

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

Three tight clauses with no filler. The primary behavior is front-loaded in the first sentence, and the parameter disambiguation follows immediately after. Nothing is 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 no output schema and no annotation detail on side effects, the description supplies the essentials: what gets created, that history is preserved, and how the two revision-style parameters differ. A note on conflict/error behavior for the concurrency check would make it fully self-contained.

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 carry the parameter burden and largely does: it clearly disambiguates revision (current head, for concurrency protection) from restore (the revision to copy), which are otherwise easy to swap. project_id is unaddressed, but its meaning is self-evident.

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 (restore) and resource (revision), plus the key outcome: the restored revision becomes a new head. The mechanics of restoring vs. the head pointer are explained, so an agent can distinguish it from mutating siblings like edit_regions. It does not explicitly contrast itself with any named sibling, keeping it just 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?

"Restore a historical or candidate revision" implies the usage context, and naming candidate revisions hints at a comparison workflow (compare_candidates → restore_revision). However there is no explicit when-to-use statement, no prerequisites, and no stated alternatives, so usage is only implied.

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

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

Annotations declare only that this is a non-read-only, non-destructive, closed-world operation. The description adds meaningful behavior beyond that: the call is queued/detached, returns immediately rather than blocking, and completion must be observed via get_job. It omits timeout behavior, auth requirements, and what the job actually produces.

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

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

Three compact clauses, front-loaded with the action, then the async contract, then the one non-obvious parameter rule. No filler sentences and nothing that restates structured fields.

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

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

With no output schema, the description correctly points to get_job for results, covering the return path. However, for a job-launching mutation tool it leaves too much unsaid: the meaning of revision, timeout_seconds, and what happens on timeout or failure.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate and largely does not. It only clarifies plate_index (0 = all plates, values are 1-based); revision, project_id, and timeout_seconds remain undocumented in both the schema and the description.

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

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

"Queue a detached Studio slice" gives a specific verb (queue) and resource (Studio slice), and the async framing distinguishes it from synchronous siblings like open_in_studio. It never names a sibling alternative explicitly, but an agent can tell what operation this performs.

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?

"Returns immediately; poll get_job" clearly describes the async workflow and directs the agent to the correct follow-up tool, which is real usage context. There is no statement of when not to use this tool or what competing operation to prefer, 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.