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?

With no readOnly/destructive annotations, the description carries the behavioral burden; 'Post' and 'hand-written' convey that this is an unvalidated write and a fallback rather than a high-level helper. It does not disclose validation, failure, or permission behavior, but the raw/escape-hatch nature is explicitly communicated.

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

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

One sentence, no filler, with the core action front-loaded and the use-case qualifier in a separable clause. 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 4-parameter tool with full schema coverage, the description plus schema are mostly sufficient to select and aim the call. The arbitrary 'feature' object and absent output schema could benefit from an example or a pointer to feature specs, but the escape-hatch framing sets correct expectations.

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 and the schema already documents doc, ws, elem, and feature. The description adds only that the payload is hand-written and assembly-specific, which does not change invocation 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 names a specific action ('Post ... payload') and resource ('assembly feature'), immediately distinguishing it from the generic add_feature and the dedicated assembly mate tools. The escape-hatch framing makes its role unmistakable.

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

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

It tells the agent to use this tool for 'mate types with no tool here,' implying dedicated mate tools should be preferred when available. It does not name those tools explicitly, but the 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?

Annotations contain only a title, so the description must carry the behavioral burden. It does add one meaningful behavioral trait—no individual mates are created—but it doesn't disclose whether this mutates the assembly feature tree, whether it's reversible, or what effect grouping has on transforms. This is a meaningful gap for a mutating 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 one short, front-loaded sentence with no filler. Every word contributes to the core meaning, and it avoids restating schema details unnecessarily.

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 provides strong coverage of required parameters, and the operation is conceptually simple. However, with no annotations and no output schema, the description doesn't fully explain side effects or what an agent should expect after grouping. It is sufficient for basic invocation but leaves important operational context implicit.

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 already has a clear description in the schema. The tool description doesn't add parameter-level detail, so the baseline of 3 is appropriate. It offers no extra guidance on how to format occurrence IDs or how they relate to assembly instances.

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 resource: locking instances together, rather than simply restating the title. It also draws a clear distinction from mating tools by saying 'without individual mates,' which helps an agent tell it apart from assembly_mate. It stops short of 5 because 'lock' is somewhat jargony and doesn't explicitly say this creates a Group 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 phrase 'without individual mates' implies the main use case: grouping instances when individual mates are not desired. However, it doesn't explicitly name alternatives or provide when-not-to-use guidance, and the sibling list contains several assembly tools that could overlap with this operation.

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?

Annotations provide only a title, so the description carries full behavioral burden. It never discloses that this is a mutating operation that modifies the assembly by adding a feature, nor does it mention prerequisites like existing mate connectors. 'Join' implies an action but leaves side effects and requirements unspecified.

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

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

A single sentence with no filler. The core operation is stated first and the supporting examples follow immediately. Every part 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 parameters and the description states the core operation, but with no annotations and no output schema the definition omits behavioral context: it does not say whether this modifies the assembly, what the result is, or what must already exist before calling it. An agent gets the inputs but not enough surrounding context for safe 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%, so the baseline is 3. The description adds value by naming concrete mate type values (FASTENED, REVOLUTE, SLIDER, PLANAR) that the schema's 'type' parameter does not enumerate, and it reinforces the minItems=2 requirement for connectors.

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 resource: 'Join two or more mate connectors with a mate.' It clearly distinguishes this tool from the sibling onshape_assembly_mate_connector by focusing on combining existing connectors rather than creating them. The listed mate types further clarify the operation.

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 no explicit guidance on when to use this tool versus alternatives such as onshape_assembly_mate_connector or onshape_assembly_add_feature. There are no exclusions, prerequisites, or routing cues beyond the general implication that it creates a mate.

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 no readOnly/destructive hints, so the description bears the burden of disclosing behavior. It does convey the creation of an implicit feature and its role in mating, but it doesn't mention side effects, whether it modifies an existing feature, or any prerequisites beyond the instance.

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 is first, and the crucial downstream connection to onshape_assembly_mate is stated in the second sentence.

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

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

Provides the essential selection and usage context: placing an implicit mate connector on an instance and linking the resulting feature id to assembly mating. Given the well-documented schema and lack of an output schema, this is largely sufficient, though it could state the mutating effect more 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%, so the schema fully documents all parameters, defaults, and required fields. The description adds context about inference types being used for placement, but does not need to repeat parameter details.

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

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

