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

Annotations only provide a title, so the description carries the behavioral burden. It discloses that the tool posts a raw BTM payload (a low-level, hand-written operation), and the 'validate' parameter description adds that it re-reads the feature list and fails on regeneration errors. It does not explicitly state that this is a mutating operation, but 'Post' and 'add' clearly imply it. The escape-hatch framing also warns the agent this is advanced usage. Minor gap: no mention of auth requirements or failure modes beyond validation.

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

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

Two sentences, zero filler. The core action and the escape-hatch purpose are front-loaded, and the prerequisite sibling is named in the same breath. Every word earns its place.

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

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

For a low-level raw-payload tool with no output schema, the description gives the essential context: what it posts, where, when to use it, and what to read first. The validate parameter's behavior is documented in the schema. It could add a note about the response shape or error behavior, but the escape-hatch framing plus the prerequisite pointer is enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds context for the 'feature' parameter by calling it a BTM payload and mentioning the BTFeatureDefinitionCall-1406 envelope, which is genuinely useful beyond the schema. However, the description does not explain the doc/ws/elem URL-segment pattern beyond what the schema already says, so the added value is modest. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Post'), a specific resource ('a hand-written BTM feature payload to a Part Studio'), and explicitly frames it as the escape hatch for feature types with no dedicated tool. This clearly distinguishes it from the many sibling feature-creation tools (extrude, hole, fillet, etc.) and from onshape_update_feature/onshape_delete_feature.

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

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

The description explicitly says when to use it: for feature types this server has no dedicated tool for. It also names the prerequisite sibling, onshape_get_feature_specs, telling the agent to read that first. This is strong routing guidance that prevents misuse of the raw-payload tool when a dedicated tool exists.

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 carry only a title, so the description bears the full behavioral burden. 'Post' reveals it is a mutation, but there is no mention of permissions/auth needs, that a raw payload bypasses the safety of typed mate tools, what happens to the assembly on partial failure, or the practical consequence of the schema's 'validate' default (a re-read that fails the call on regeneration error). For a low-level write escape hatch, that is a significant gap.

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

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

A single sentence, front-loaded with the action and closed with the routing rule. Nothing redundant, nothing 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?

With five parameters, a free-form nested 'feature' object (additionalProperties), no output schema, and no annotations, the description is too thin: it does not say where a valid payload comes from (e.g. onshape_get_assembly_features), what the response returns, or what 'validate' failure means in practice. An agent could not confidently construct a correct call from this definition alone.

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

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

Schema description coverage is 100%, so doc/ws/elem and the 'validate' semantics are already documented in the schema; baseline 3 applies. The description adds only the phrase 'hand-written payload', hinting that 'feature' is unvalidated free-form JSON, and gives no hint about where to obtain a valid payload shape.

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

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

States a specific action (post a hand-written assembly feature payload) on a specific resource, and the phrase 'escape hatch for mate types with no tool here' implicitly distinguishes it from the sibling mate tools (onshape_assembly_mate, onshape_assembly_relation) and from onshape_update_assembly_feature. It never names those siblings explicitly, so the differentiation is inferential rather than declarative.

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 escape hatch for mate types with no tool here' signals the when-to-use condition (only when no dedicated tool covers the mate type), which is genuine routing guidance. However, no alternative is named, no prerequisite is given (does the element need to be an assembly tab?), and there is no when-not-to-use statement beyond the implication.

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 provide only a title, so the description carries the burden. It conveys the key behavior (rigid grouping that locks instances without mates), but omits that it creates a feature in the assembly, whether it's reversible, error behavior, or permission needs—relevant for a mutation tool with minimal annotations.

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

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

A single front-loaded sentence with no filler. Efficient, though it is so terse that a bit more context could have been added without bloat.

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 title-only annotations, the description is thin—it doesn't mention the feature-creation side effect or validation behavior, though the fully documented schema covers the inputs.

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

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

Schema coverage is 100%, so all six parameters are already documented in the schema. The description adds no parameter-level meaning beyond that, making the baseline 3 appropriate.

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

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

States a specific action (lock instances together) with a clear mechanism (no individual mates), which distinguishes it from mate-based siblings like onshape_assembly_mate. It doesn't explicitly name the alternate tool, 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?

"Without individual mates" implies when this is preferable to mating, but there is no explicit when-to-use/when-not guidance or named alternative. Usage is only inferable.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds some value by enumerating the returned quantities (mass, volume, centroid, inertia) and the whole-assembly scope, but it does not mention units, coordinate system, or response structure. No contradiction with 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?

The description is nine words and contains no filler or repetition. The key target ('whole assembly') and the output list are front-loaded, making it easy to scan.

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 query tool with all parameters fully documented in the schema, this description is largely complete: it names the object scope and all returned value categories. It could be more complete by stating units or coordinate frame, and there is no output schema to fall back on, but an agent has enough information to select and invoke the tool 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 100%, with each required identifier (doc, ws, elem) explained in the context of the Onshape URL. The tool description itself adds no parameter-level meaning, so the schema carries the full burden; the baseline of 3 applies.

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

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

The description clearly states what the tool produces—mass, volume, centroid, and inertia—for a whole assembly, and the 'whole assembly' qualifier narrows the scope. However, it does not explicitly contrast this with the closely named sibling onshape_mass_properties, so it is clear but not fully differentiated.

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

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

The phrase 'for a whole assembly' implies the intended use case (assembly-level mass properties) and suggests it is not for individual parts. It gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives such as onshape_mass_properties or onshape_measure.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses useful semantics like mate-type options and connector-ordering effects, but it never explicitly states that this creates a persistent assembly mate feature, what permissions are required, or what the validate parameter does on failure — schema covers validate but the description does not surface the mutation profile.

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

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

Three sentences, zero waste. The operation is front-loaded, followed by connector-format details and then the ordering caveat, which is exactly the order an 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?

For a mutation tool with no annotations, no output schema, and seven parameters, the description leaves key operational facts unsaid: that it creates a feature, error/failure behavior, and what validate actually gates. The connector semantics are complete, but the mutation and validation story is only inferable.

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

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

Schema coverage is 100%, establishing a baseline of 3, and the description genuinely adds meaning: it enumerates concrete mate types beyond the schema's bare 'Mate type (default FASTENED)', explains the two connector representation shapes, and clarifies that the first connector is the moving part. It does not document name or validate behavior, but it improves on the schema's semantics.

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

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

The description states a specific verb and resource — joining two mate connectors with a mate — and enumerates mate types, so the agent knows exactly what operation it performs. It does not explicitly distinguish itself from sibling tools such as onshape_assembly_mate_connector or onshape_assembly_relation, which keeps it 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?

It gives concrete procedural guidance: where to obtain connectors (onshape_get_assembly), the two accepted connector formats, and the ordering rule (moving part first). It stops short of stating when not to use it or naming the alternative sibling for other join operations.

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 carry only a title, so the description bears most of the disclosure burden: it correctly frames the operation as creating a feature via inference and discloses that the return value is a feature id. It does not mention that this mutates the assembly feature list, whether the connector is persisted, or what happens if 'validate' fails beyond what the schema already spells out. Useful context, but an incomplete behavioral picture for a mutation.

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

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

Two tight sentences with the core action front-loaded and the downstream dependency in the second clause; nothing extraneous. It could be marginally clearer by naming the return type explicitly ('returns the feature id'), but 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 7-param mutation with no output schema, the description does cover what the agent most needs: what gets created, how it's inferred, and that the output feeds onshape_assembly_mate. The one real gap is the absence of any note on error behavior or side effects, which 'validate' hints at only in the schema.

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

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

Schema description coverage is 100%, so every parameter (doc/ws/elem/occurrence/name/validate/inference) is already documented with defaults and URL-segment hints. The description only echoes the inference examples already present in the schema, adding no syntax or value guidance beyond it — baseline 3 applies.

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

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

The description states a specific verb and resource — 'Place an implicit mate connector on an instance by inference' — and immediately ties it to the sibling that consumes its output ('what onshape_assembly_mate then joins'). The parenthetical inference examples (CENTROID, TOP) make the mechanism concrete, so an agent can distinguish this from onshape_assembly_mate and onshape_assembly_add_feature.

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 sequencing hint ('Its feature id is what onshape_assembly_mate then joins') tells the agent this is a prerequisite step in the mating workflow, which is genuine when-to-use guidance. It stops short of explicit exclusions — e.g., it never says when to use an explicit mate connector feature instead of inference — so it earns a 4 rather than 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 carry only a title, so the description bears the full burden and does disclose meaningful behavior beyond the schema: it mutates other features by completing missing mate parameters and reports them in completedMates, and it fails if the relation does not regenerate. It does not state permission requirements or whether an existing relation is overwritten, but the side-effect and failure disclosures are unusually concrete.

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 purpose, then the type enumeration, then the side-effect and failure notes. Dense but every sentence adds information; the first sentence is long with nested parentheticals but remains scannable.

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 10-parameter mutation tool with no annotations and no output schema, the description covers the valid type/mate combinations, the dof derivation, the completedMates return value, and the failure mode. Missing only permission/prerequisite and overwrite semantics to be fully complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that each mate's degree of freedom follows from its type and that cylindrical mates contribute whichever the relation needs, which clarifies the purpose of the dofs override. It also maps ratio and distance_per_revolution to their relation types, though that partly duplicates the schema text.

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

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

States a specific verb and resource — coupling two existing mates so one drives the other — and then enumerates the four relation types with the mate types each requires (GEAR = two revolutes, SCREW = one cylindrical mate). This clearly separates it from the sibling mate-creation tools like onshape_assembly_mate, since it operates on already-existing mates rather than creating them.

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

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

The per-type prerequisites (e.g. 'RACK_AND_PINION (a revolute and a slider)', 'SCREW (one cylindrical mate)') effectively tell an agent when a given relation is valid. There is no explicit exclusion or named alternative, but the context for selecting among the four relation types is clear.

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

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

Annotations already provide readOnlyHint=true. The description adds value by noting that secrets are redacted and that the tool reports credential origin and validity, going beyond the annotation. It does not explicitly state that the verify parameter controls whether a live check is performed, but that is captured in the schema.

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

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

Two sentences with no redundant wording. The main purpose is front-loaded, and the additional note about redaction is concise and relevant.

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 read-only status tool with one optional parameter and no output schema, the description covers the core behavior and adds redaction context. It is adequate for an agent to understand the tool's function, though it could mention the verify parameter's effect explicitly.

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

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

Schema description coverage is 100% for the single 'verify' parameter, which is fully described in the input schema. The description adds no additional semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool reports which credential is active, its source, and validity. It is specific and not a tautology, but it does not differentiate from the similarly named sibling onshape_login_status, which could overlap in purpose.

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

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

No guidance is given on when to use this tool versus alternatives like onshape_login_status or onshape_login. It does not mention conditions for use or exclusions.

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

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

Annotations contain only a title, so the description carries the full burden of behavioral disclosure. It identifies the operation type but does not mention that boolean operations typically consume tool bodies unless keep_tools is set, that the feature is validated by default, or what happens on regeneration errors. For a mutating CAD operation, this is a significant transparency gap.

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

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

Two short sentences with no filler. The core action and operation modes are front-loaded, and the special subtraction requirement is stated economically. Every word earns its place.

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

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

This tool has 10 parameters, a destructive editing effect, and no output schema or meaningful annotations. The description only covers the basic operation and one parameter dependency. It omits default behavior for tools/keep_tools, validation behavior, and side effects, leaving an agent without enough context to anticipate the tool's full impact.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema by explicitly calling out that SUBTRACTION also requires the targets query, which is a critical conditional dependency not stated in the parameter descriptions themselves.

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 action ('Combine bodies') on a specific resource (bodies) and enumerates the operation modes (UNION, SUBTRACTION, INTERSECTION). However, it does not differentiate from the closely named sibling tool onshape_boolean_union, leaving the agent to infer which of the two boolean tools to choose.

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

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

The description gives one useful operational guideline: subtraction requires the targets query. But it provides no general guidance on when to use this tool versus onshape_boolean_union or any other feature-creation sibling, and no exclusions or prerequisites. The context is implicit rather than explicit.

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

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

Annotations only contain a title, so the description carries the behavioral burden. It states that the operation merges all modifiable solid bodies, implying a mutation. However, it does not disclose side effects such as whether original bodies are removed, whether the operation is destructive, or failure conditions (e.g., what happens if no bodies are modifiable). It also does not mention that this adds a feature to the tree. This is a minimal but honest description; it conveys the core behavior without 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?

The description is two sentences with no filler. The primary action is front-loaded ('Merge all modifiable solid bodies into one'), and the second sentence provides a practical use case. Every word earns its place, and the structure is optimal for quick comprehension.

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

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

Given the tool's simplicity and that the schema fully documents parameters, the description covers the essential purpose and context. It explains what the tool does and when to use it, which is enough for an agent to select and call it. The lack of an output schema means return values are not expected to be detailed, and the description does not need to explain them. Minor gaps exist (e.g., failure behavior), but overall it is complete for its role.

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

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

Schema description coverage is 100%, so all five parameters already have detailed descriptions in the schema. The tool description adds no parameter-specific information beyond what the schema provides. Per the rubric, when coverage is high, the baseline is 3. The description does not clarify any parameter semantics further, which is acceptable.

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

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

The description clearly states the action: 'Merge all modifiable solid bodies into one.' It identifies the resource (solid bodies) and the operation (union). It also adds context about the typical use case ('cleanup before exporting a single part'), which helps an agent understand when it applies. The phrase 'all modifiable' distinguishes it from a generic boolean tool like onshape_boolean.

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

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

The description provides a clear use case: 'The usual cleanup before exporting a single part.' This signals when an agent should consider this tool. It does not explicitly name alternatives or exclusions (e.g., when to use onshape_boolean instead), but the context implies it is for merging everything into one body. This is sufficient guidance for most scenarios, though explicit sibling differentiation would be stronger.

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 provide a title, with no readOnly or destructive hints, so the description carries the full burden. It discloses that selection behavior mirrors onshape_fillet, which is a behavioral note, but it does not mention any other behavioral traits like whether the operation modifies the document, requires specific permissions, or has side effects on existing features. This is a significant gap 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 description is extremely concise at two sentences, front-loading the primary purpose and then providing a helpful pointer to onshape_fillet. It wastes no words, but it could arguably include a bit more context without losing conciseness. It is well-structured and 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 tool with 14 parameters (3 required) and no output schema, the description is incomplete. It does not explain how the parameters interact (e.g., which chamfer type requires which fields), any prerequisites, or what happens after execution. The only guidance is on selection, which is helpful but insufficient for a tool of this complexity. The schema descriptions cover parameters individually, but the description does not tie them together or provide workflow context.

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

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

Schema coverage is 100%, meaning all 14 parameters have descriptions in the schema. The tool description itself adds no parameter-specific meaning, but per the rubric, high schema coverage earns a baseline of 3. The description does not compensate beyond that, so 3 is appropriate.

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

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

The description states a specific action ('Bevel the selected edges') with a clear resource (edges). It also references onshape_fillet for selection, which helps distinguish it from that sibling (fillet rounds edges while chamfer bevels them). This is unambiguous and specific.

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

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

The description gives one usage guideline: 'Selection works exactly as for onshape_fillet.' This tells the agent how to select edges, but it does not explain when to use chamfer vs. fillet or other edge-modification tools. The when-to-use guidance is only implied by the tool name and 'bevel' verb, not explicit.

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

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

Annotations contain only the title, so the description carries the full burden of behavioral disclosure. It does not mention that this tool creates a feature (mutates the document), any permission requirements, or postconditions. For a feature-creation operation, this is a significant gap.

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

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

The description is extremely concise (one sentence) and front-loaded with the action, but it is under-specified for a tool with 12 parameters. It is not verbose, yet it lacks any structural breakdown or additional context that would justify its brevity.

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 complex tool with 12 parameters, no output schema, and no behavioral annotations, the description is far from complete. It does not explain how parameters relate (e.g., axis query syntax), prerequisites, or typical usage scenarios. The schema provides parameter details but the description fails to tie them together.

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

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