States a specific verb ('Place') and resource ('implicit mate connector on an instance'), and clarifies the mechanism ('by inference (CENTROID, TOP, ...)'). It also distinguishes itself from the related sibling onshape_assembly_mate by explaining the connector's feature id is what that tool then joins.

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 contextual guidance: use this tool to create the mate connector that onshape_assembly_mate later consumes. It doesn't explicitly list exclusions or alternative tools, but the assembly-mating workflow 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?

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 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 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 provide only a title, so the description carries the full burden of behavioral disclosure. It implies a non-destructive read/export and hints at a measurement prerequisite, but it does not state side effects, output destination, whether the file is written locally or returned, auth requirements, or why measuring matters. The 'measure before exporting' instruction is ambiguous about the underlying 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?

Two short sentences with zero filler and the core action front-loaded. The second sentence earns its place as a workflow tip, though its cryptic wording slightly reduces the value of an otherwise compact 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?

With no output schema, only a title annotation, and 8 parameters, the description should clarify what the export produces and how defaults like units/resolution behave. It leaves an agent uncertain about return values, file handling, and the reason for the measurement prerequisite, making it incomplete for confident invocation.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented with their own descriptions. The tool description adds no parameter-level meaning beyond the schema, matching the baseline of 3 for high 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 (Export), resource (Part Studio), and format (STL) with a clear use case (3D printing). This specificity distinguishes it from the sibling onshape_export and onshape_export_drawing, so an agent can identify the right tool without opening the schema.

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

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

The 'for 3D printing' clause gives clear usage context, and the second sentence adds a workflow pre-step ('Measure the model before exporting it'). However, it names no alternatives or exclusion conditions versus the generic onshape_export sibling, leaving some selection judgment to the agent.

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

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

With only a title annotation and no readOnly/destructive hints, the description carries the burden of behavior disclosure. It clearly states that NEW makes a body and that ADD/REMOVE/INTERSECT modify existing bodies. It doesn't mention feature-tree side effects or regeneration validation, but the core mutating behavior is transparent.

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

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

Two sentences with no filler. The core action is front-loaded, and the op modes are compressed into a compact, readable list.

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

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

Given a well-documented schema and no output schema, the description covers the essential conceptual ground: closed sketch regions, solid result, and boolean operations. It could add failure conditions, such as missing existing bodies for REMOVE/INTERSECT, but nothing critical is missing for basic 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?

Since the input schema already documents all 9 parameters, the baseline is 3. The description adds value by giving concrete semantics to the op enum (merge, cut, overlap) and by emphasizing that the input sketch must have closed regions.

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 operation (extrude), a clear resource (closed regions of a sketch), and the resulting output (a solid). This distinguishes it from sketch-drawing tools and many other modeling operations, though it doesn't 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?

Provides clear contextual use — closed sketch regions become a solid — and explains the different boolean modes. However, it does not explicitly state when to choose extrude over alternatives like revolve, sweep, or thicken, nor when not to use it.

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 radius-filtering behavior and a typical use case, but does not disclose the return format or any limitations. For a read-only tool, 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 a single concise sentence (fragment) that front-loads the core purpose and then adds optional filtering and a use case. It is efficient, though it could be more structured as a full sentence.

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

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

For a simple read-only tool with 5 parameters and no output schema, the description explains purpose and typical use but does not mention what the tool returns (e.g., a list of edge IDs). Since there is no output schema, this is a notable gap, but the tool's simplicity and common patterns may mitigate 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 all parameters are documented. The description's mention of 'matching a radius' adds minimal context to the radius parameter, but does not go beyond what the schema already states. 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 the tool returns circular edges, optionally filtered by radius, and gives a typical use case (picking hole rims to fillet). It distinguishes from generic edge tools by focusing on circular edges, but the verb 'find' is implied rather than explicit, and the resource scope (part studio) is not stated.

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

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

The description suggests when to use it (for picking hole rims to fillet) but does not explicitly compare to sibling tools like onshape_get_edges or onshape_find_edges_by_feature, nor state when not to use it. The guidance is implied 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?

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?