Schema description coverage is 100%, with each of the 12 parameters having a description. The tool description adds no parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description 'Repeat geometry around an axis' clearly identifies the verb (repeat), the resource (geometry), and the distinguishing axis concept. This differentiates it from siblings like onshape_linear_pattern (linear translation) and onshape_mirror (reflection). The purpose is unambiguous and specific.

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

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

No guidance is provided on when to use this tool versus alternatives such as onshape_linear_pattern or onshape_mirror. The description only states what it does, leaving the agent to infer appropriate use cases from the name and schema.

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 readOnlyHint=true; the description adds real behavioral context by defining what a 0 result means (touch or overlap) and by disclosing the return payload (inches and millimetres, closest point on each body). It leaves error behavior for a missing or ambiguous body reference unstated, which keeps it off 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?

Three sentences, front-loaded with the core measurement semantics, then the zero-case interpretation, then the return format. The bracket/servo example is short and materially illustrates the interference use case rather than padding.

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

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

With no output schema, the description correctly takes on return-value disclosure — units, closest points, and the clear flag — and states the same-Part-Studio scope constraint. A read-only, fully-schema'd tool needs little more; only failure modes are omitted.

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

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

Schema description coverage is 100% and the nested a/b objects already document 'give exactly one of part or feature', so the description's restatement of that naming scheme adds reinforcement rather than new meaning. Baseline 3 is correct when the schema carries the parameter burden.

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 — minimum distance between two solid bodies in the same Part Studio — and pins the body identification scheme (part id or creating feature). This cleanly separates it from onshape_measure (generic measurement), onshape_mass_properties, and onshape_get_body_details without needing to open any schema.

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

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

Explicitly frames the tool as the interference check and gives a concrete use case (a bracket against a dummy servo body), plus the same-Part-Studio precondition. It stops short of naming when to prefer the sibling onshape_measure instead, so there is no true when-not 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?

Annotations provide only a title, so the description carries the full behavioral disclosure burden. It does state the side effect: adding an assembly tab to a workspace. However, it does not disclose what happens on success, whether duplicate names are handled, failure conditions, or prerequisites for the workspace/document.

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 one efficient sentence with a clear verb, object, and target location. It is front-loaded and contains no filler or redundant restatement of the schema.

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

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

For a simple creation action with fully documented parameters, the description is minimally viable. It does not mention return values, error behavior, or when this tool should be chosen over similar creation tools, so an agent gets the gist but not full operational context.

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

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

Schema description coverage is 100%: all three parameters (doc, ws, name) already have descriptions. The tool description adds little parameter-level meaning beyond the schema, which matches the baseline expectation for high schema coverage.

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 and object: 'Add an assembly tab to a workspace.' It clearly identifies the operation and target resource. It does not explicitly differentiate itself from siblings like onshape_create_part_studio or onshape_create_document, but the assembly-tab scope makes the purpose reasonably 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?

No guidance is given about when to use this tool versus alternatives. It does not mention related tools such as onshape_create_part_studio, onshape_get_assembly, or onshape_insert_instance, nor does it give conditions or exclusions. The only usage signal is implied by the tool's name and the one-line description.

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

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

No substantive annotations exist beyond the title, so the description carries the burden. It discloses that creation is performed, that free accounts are restricted to public documents, and that the result includes the new document id and default workspace id. It does not mention authentication requirements or broader side effects, but the disclosed result details go beyond the schema.

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

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

Two sentences, no filler. The core action is front-loaded, the free-account caveat directly affects a parameter choice, and the return-value note is placed at the end where it naturally completes the description.

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 there is no output schema, the description usefully tells the agent that the response contains the document id and default workspace id. The tool is simple, has only one required parameter, and the description covers the main call requirement. Minor gaps such as clarifying the default visibility for paid accounts are not critical.

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

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

Schema description coverage is 100%, so the baseline applies. The description adds a small amount of parameter context by clarifying that free accounts must pass public=true, but this largely restates the schema's 'required on free accounts' note. It adds no meaningful semantics for name or description.

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

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

The description states a specific verb and resource — 'Create a document' — and adds context about free-account public visibility and the returned id/workspace id. This clearly differentiates it from sibling tools like onshape_list_documents, onshape_get_document, onshape_update_document, and onshape_delete_document.

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

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

The description implies its use case ('Create a document') and provides account-specific guidance for when public=true is needed. However, it does not explicitly contrast this tool with alternatives such as onshape_update_document or onshape_create_part_studio, so the agent must infer the boundary from sibling names.

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

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

Annotations are minimal (only a title), so the description carries the full burden of behavioral disclosure. It mentions the version requirement, which is a key constraint, but does not describe side effects (e.g., creating a new element), permission needs, or return values. For a mutation tool with no other safety hints, this is a partial gap.

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

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

Two sentences: the first states the purpose, the second gives the critical usage instruction. No fluff, fully front-loaded. Every word earns its place.

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

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

With 7 parameters and no output schema, the description covers the essential prerequisite but omits what the tool returns (e.g., the new drawing element id) and any post-creation steps. An agent would need additional context to know how to use the result. Given the tool's complexity and minimal annotations, this is a noticeable gap.

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

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

Schema coverage is 100% with each parameter described, so the baseline is 3. The description adds value by clarifying that src_version must come from onshape_create_version, which is a dependency not evident from the schema alone. This goes beyond the schema's individual parameter descriptions, earning a 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?

The description clearly states the action ('Create a drawing') and the resource types (part, Part Studio or assembly). It distinguishes this tool from sibling creation tools like onshape_create_document or onshape_create_part_studio by its specific resource focus. The additional note about version reference adds specificity without ambiguity.

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

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

Explicitly instructs the agent to call onshape_create_version first and pass its id as src_version. This provides a clear prerequisite and a direct call sequence, leaving no room for misinterpretation. It also implicitly states when to use this tool: whenever a drawing is needed from a versioned source.

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 provide no behavioral hints (no readOnly/destructive flags). The description mentions 'Add' implying a mutation, but does not disclose permissions, side effects, idempotency, or what happens on success. With no annotation coverage, the description fails to inform the agent about expected behavior beyond the basic operation.

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

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

The description is a single, direct sentence with no filler. It front-loads the action and resource, making it immediately scannable and appropriately sized for the tool's simplicity.

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?

This is a simple create tool with three required parameters and no output schema, but the description offers no information about return values, potential errors, or necessary prerequisites. Given the lack of annotations and behavioral disclosure, the tool feels under-specified for an agent that needs to know what to expect after 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 100%, so the baseline is 3. The description adds no additional meaning for the parameters (doc, ws, name) beyond what the schema already documents. No extra context is provided to enrich parameter understanding.

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 'Add' and names the resource 'Feature Studio tab' along with its purpose 'custom FeatureScript'. It clearly distinguishes this create tool from sibling get/set feature studio tools without needing to reference them.

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

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

The description implies usage — you use this tool to create a feature studio — but does not explicitly state when to choose it over alternatives like onshape_get_feature_studio or onshape_set_feature_studio. There is no exclusion or alternative routing, which limits 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 readOnly/destructive annotations, the description carries the behavioral disclosure burden. 'Add' clearly signals a mutating operation, and 'The new element id is at result.response.id' usefully states where the result appears. However, it does not mention permissions, failure behavior, or any workspace-level side effects beyond adding the tab.

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 two short sentences with no filler: the first states the core action and target, and the second gives the key output location. It is front-loaded, scannable, and every sentence earns its place.

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

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

For a simple tool with three fully documented required parameters)Skip, the description and schema cover the essential invocation details, and the response-location note helps the agent use the result. It could mention that the document/workspace must already exist or explicitly note that this creates a new tab rather than modifying an existing one, but the definition is largely complete.

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

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

The input schema documents all three parameters with clear descriptions, including the exact URL context for doc and ws, so schema coverage is 100%. The tool description itself adds no additional parameter detail, but none is required because the schema already provides sufficient 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?

The description 'Add a Part Studio tab to a workspace' uses a specific verb and resource, and clearly identifies the operation as creating an element inside an existing workspace. This distinguishes it from sibling creation tools such as onshape_create_assembly or onshape_create_document.

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 'to a workspace' implies that the tool is used when adding a Part Studio tab to an existing document/workspace, but there is no explicit guidance about when to choose this over sibling tools or what prerequisites must be satisfied. Usage is primarily inferred from the name and one-line description.

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

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

Annotations provide no read-only or destructive hints, so the description carries the behavioral burden. It clearly indicates that the tool creates/adds a sketch and adds the useful closed-profile constraint, but it does not disclose side effects like feature-tree insertion, error behavior, or what happens with an open profile. This is adequate 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?

Three short sentences with no filler. The core purpose is front-loaded, the usage condition is stated next, and the extrusion tip is a practical final note. Every sentence earns its place.

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

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

The schema fully documents all 8 parameters, and the description covers tool selection plus a critical geometric constraint. It lacks explicit return/error information, but with no output schema and a fully covered input schema, the essential invocation context is present enough for an agent to proceed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema by emphasizing that the profile should be closed if extruding and by implicitly framing entities as the core payload. It does not need to repeat parameter details the schema already documents.

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 action and resource: "Add a sketch from a list of entities: lines, circles, rectangles and arcs." It also distinguishes this tool from "single-shape sketch tools," so an agent can immediately tell it apart from onshape_sketch_line, onshape_sketch_circle, and onshape_sketch_rectangle.

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

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

The description gives explicit selection guidance: "Use this when the single-shape sketch tools cannot express the profile." It also adds a conditional follow-up instruction about closing the profile before extruding, which helps the agent use the tool correctly in a downstream workflow.

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 readOnly or destructive hints in annotations, the description carries the full burden of behavioral disclosure. It transparently states the result (immutable version) and its implications (only way back, drawings require version). While it doesn't cover permissions or return format, it provides meaningful behavioral context beyond the tool name.

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

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

Two sentences with zero wasted words. The primary action is front-loaded, followed by the critical usage guidance. Every word earns its place, and the structure prioritizes the most decision-relevant information first.

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

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

For a create operation with no output schema, the description adequately explains the action, its consequence (immutability), and when to use it. It lacks details on return value or potential errors, but those are less critical for a straightforward creation tool with well-documented parameters. The context is sufficient for an agent to invoke it correctly.

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

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

Schema documentation covers all 4 parameters at 100% coverage, so the schema already explains each field. The description adds no parameter-specific details beyond what's in the schema, maintaining the baseline 3. It does hint at the purpose of 'name' via 'what is about to change' in the schema, but the description itself offers no additional parameter semantics.

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

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

The description clearly states a specific action ('Snapshot the workspace as an immutable version') and the resource (workspace). It also conveys the purpose (creating a safe, immutable checkpoint) and distinguishes it from other version-related operations by emphasizing immutability and its role as the only way back.

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?

Explicitly tells the agent when to use this tool: 'Do this before restructuring an existing design'. It explains the rationale ('only way back' and 'drawings must reference a version'), giving clear contextual guidance on when this tool is appropriate versus alternatives.

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

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

The annotation already declares destructiveHint=true, so the description isn't required to establish that this mutates state. It does add genuinely new behavioral information beyond the annotation: "Relations on a deleted mate stop solving," which discloses a cross-entity side effect an agent could not infer from the schema. It stops short of addressing irreversibility/undo or permission requirements.

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

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

Two short sentences with zero filler: the scope list comes first and the side-effect caveat second. Nothing is redundant with the title or restates the tool name.

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

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

For a destructive mutation with no output schema, the description covers what is removed and one downstream consequence, with annotations covering the safety profile and the schema covering all inputs. However, it omits whether deletion is permanent/undoable and whether dependent mates or instances are also affected — meaningful gaps for a delete tool.

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

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

Schema description coverage is 100% (all four params, including URL-segment guidance for doc/ws/elem and the meaning of feature_id), so the schema fully carries parameter semantics and the baseline applies. The description adds no parameter-level detail beyond what the schema already explains.

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

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

States a specific verb ("Remove") and enumerates the exact resource types it operates on (mate, mate connector, group, relation), which makes clear this is an assembly-level deletion rather than a part-studio feature deletion. It never explicitly contrasts itself with siblings like onshape_delete_feature or onshape_delete_element, but the entity list does most of that work implicitly.

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

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

Usage is only implied by the entity list — an agent can infer this is the tool for removing assembly mates/groups/relations, but there is no explicit "use this when…" or exclusion against onshape_delete_feature, onshape_delete_instance, or onshape_update_assembly_feature. No preconditions (e.g., mate must exist, assembly must not be locked) 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?

The annotations already supply destructiveHint=true, and the description adds meaningful context by clarifying that deletion means moving to trash rather than permanent destruction, and that the entire document is affected. This goes beyond the annotation without contradicting it.

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 carry all essential information with no filler. The deletion behavior is stated first, and the scoping clarification is front-loaded immediately afterward.

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

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

For a one-parameter tool with a destructive annotation, the description is complete: it names the action, the target scope, and the non-tab exclusion. No return format is needed for a simple delete operation, and no additional prerequisites or side effects are necessary 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 100%, so the single 'doc' parameter is fully documented in the schema. The description does not add new meaning to the parameter itself, so the baseline score of 3 is appropriate.

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

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

The description names a specific action ('Move a document to the trash') and a specific resource ('a document'), and immediately distinguishes itself from tab-level operations with 'not a single tab.' This makes the tool's purpose unmistakable and separates it from siblings like onshape_delete_element.

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 'affects the whole document, not a single tab' provides a clear exclusion boundary: use this only for whole documents, not individual elements. It does not explicitly name an alternative tool such as onshape_delete_element, but the when-not condition is clear.

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

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

The description adds no behavioral context beyond the destructiveHint annotation. It does not mention irreversibility, potential impact on dependent features, or any side effects. Since the annotation already signals destructiveness, the description contributes nothing extra.

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

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

The description is a single, tightly worded sentence that front-loads the action and object. Every word earns its place, and there is no redundancy or filler.

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

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

For a simple delete operation with three fully documented parameters and no output schema, the description is minimal but adequate. It does not mention potential errors or permission requirements, but the destructiveHint annotation covers the primary caveat, and the schema covers the inputs.

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

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

Schema coverage is 100% with each parameter (doc, ws, elem) having a descriptive comment. The tool description does not add further meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

The description states a clear verb ('delete') and specific resource ('element (tab)'), which distinguishes it from sibling tools like onshape_delete_document and onshape_delete_feature. The parenthetical clarifies the exact entity type, leaving no ambiguity about what is being removed.

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

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

The description offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., being in a workspace, having edit permissions). It simply states the action without contextual routing.

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

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

The destructiveHint annotation already flags that this operation is destructive. The description adds a valuable behavioral warning: features added after the deleted one may fail to regenerate. This goes beyond the annotation and informs the agent of downstream consequences.

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 deliver the core action and the most important risk in a front-loaded, efficient way. There is no filler or redundant restating of the tool name.

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

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

For a destructive single-feature deletion, the description provides the essential target and consequence. It does not explain return behavior or mention irreversibility explicitly, but the destructive annotation and regeneration warning cover the main context an agent needs.

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?

All four parameters are fully documented in the schema with clear descriptions, so the baseline is 3. The tool description adds no parameter-specific meaning beyond the schema, but none is needed because schema coverage is 100%.

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 action ('Remove one feature') and a clear resource ('from the tree'), so an agent knows exactly what this tool does. It is naturally distinguished from siblings like update_feature and add_feature by the delete semantics.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives such as delete_element or update_feature. It implies the use case by describing the action, but it does not state prerequisites, exclusions, or when a different tool would be more appropriate.

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

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

Annotations already declare destructiveHint=true, so the description is not required to repeat destructiveness. However, it adds no additional behavioral context—such as irreversibility, effects on sub-assemblies, or required permissions—beyond what the annotation provides. It also leaves ambiguity about the scope of the deletion (e.g., does it cascade to child instances?).

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

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

The description is a single, front-loaded sentence that directly states the action and target. There is no fluff, and every word contributes to the meaning, making it highly concise and efficient.

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

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

For a simple delete operation with all parameters fully described in the schema, the description provides sufficient context—the action and the key identifier. It does not explain return values or error handling, but no output schema exists, and the description clarifies that the node is an occurrence node id, which is the critical detail. It is adequate for an agent to correctly invoke the tool.

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

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