The readOnlyHint annotation already tells the agent this is a safe read operation, lowering the burden on the description. The description adds a small behavioral detail by specifying exactly which kinds of features are listed (mates, connectors, groups) and that feature ids are included, but it does not disclose pagination, response format, or other runtime behaviors.

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 sentence with no filler or repetition. It front-loads the meaningful content — what the tool returns — and every word adds information.

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

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

For a simple read-only listing tool with three fully documented parameters, the description is mostly complete: it states the target resource (assembly) and the output contents (mates, connectors, groups with feature ids). The lack of an output schema makes the description the only source of return-value information, and it covers that adequately, though it could mention whether the result is a list or object.

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 every parameter already has a clear explanation tying doc, ws, and elem to URL segments. The description adds no additional parameter semantics, 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 the specific content returned — mates, mate connectors, and groups defined in an assembly — and mentions feature ids, so an agent can tell this is an assembly-feature lister. It does not use an explicit verb like 'List', but the title and tool name supply that, and the resource scope is clear enough to distinguish it from generic feature tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as onshape_get_features or onshape_get_assembly. It implies assembly feature listing but does not state exclusions, prerequisites, or selection criteria, leaving the agent to infer the right context.

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

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

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?

Annotations declare readOnlyHint=true, covering the safety profile. The description adds that edges come with a deterministic id, owning body, type, and radius in inches, which is useful context beyond the annotation. However, it doesn't mention any edge cases (e.g., only solid bodies, not surfaces) or whether the result set is large, so it adds moderate behavioral detail without going deep.

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

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

A single, well-structured sentence that front-loads the core purpose and lists the returned attributes. No fluff, no redundancy, and 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 simple list operation, the description covers what it returns and the scope (all solid bodies). It doesn't specify the output format or pagination, but since there is no output schema, the description partially compensates by naming the fields. It could mention that edges are from solid bodies only, which it does, and that radius applies only to circular edges, but that is a minor 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 all three parameters (doc, ws, elem) described in the schema itself. The description adds no additional parameter semantics, so the baseline score of 3 applies because the schema carries the full 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?

The description clearly states the tool lists every edge of every solid body, with specific attributes (id, body, type, radius). It is distinct from sibling tools like find_circular_edges or find_edges_by_feature, but it doesn't explicitly name those alternatives, so the differentiation is implicit 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?

No guidance is given on when to use this tool versus alternatives such as onshape_find_circular_edges or onshape_find_edges_by_feature. The description implies it returns all edges, but it doesn't state when a more targeted edge query would be appropriate, nor does it mention any prerequisites or context for use.

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?

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.

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

The description implies this is the tool to use when metadata is needed, but it does not explicitly state when to prefer it over related tools like onshape_get_elements or onshape_get_parts. There are no exclusions or explicit alternative routing, so usage guidance is only implied.

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

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

The annotation readOnlyHint=true already covers the safety profile, so the description does not need to restate that the operation is read-only. The description adds the useful behavioral detail that the result contains part ids intended for export and assembly insertion. However, it does not mention ordering, configurability, or whether the listing reflects a specific configuration state, which would add further transparency.

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 compact sentence with no filler. It front-loads the core meaning and then adds the most important downstream use of the returned data. It could be slightly more direct by starting with 'Lists' instead of 'The parts', but overall it is efficiently written.

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 tool with fully documented parameters, the description provides enough context: it names the subject, the source, and the intended downstream use of the returned part ids. There is no output schema, so more detail about the exact return shape would be welcome, but the description is adequate for correct 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%, and all three parameters (doc, ws, elem) have descriptive explanations linked to URL segments. The description itself adds no parameter-specific semantics, so the baseline of 3 applies because the schema already carries the 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?

The description clearly identifies the resource (parts) and the producing context (a Part Studio), and it specifies the key content (part ids) for export and assembly insertion. The title 'List parts' supplies the verb, so an agent can infer the action even though the description is a noun phrase. It is distinguishable from sibling tools like get_features or get_elements, though it does not explicitly name them.

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

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

The description gives clear context for when this tool is useful: when a caller needs the parts a Part Studio produces, particularly their part ids for downstream export or assembly insertion. It does not explicitly list exclusions or alternative tools that might be preferable in other cases, but the use case is clear 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?