The schema provides descriptions for all four parameters (doc, ws, elem, node) with full coverage. The description reiterates the role of 'node' (occurrence node id) but adds no syntax, format, or additional meaning beyond what the schema already specifies. Baseline 3 is appropriate given high schema coverage.

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 ('Remove'), a specific resource ('instance from an assembly'), and the key input ('occurrence node id'). This clearly differentiates it from sibling delete tools like onshape_delete_feature or onshape_delete_document, making the purpose unambiguous.

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

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

The description implies usage context by mentioning 'assembly', but it does not explicitly state when to use this tool versus alternatives (e.g., delete_feature for features, delete_document for documents). An agent must infer the appropriate scenario from the name and context rather than receiving direct routing 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?

Annotations provide no behavioral hints, so the description carries the burden. It does disclose the core geometric behavior and taper direction. However, it does not mention that this is a model-mutating feature addition, potential failure behavior, or validation implications beyond what the schema's 'validate' parameter implies.

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 states the operation and its typical use case with zero filler. The explanation is compact and easy to parse before considering parameters.

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

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

With no output schema and only a title annotation, the description carries significant context burden. It explains the geometric purpose but omits side effects, failure modes, and explicit selection guidance for the required FeatureScript queries, leaving part of the operational context to be inferred.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters. The description adds little beyond the phrase 'away from a neutral plane', which helps interpret 'neutral' and 'faces', but it does not go beyond the schema baseline.

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 pair: 'Taper faces away from a neutral plane'. This clearly identifies the draft feature and differentiates it from sibling operations like chamfer, fillet, or shell. The molded/cast context reinforces the geometric intent.

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 'the usual requirement for moulded or cast parts' gives clear context for when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the use case is specific enough for an agent to route correctly.

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

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

With no annotation hints (readOnly, destructive, etc.), the description carries the burden of behavioral disclosure. It states the tool produces an encoded string, but doesn't mention any side effects, error behavior, or whether it's a pure transformation. For a simple encoding utility, this is adequate but not rich; it could mention that it has no side effects.

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

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

The description is a single, clear sentence with no wasted words. It front-loads the action ('Turn... into...') and immediately communicates the output's purpose. Perfectly concise for a simple utility.

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 straightforward encoding tool, the description covers the essential purpose. It doesn't describe the exact format of the encoded string or any constraints, but given the tool's simplicity and other context (schema covers parameters), it's sufficiently complete. No output schema exists, but the return value is implied as an encoded string.

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

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

Schema description coverage is 100%, so all parameters are documented in the input schema. The description does not add extra meaning beyond what the schema provides; it generically refers to 'configuration parameter values' without specific details. With high schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the tool's function: converting configuration parameter values into an encoded string used by other tools. It identifies the resource (configuration) and the specific action (encode), and distinguishes itself from sibling tools like onshape_get_configuration by noting it produces a string others accept.

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

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

The description implies when to use it: when you need to provide a `configuration` string to other tools. It doesn't explicitly name alternatives or say when not to use it, but the context of 'other tools accept' gives clear guidance. No exclusions are stated, but the purpose is evident.

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 behavioral annotations besides a title, the description carries the burden of disclosure. It does clarify that the tool returns a decoded value (or raw response via the 'raw' parameter) and frames the operation as inspection, which suggests it is non-mutating. However, it does not explicitly guarantee no side effects on the document or mention required permissions, which would be valuable for an arbitrary-code evaluation 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 description is two efficient sentences with the purpose, the general-use context, and the required script signature all front-loaded. It contains no filler, though it could slightly improve structure by separating the signature example more clearly.

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 description covers the basics: what the script should look like, where it runs, and what kind of output to expect. However, with no output schema and no annotations, it leaves gaps around return value types, error behavior, whether evaluation can have side effects, and common usage patterns—significant for an advanced, open-ended evaluation tool.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the exact function signature 'function(context is Context, queries) { ... }', but this largely restates the script parameter's schema description ('function expression taking (context, queries)'). Thus the description provides no substantial parameter meaning beyond the schema.

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

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

The description states a specific action ('Run a FeatureScript function'), identifies the target resource ('against the Part Studio'), and explains the result ('return its decoded value'). It also brands itself as 'the general-purpose way to inspect geometry,' which differentiates it from the many specific feature-creation and inspection siblings.

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

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

'The general-purpose way to inspect geometry' implies this is the fallback tool when no dedicated sibling applies, but it never explicitly says when to prefer it or when to avoid it. The usage guidance is implied rather than stated as direct selection criteria or exclusions.

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

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

The description adds meaningful behavioral context beyond the sparse title-only annotation: exports are handled by a server-side translation service and are queued, making them slower than STL. This warns the agent about latency and async behavior. It does not mention return values or side effects, but the disclosed queuing trait is genuinely useful.

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 deliver the core purpose, supported formats, and a key behavioral caveat with no filler. The format list is front-loaded and the latency note is placed after the main purpose, making the description easy to scan.

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 with seven parameters and no output schema, the description covers the essential purpose and latency behavior, and the schema covers parameter semantics. However, it does not explain what the tool returns (e.g., a job status, output path, or confirmation), which the agent would need since no output schema is present.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including doc/ws/elem and format examples. The description's format list mostly duplicates the schema's format example and adds no additional parameter-level detail or constraints, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Export through Onshape's translation service') and enumerates the relevant formats (STEP, IGES, 3MF, PARASOLID, SOLIDWORKS). It also distinguishes itself from the STL export path by explicitly noting that this path is slower, which helps an agent separate it from the onshape_export_stl 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?

The description gives clear usage context by listing supported CAD formats and contrasting the queued translation service with STL. It does not explicitly name onshape_export_stl as the alternative for STL exports, but the comparison is concrete enough for an agent to infer the appropriate selection.

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

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

Annotations only provide a title, so the description carries most of the behavioral burden. It adds useful context by mentioning formats and the translation service, but it does not disclose whether a file is written locally, what the response contains, or whether the operation is non-destructive.

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

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

A single, front-loaded sentence that communicates purpose and formats without any filler. Every word earns its place.

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

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

With no output schema and no behavioral annotations, the agent is not told what happens after the export is requested: whether a file is returned, written to the output path, or whether translation is asynchronous. Parameter documentation is complete, but post-invocation behavior is missing.

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

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

Schema coverage is 100% and all parameters already have descriptions well beyond the tool description. The description only repeats the format options already present in the schema, adding no new parameter-level insight.

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

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

The description states a specific verb and resource: 'Export a drawing' as PDF, DWG, or DXF through the translation service. This clearly distinguishes it from sibling tools like onshape_export_stl and generic onshape_export.

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

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

No guidance is given about when to use this tool versus alternatives. Sibling tools such as onshape_export_stl and onshape_export exist, but the description does not mention them or provide 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 carry only a title, so the description carries the behavioral burden. It usefully explains that STL is unitless and that millimetres match slicer assumptions, but says nothing about file-writing side effects (overwrite behavior of `out`, partial-write failure) or auth requirements for a tool that produces a file on disk.

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 with zero padding; the format and unit default are front-loaded. The closing line 'Measure the model before exporting it' is advice rather than an instruction about this tool and is slightly cryptic, but it is compact.

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?

Eight parameters with 3 required, no output schema and no safety annotations — the description covers the one parameter with real semantic ambiguity (units) and the tool's purpose. It leaves resolution/ascii/configuration guidance and the shape of the return value unexplained, which is acceptable given the full schema coverage but not ideal for an 8-parameter tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the semantics of `units` beyond the enum and default — why millimetres is the safe choice and when a consumer would want otherwise. The remaining parameters (resolution, ascii, configuration) get no added meaning in 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?

States a specific verb and resource plus the output format: 'Export the Part Studio as STL'. This distinguishes it in practice from onshape_export_drawing and the generic onshape_export, though it never names those siblings explicitly.

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

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

Gives a conditional rule for the `units` parameter ('only change `units` if the consumer expects otherwise') and an advisory to measure first, which implies calling onshape_measure. It offers no explicit when-not guidance and never points to an alternative export tool for non-STL needs.

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 carry only a title, so the description bears full behavioral burden. It does usefully disclose that REMOVE cuts existing bodies and INTERSECT keeps overlap, which signals destructive potential. However, it never says the call appends a feature to the tree, that it mutates the Part Studio, or what is returned (feature id?) for chaining.

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

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

Three tight sentences: operation first, then the op enum semantics, then the direction/depth knobs. No filler, no repetition, front-loaded with the core action.

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

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

For an 11-parameter mutation tool with full schema coverage and no output schema, the description covers the two semantically weighty enums well. The remaining gap is the return value and the Part Studio context requirement, which is minor given how complete the schema is.

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

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

Schema description coverage is 100%, so every parameter including the op and end_type enums is already fully documented, and the description largely restates the op enum plus a compressed end_type gloss. It adds no syntax, units, or default detail beyond the schema, so the baseline of 3 applies.

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

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

The opening sentence names a specific CAD operation and its exact input/output: 'Extrude the closed regions of a sketch into a solid'. It is unambiguous against siblings like onshape_revolve or onshape_sweep, though it never explicitly names an alternative to route away from.

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?

Explaining what NEW/ADD/REMOVE/INTERSECT do implicitly tells the agent which mode to pick for a given modeling intent, but there is no explicit when-to-use guidance, no prerequisites (sketch must contain closed regions, must live in the same Part Studio as `elem`), and no routing to onshape_boolean for subtractive work.

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 provide only a title, so the description carries the full burden of behavioral disclosure. It states the action ('Round the selected edges') but does not mention that this creates or modifies a feature, implies write access, or describe any side effects or validation behavior. This is similar to the 'update_drive' example—mutation is implied but not elaborated.

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 two sentences with no fluff. The core purpose is front-loaded, and the edge-selection options are listed compactly. It is efficient and scannable, though the phrase 'Name the edges' is slightly unusual, it does not waste words.

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

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

With 13 parameters, no output schema, and sparse annotations, this tool is complex, yet the description only addresses edge selection. It omits context about radius, type, validation, and the overall feature-creation workflow. An agent has to rely entirely on the schema for everything except edge selection, leaving significant gaps in understanding how to call the tool effectively.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a minor but useful clarification that the edge selection parameters (edges, query, feature, all, circular) are mutually exclusive alternatives, which the schema does not explicitly state. However, it does not expand on any parameter beyond what the schema already describes, so it only marginally exceeds the baseline.

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

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

The description opens with 'Round the selected edges,' which is a clear verb+resource statement that unambiguously conveys the tool's purpose of filleting edges. It distinguishes from the sibling onshape_chamfer by using 'round' instead of 'bevel.' However, it doesn't explicitly name the sibling or contrast with it, so it stops short of strong 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?

The description implies the tool is for rounding edges but gives no explicit guidance on when to choose it over alternatives like onshape_chamfer or onshape_shell. No exclusions or alternative tool mentions are present. The edge-selection instructions are about how to pick edges, not about when to use the tool.

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, so the safety profile is covered; the description adds the useful specifics that centres are reported in inches and that the radius filter is optional. It still doesn't say what identifying info accompanies each centre (edge id, radius value) or how the tolerance affects 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?

A single dense sentence that front-loads the resource and the radius-filter qualifier, with the use cases trailing as motivation. Efficient, though the stacked parenthetical and em-dash clause makes it slightly harder to scan than a two-clause form would.

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 the return shape, and it only partly does: centres in inches, radius filtering. It omits whether radii, edge ids or counts are returned, which an agent needs to chain this into a fillet 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 coverage is 100%, so all five parameters, their units and the tolerance default are already documented in the schema. The description only restates the radius filter, adding nothing beyond the schema — baseline 3 is correct here.

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

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