Annotations already declare readOnlyHint=true, and the description adds the specific return content (entities and solved geometry), which is useful context. It doesn't disclose additional behaviors like pagination or error conditions, but with the safety profile covered, this is a reasonable baseline.

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, efficient sentence that front-loads the core capability. It avoids unnecessary words and is easy to parse, though it could optionally mention the optional parameter's effect more explicitly.

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 should clarify what the agent will receive. It mentions 'entities and solved geometry' but not their structure or any caveats. For a straightforward read-only tool with well-defined inputs, this is adequate but leaves some ambiguity about the response format.

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

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

Schema description coverage is 100%, so the parameters are fully documented. The description adds no additional meaning beyond the schema, such as clarifying the 'sketch' parameter's format or how the 'elem' refers to a Part Studio tab. 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 resource (sketch entities and solved geometry) and scope (all sketches in a Part Studio or one sketch), distinguishing it from other get_* tools by its specific focus. However, it lacks an explicit verb like 'retrieves' or 'returns', and doesn't contrast with siblings, though the name already implies a getter.

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 usage is implied: if you need sketch geometry, this is the tool. But it doesn't explicitly state when to use it over alternatives, mention when not to use it, or note any prerequisites. For a simple getter this is acceptable but not ideal.

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 discloses an important behavioral trait: thumbnails are generated asynchronously and can lag behind edits. However, annotations provide no behavioral hints, and the description does not clarify side effects such as writing a file to disk, returning an image, or whether the operation is 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?

Two short sentences with no filler. The core purpose is front-loaded, and the caveat plus alternative is delivered immediately after.

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 critical caveat about stale thumbnails and the pointer to onshape_shaded_view are present, and the schema fully documents parameters. A minor gap is that return/save behavior is not explicitly described, but the schema's out and return_image fields partially cover this.

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

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

Schema description coverage is 100%, so parameters are already well documented. The tool description adds no parameter-specific meaning, 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 states a specific action and resource: saving Onshape's stored thumbnail. It also distinguishes this tool from onshape_shaded_view by noting that shaded_view shows current state, so the agent can tell which tool serves which need.

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 explicitly names onshape_shaded_view as the preferred alternative when current state is needed, which tells the agent when not to use this tool. That is clear, actionable usage 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 safety profile, and the description adds useful context about what the variable table contains. However, it does not disclose behaviors such as whether all variables are returned, how empty tables are handled, or any error conditions. There is no contradiction with 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, compact sentence that directly conveys the tool's purpose and expected content without extraneous words. 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 simple read-only listing tool with fully documented required parameters and a readOnlyHint annotation, the description is nearly sufficient. It communicates the returned fields, which partially compensates for the missing output schema, though it omits any nuance about version context or empty results.

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 parameters are fully documented in the schema. The description adds no parameter-level semantics beyond the schema, keeping this at the baseline of 3.

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 resource (Part Studio variable table) and the content returned (names, expressions, descriptions), and the title supplies the 'List' verb. It is clear and distinct from the sibling set_variable, though it never explicitly states 'retrieves' or 'lists'.

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

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

There is no guidance on when to use this tool versus alternatives such as onshape_set_variable or other read-only queries. The intended context can be inferred from the name and title, but no explicit usage 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 safety profile is covered. The description adds the clarification that workspaces are 'branches', which is useful domain context. However, it does not disclose what the response contains (e.g., workspace names, IDs, default workspace) or any pagination/ordering behavior. With annotations covering the read-only nature, a 3 is appropriate.

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, efficient sentence that front-loads the verb and resource. It adds the parenthetical clarification '(branches)' which is valuable domain context without waste. 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 simple, read-only list operation with one fully documented parameter, the description is nearly complete. The only minor gap is that it doesn't describe the return format (e.g., list of workspace names/IDs), but since there is no output schema and the tool is simple, this is a small omission. The read-only annotation covers the safety profile.

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 fully documents the 'doc' parameter, including its format and example. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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') and resource ('a document's workspaces (branches)'), which clearly identifies the operation. It does not explicitly differentiate from sibling tools like onshape_list_versions or onshape_get_elements, but the resource is distinct enough that an agent can infer the 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?

The description implies usage context: it lists workspaces for a document, which is a read-only operation. However, it does not explicitly state when to use this tool versus alternatives like onshape_list_versions or onshape_get_document, nor does it mention any prerequisites (e.g., needing a document ID). The context is clear but not fully explicit.

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