States a specific verb+resource — find circular edges, full circles and arcs — and the returned content (each edge's centre in inches). It doesn't name sibling tools like onshape_get_edges or onshape_find_edges_by_feature, so the boundary is inferred from the word 'circular' rather than stated.

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

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

It hints at the two main use cases (picking hole rims to fillet, checking hole locations), which implies when to reach for it. But it never says when to use onshape_get_edges or onshape_find_edges_by_feature instead, nor any prerequisites for the doc/ws/elem identifiers.

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

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

The description adds 'deterministic ids' and 'evaluated by Onshape,' which go beyond the readOnlyHint annotation by implying the output is stable and computed server-side. This is useful context for an agent. No contradictions with annotations are present.

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 one concise sentence that immediately conveys the core purpose. It is front-loaded with the key information and contains no filler.

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

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

For a simple read-only query with four well-documented parameters and no output schema, the description fully explains what the tool returns (edge ids) and how it operates. An agent has enough information to call it correctly without additional context.

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

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

Schema coverage is 100%, and each parameter has a description. The tool description adds no additional parameter semantics beyond the schema. The 'feature' parameter is already explained in the schema as 'Feature id whose edges you want.' Baseline 3 is appropriate given full schema coverage.

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 edges created by a feature. It is specific and distinct from siblings like onshape_get_edges or onshape_find_circular_edges because it explicitly ties edges to the feature that created them. The phrase 'deterministic ids' also adds precision about the output nature.

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

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

No guidance is given on when to use this tool versus alternatives such as onshape_get_edges or onshape_find_circular_edges. The description does not mention when this tool is preferred or when to avoid it. The usage context is only implied by the name and description.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the workspace scope and filtering behavior, but does not disclose return format, pagination, or failure behavior; for a simple list tool this is acceptable 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?

A single front-loaded sentence with no fluff; it states the action, scope, and optional behavior in a compact way.

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 read-only list tool, the description plus fully covered schema and readOnlyHint give an agent everything needed to call it appropriately. No output schema is present, but 'List' reasonably implies the return value.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds little semantic value beyond the schema, simply restating workspace scope and substring filtering.

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 ('List') and resource ('Part Studios'), and scopes it to a workspace with an optional name-substring filter. This makes it clearly distinct from general element listing and part-listing siblings.

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

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

It states the context clearly: use it to list Part Studios in a given workspace, optionally filtered by a name substring. It does not explicitly name alternatives or exclusion conditions, but the use case is unambiguous.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description is consistent with that. The description adds the content scope (instances, occurrences, mate features, connectors) but does not disclose any additional behavioral traits such as output size, no-return-value cases, or performance characteristics. With annotations covering the safety profile, this is adequate 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 description is very short and free of fluff, and the key returned content is listed compactly. It is under-specified as a sentence fragment but appropriately sized for a simple read-only assembly-structure tool.

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

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

For a read-only tool with complete parameter schema coverage, the description lists the main content of the result, partially compensating for the absent output schema. However, it does not explain how the include_* flags affect the result, whether the response is nested/hierarchical, or how occurrences relate to instances, which an agent might need for correct interpretation.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including defaults. The description repeats some concepts (mate features, mate connectors) but adds no parameter-level meaning beyond what the schema provides. Baseline 3 applies.

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

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

The title 'Get assembly structure' provides the verb and resource, and the description lists the specific components (instances, occurrences, mate features, mate connectors) that the tool returns. It is clear what the tool does, though the description itself is a noun fragment and does not explicitly differentiate itself from sibling tools like onshape_get_assembly_features.

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

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

No guidance is given about when to use this tool versus alternatives such as onshape_get_assembly_features, onshape_get_bom, or onshape_get_parts. The agent is left to infer the use case from the tool name and description.

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

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

readOnlyHint=true already declares the safety profile, and the description adds value by disclosing what is returned — feature ids, payloads and regeneration states — which goes beyond the annotation. It stops short of describing shape, pagination or ordering, but that is a minor gap for a read-only listing.

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 zero filler, front-loading the resource enumeration before the returned fields. It reads as a noun fragment rather than a full statement of action, a small structural weakness but nothing wasted.

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

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

For a read-only, three-parameter listing tool with full schema coverage and no output schema, the description supplies the return contents an agent needs to decide relevance. It could say a bit more about what 'payloads' and 'regeneration states' contain, but the essentials are present.

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

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

Schema coverage is 100% with all three identifiers (doc, ws, elem) documented in the schema, so the baseline of 3 applies. The description adds no additional meaning about how these identifiers are used or whether they can be defaulted.

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 exact resource set — mates, mate connectors, groups and relations in an assembly — which clearly distinguishes it from generic siblings like onshape_get_features or onshape_get_assembly. The verb is implied rather than stated (the title supplies 'List'), but the scope is unambiguous.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as onshape_get_assembly, onshape_get_mate_values, or onshape_get_features. An agent must infer from the noun list alone that this is the tool for inspecting existing assembly mating structure.

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

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

The description adds the deterministic nature of IDs, which is useful context beyond the readOnlyHint annotation. However, it does not disclose other behavioral details such as response structure or limits, and the annotation already covers safety.

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

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

The description is a single, focused sentence that conveys the essential function and a key attribute (deterministic IDs) without waste. It is front-loaded and easy to parse.

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 retrieval tool with three well-documented parameters and no output schema, the description provides the essential context: what is returned and why it is useful. It is sufficient for an agent to understand the tool's role, though it could benefit from a note on how the IDs are structured.

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

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

The input schema has 100% description coverage, so all three parameters are documented. The description adds no parameter-specific information beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description clearly states the resource (bodies, faces, edges) and the purpose (providing deterministic IDs for explicit edge selection). It is specific and distinguishes this tool from a generic 'get' operation, though it does not explicitly name sibling 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?

The phrase 'the source for explicit edge selection' implies a use case but does not explicitly mention when to use this tool versus alternatives like onshape_get_edges or onshape_find_edges_by_feature. There is no clear when-not-to-use 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?

The annotations provide readOnlyHint=true, so the safe-read behavior is already known. The description adds only that the result is an assembly BOM table, and does not disclose return format, how indented or multi_level affect output, or any other behavioral details. No contradiction exists, but no additional behavioral context is provided either.

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

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

The description is a single short sentence with no filler and the key subject ('BOM table') is front-loaded. It earns its place, though it is minimal enough that it cannot carry much explanatory weight on its own.

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 would need to convey more about what an agent can expect from the tool. It does not mention when to use it, what the returned BOM table contains, or how the boolean parameters change the result. For a five-parameter, read-only retrieval tool, this leaves meaningful gaps.

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

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

Schema description coverage is 100%, and the schema already documents document/workspace/element IDs plus the two boolean options and their defaults. The description adds no extra parameter meaning beyond the assembly context, so the baseline of 3 is appropriate.

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

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

The title and description together identify a clear resource: the assembly's bill of materials. 'BOM table' is specific enough to distinguish this tool from the many sibling tools, none of which target BOM data. However, the description itself is a noun phrase rather than a full verb statement, so it relies on the title for the action.

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

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

No guidance is given for when to use this tool versus alternatives such as onshape_get_assembly or onshape_get_parts. The intended context is only implied by the word 'assembly', with no exclusions or 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 already declare readOnlyHint=true, and the description confirms a read-only retrieval by describing what is returned. It adds value by specifying the return content (ids and allowed values), but does not disclose other behavioral aspects such as error conditions or configuration applicability. No contradiction with annotations.

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

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

A single, concise sentence that front-loads the core concept with no wasted words. It efficiently states what the tool returns.

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 read-only getter with fully documented parameters and a readOnly annotation, the description adequately explains the return content. Given no output schema, it could be slightly more explicit about the response structure, but it meets the essential needs.

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

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

The input schema provides 100% description coverage for all three parameters, so the tool description adds no additional parameter-level meaning. Baseline 3 applies.

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

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

The description clearly identifies the resource (configuration parameters of an element) and the kind of information returned (ids and allowed values). It is distinct enough from siblings like onshape_encode_configuration, though it does not explicitly differentiate itself 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?

No guidance is given on when to use this tool versus alternatives such as onshape_encode_configuration or onshape_get_features. The purpose implies a use case, but there is no explicit context, prerequisites, or exclusions.

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

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

The readOnlyHint annotation already establishes this as a safe read operation, and the description is consistent with that. It adds a small behavioral detail—returned metadata includes the default workspace id—but it does not disclose error behavior or authentication requirements; this is acceptable for a simple read annotated as read-only.

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

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

The description is one short sentence, front-loaded with the verb 'Read', and contains no filler or repeated information from the title.

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?

This is a simple one-parameter read operation with a fully documented schema and a read-only annotation. The description is largely sufficient for invocation, though because there is no output schema, the return value is only vaguely described as 'metadata' plus one field.

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

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

The single required parameter 'doc' is already fully described in the schema with a URL template, so schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific action—'Read'—and a specific resource—'one document's metadata'—and adds a concrete returned field ('default workspace id'). It is clear enough, but it does not explicitly differentiate itself from the sibling onshape_get_document_summary.

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

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

No guidance is given on when to use this tool instead of list_documents, search_documents, or get_document_summary. The only hint is 'one document', which weakly implies a single-document lookup.

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 provide readOnlyHint=true; the description adds meaningful behavior by stating it returns the full workspace/tab tree, not just one slice. It does not discuss response size or rate limits, but for a read-only aggregate tool those are minor gaps.

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 states the return content and the value proposition with no filler. Every clause earns its place.

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

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

With one fully documented parameter, a read-only annotation, and no output schema, the description still tells the agent what will be returned (metadata, workspaces, elements, ids) and when to use it. Nothing necessary for invoking it correctly is missing.

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

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

Schema coverage is 100%, and the schema's doc description already gives the URL format and required semantics. The tool description only repeats that the tool collects ids; it adds no new parameter-level information, so the baseline 3 applies.

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

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

The description names a specific verb ('summarize'), resource ('document'), and the exact payload: metadata plus every workspace and the elements inside each. This clearly differentiates it from sibling tools like get_document, get_workspaces, and get_elements, which cover only a slice of that aggregate.

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 an explicit use case: 'the fastest way to orient in an unfamiliar document and collect the ids other tools need.' It does not name alternative tools or say when not to use it, so it stops short of full routing 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?

The readOnlyHint annotation already covers the read-only safety profile. The description adds the scoping detail that views are those 'placed on a drawing sheet,' but it does not disclose return format, pagination, or how sheets are handled. This is a minor gap given the annotation exists.

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

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

The description is a single short phrase with no filler, and the drawing-sheet scoping is front-loaded. It is efficient, though the noun-phrase form is less informative than a proper verb-first instruction.

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 read-only listing with fully documented parameters and a readOnly annotation, the definition is minimally sufficient: an agent knows what to call and what high-level result to expect. The lack of an output schema and any note about multiple drawing sheets or return structure leaves some ambiguity, but it is not blocking.

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 description adds no parameter-level meaning, but the input schema has 100% coverage with clear explanations for doc, ws, and elem as URL segments. With full schema coverage, the schema carries the parameter-semantics burden, so the baseline 3 applies.

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

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

The title 'List drawing views' supplies a specific verb and resource, and the description clarifies the scope as 'views placed on a drawing sheet.' This is reasonably distinct from sibling element/feature listing tools, though the description itself is a noun phrase and does not explicitly name an action.

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

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

The title and description imply the tool should be used when an agent needs the views on a drawing sheet. However, it does not state when not to use it, mention prerequisites, or reference alternatives among the sibling 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?

readOnlyHint=true already declares the safety profile, so the description's job is to add context — which it partly does by disclosing units (inches) and the deterministic nature of edge ids. It says nothing about scope limits (body visibility, suppressed bodies), pagination, or what happens on a non-part-studio element.

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 that front-loads the scope ('every edge of every solid body') before the payload description. Zero filler.

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

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

With no output schema, the description must describe returns, and it does — id, owning body, type, plus radius/centre for circular geometry with units. The remaining gap is failure/edge-case behavior (empty body list, wrong element type), which is minor for a simple read.

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

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

Schema coverage is 100% and each of the three identifiers is documented inline with URL-segment mapping, so the schema does the heavy lifting. The description adds no parameter-level detail beyond what is already there; baseline 3 applies.

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

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

States a specific verb+resource ('every edge of every solid body') and enumerates the returned fields (deterministic id, owning body, type, radius/centre). The exhaustive-all-edges scope implicitly contrasts with siblings like onshape_find_edges_by_feature and onshape_find_circular_edges, though those siblings are never 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?

No explicit when-to-use, prerequisites, or named alternatives. The phrase 'every edge of every solid body' implies a whole-part enumeration use case (e.g., pre-selecting targets for fillet/chamfer) as opposed to the filtered sibling tools, but the agent must infer that routing.

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

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

The readOnlyHint annotation already signals this is a safe read operation, so the description does not need to repeat that. It adds modest context by enumerating element types, but does not disclose details like whether all elements are returned by default or how filtering behaves.

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

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

The description is a single clear sentence with no wasted words. The examples in the parenthetical add useful context without bloating the definition.

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 read-only list tool with a fully documented schema and a readOnlyHint annotation, the description is nearly sufficient. It could mention that element identifiers are returned, but the lack of an output schema and the tool's simplicity keep this from being a significant 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 100%, so the schema fully explains doc, ws, and type. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('List'), a resource ('elements/tabs'), and a container ('workspace'), and names the kinds of elements returned. This clearly distinguishes it from sibling tools like onshape_list_documents or onshape_get_features.

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

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

No guidance is provided on when to use this tool versus alternatives such as onshape_get_features, onshape_get_workspaces, or onshape_find_part_studios. The usage context is only implicit in the title and description.

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

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

Annotations already provide readOnlyHint=true, so no safety contradiction. The description adds the behavioral context that the output is large and includes regeneration state, which is useful. However, it does not disclose pagination, rate limits, or any specific response format, but given the readOnly annotation, additional behavior is less critical. A 3 is appropriate for adequate but not rich behavioral disclosure.

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

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

Two sentences, zero waste. The first sentence states the core functionality, and the second immediately provides routing guidance. The warning about size is front-loaded and helps the agent avoid expensive calls. Excellent structure with no extraneous 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 read-only list tool with complete schema coverage and no output schema, the description provides everything needed: what it returns, when to use alternatives, and the size warning. The lack of output schema is fine since the description enumerates the major fields (id, type, parameters, regeneration state). Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add any parameter-specific meaning, but with complete schema coverage, baseline 3 is correct. The description only mentions the 'configuration' indirectly as part of the feature tree, but no extra syntax or constraints are needed.

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

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

The description clearly states the tool lists the full feature tree, including id, type, parameters, and regeneration state. It names specific sibling tools (onshape_measure, onshape_get_parts) as alternatives, distinguishing it from those that return results rather than the tree. This is specific and actionable.

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

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

The description explicitly says to prefer onshape_measure or onshape_get_parts when only the result of the tree is needed, providing clear when-to-use vs. when-not-to-use guidance. It also warns about the large size of the output, which helps the agent decide based on cost. This is excellent routing 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?

The description adds useful behavioral context beyond the readOnlyHint annotation by specifying what the tool returns and that it is scoped to 'this Part Studio.' It also frames the tool as a prerequisite for add_feature payload construction. No contradiction with 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?

Two compact sentences carry significant information: the first defines the output content and scope, the second gives the usage trigger. There is no redundant wording.

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?

Despite lacking an output schema, the description tells the agent what the response will contain and when to invoke this tool. All required parameters are schema-documented, and the workflow purpose is clear. Nothing essential is missing for a read-only 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?

All three parameters are fully documented in the schema (100% coverage), so the description does not need to repeat their meanings. It adds no additional parameter-specific guidance, which matches the baseline for complete schema coverage.

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?

Clearly states a specific verb and resource: it returns the parameter ids, enum names, and defaults Onshape expects for feature types in a Part Studio. This distinguishes it from onshape_get_features, which would retrieve actual features rather than their specifications.

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

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

Provides an explicit, actionable usage instruction: 'Read this before hand-writing a payload for onshape_add_feature.' It does not name alternatives or exclusions, but the workflow context is concrete and unambiguous.

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

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

The readOnlyHint annotation already communicates that this is a safe read operation, lowering the burden on the description. The description adds that the content is FeatureScript source, but does not disclose response format, error behavior, or whether it reflects the currently saved state. This is minimal but acceptable given the annotation.

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

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

The description is a single six-word fragment that conveys one essential fact without filler or repetition. It is appropriately brief and front-loaded.

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 read-only lookup with fully described parameters and no output schema, the description tells the agent that the result is the FeatureScript source. It does not detail response encoding or error cases, but the tool is simple enough that the information provided is sufficient for selection and invocation.

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

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

Schema coverage is 100%: doc, ws, and elem each have clear descriptions referencing the Onshape URL structure. The description adds no parameter-specific meaning, but with full schema coverage the baseline of 3 is appropriate.

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

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

The description identifies the returned content specifically as 'FeatureScript source' of a Feature Studio, which distinguishes it from siblings like get_feature_studio_specs or set_feature_studio. It is a noun phrase rather than an explicit verb phrase, but the tool name and title supply the read action clearly.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as onshape_get_feature_studio_specs or onshape_set_feature_studio. The phrase 'FeatureScript source' weakly implies a read-for-content use case, but no when/when-not conditions or exclusions are provided.

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, so the safe-read behavior is established. The description adds useful context that the result is specifically the custom-feature-calling specs of a Feature Studio, but it does not disclose the return shape, ordering, or any other behavioral details. This is acceptable given the read-only annotation but adds only modest context beyond it.

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

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

The description is a single, compact sentence that front-loads the core object (feature specifications from a Feature Studio) and immediately states its purpose. There is no filler, repetition, or unnecessary detail.

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 getter with three fully documented input parameters and no output schema, the description provides a complete enough mental model: the tool returns the feature specs a Feature Studio defines so its custom features can be called. It does not enumerate the spec fields, but the stated purpose is sufficient for an agent to select and invoke the tool 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 100%, and each parameter (doc, ws, elem) has a clear description referencing Onshape URL segments. The tool description adds no parameter-specific meaning, but since the schema already fully documents all three required parameters, the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource ('feature specifications a Feature Studio defines') and the purpose ('for calling its custom features'), which distinguishes it from the broader onshape_get_feature_specs sibling. It lacks an explicit verb like 'retrieves' or 'returns,' but the title supplies the action, so the intended operation is clear.

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

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

The phrase 'for calling its custom features' implies the appropriate use case: when an agent needs the specs needed to invoke custom features defined by a Feature Studio. However, it does not explicitly state when to prefer this tool over onshape_get_feature_specs or other feature-related siblings, leaving the differentiation mostly 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 readOnlyHint=true, so the safety profile is covered; the description adds genuinely non-structured detail — the returned key naming convention (translationZ_in, rotationZ_deg) and the unit system — which matters because no output schema exists. It stops short of saying the scope of mates returned or failure behavior.

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

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

A single dense sentence that front-loads the purpose and then supplies output format and units. Every clause carries information; nothing is padding, though it is packed tightly enough to be slightly harder to scan.

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 getter with no output schema, the description covers the essential unknown — what the return looks like, including key shape and units. It does not say which element scope mates are read from or what happens when a mate is suppressed, but the core call-and-interpret loop is complete.

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

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

Schema coverage is 100% and all three identifiers (doc, ws, elem) are documented in the schema with URL-segment mapping, so the description needn't repeat them. It adds no parameter-level meaning beyond what the schema already provides, which is the baseline case.

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 — reading every mate's current degree-of-freedom values — with concrete output semantics (translations in inches, rotations in degrees). It is distinguishable from write-side siblings by the 'where every mate currently sits' framing, though it never names onshape_set_mate_values or the assembly tooling it relates to.

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 read-only framing ('where every mate currently sits') implies you call this to inspect rather than modify, and onshape_set_mate_values is the obvious counterpart, but the description never states when to use this versus those alternatives or any prerequisite (e.g., that it operates on an assembly element).

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

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

The readOnlyHint annotation already signals this is a safe read operation, and the description's 'Read' is consistent with that. The description adds useful conditional behavior (element metadata vs. part metadata), but does not disclose return shape, errors, or any other runtime behavior. With annotations covering safety, this is adequate 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?

A single sentence that front-loads the action and resource, and efficiently handles the optional part behavior. There is no filler or redundant wording.

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 read-only metadata retrieval tool, the description plus the fully documented schema is nearly complete. There is no output schema, so a slightly more explicit statement of what kind of properties are returned would strengthen it, but nothing essential is missing for calling 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 100%, so doc, ws, elem, and part are each already explained. The description adds no additional parameter meaning beyond restating that part changes the scope, so the baseline of 3 applies.

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

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

The description states a specific verb ('Read'), a clear resource ('properties of an element, or of one part'), and the conditional scope when a part id is supplied. It is immediately distinguishable from its write counterpart onshape_set_metadata and from other read tools focused on features or bodies.

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