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

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that the operation mutates an assembly by adding an instance, but it does not explain side effects, required ownership, relationship between the two element IDs, or what happens if the part studio or assembly is already instanced. This is a meaningful gap for a mutating CAD 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, efficient sentence with no filler or redundancy. It is appropriately front-loaded, though it omits useful context that could make it more informative without much added length.

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 six parameters, no output schema, and no annotations, yet the description provides only a one-line summary. It does not help an agent understand the document/workspace/element ID structure, the optional partId behavior, or how this operation differs from other assembly-related tools. The context is insufficient for confident correct invocation.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds only a high-level hint ('part or sub-assembly') that maps loosely to isAssembly, but it does not clarify the relationships among documentId, workspaceId, elementId, and partStudioElementId. Baseline 3 is appropriate given the schema's completeness.

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 ('Add') and the resource ('a part or sub-assembly instance to an assembly'), which is more specific than a mere restatement of the name. It implies differentiation from siblings like create_assembly, but does not explicitly name alternatives.

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

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

The description gives no guidance about when to use this tool versus alternatives such as create_assembly, transform_instance, or set_instance_position. There are no stated prerequisites, exclusions, or decision criteria, so an agent must infer usage from the tool name and schema alone.

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

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

With no annotations provided, the description carries the full behavioral burden. It clearly discloses the coordinate semantics for each face, the fact that only the perpendicular axis moves, and that other axes remain unchanged. It does not cover persistence, mate effects, or error behavior, but the core operation is well disclosed.

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

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

Three short sentences with no filler: purpose first, then a compact face/axis reference, then a key limitation. Every sentence earns its place and the most important constraint is clearly 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 six-parameter operation with no output schema, the description provides sufficient detail to invoke it correctly: what moves, against what, which axes, and what stays unchanged. It omits mention of return behavior or preconditions, but these are minor given the operation's specificity.

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 already documents all six parameters, so the baseline is 3. The description adds meaningful value by defining what each face enum value means in terms of min/max axes, helping the agent choose the correct face parameter. It also reinforces the roles of source and target 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?

States a specific verb ('Position'), a clear resource ('source instance'), a reference ('face of target instance'), and the expected result ('flush'). The face-to-axis mapping makes the intended operation unambiguous and distinguishes it from generic transform 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?

Provides clear context: use when a source instance should be placed flush against a specified target face. The statement that only the perpendicular axis moves implies that arbitrary or multi-axis positioning would need a different tool, though no alternative is explicitly named.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that the tool uses bounding box detection (a behavioral detail implying approximation) and states the return type (overlap and amount). However, it omits caveats such as the approximate nature of bounding boxes potentially leading to false positives/negatives, or any side effects (which are likely none, being a read-only check). The disclosure 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 two sentences with zero wasted words. It front-loads the core purpose and immediately states the output. The structure is clean and efficient, making it easy to parse for an agent.

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 must explain the return value. It does state the high-level result ('which parts overlap and by how much'), but it lacks detail such as the exact format (e.g., list of part IDs, units of overlap, behavior when no overlap exists). The tool is relatively simple, so this is a moderate gap, not a critical omission. The description is sufficient to understand the tool's function but not fully complete for precise invocation without additional inference.

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 parameter having a basic description ('Assembly element ID', 'Document ID', 'Workspace ID'). The tool description adds no additional meaning about how these parameters are used or their relationships, so it stays at the baseline of 3. No extra value is provided 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 clearly states a specific verb ('Check'), a resource ('assembly'), a method ('bounding box detection'), and the output ('which parts overlap and by how much'). This distinguishes it from siblings like get_bounding_box or measure, which have different purposes. The purpose is unambiguous 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 provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as needing to load the assembly first, nor does it suggest when this tool is preferable to measure or get_bounding_box. There is no exclusionary language or alternative 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?

With no annotations provided, the description carries the full burden and discloses meaningful behavior: it renders four views, composites them below the reference, aligns horizontal extents, and notes that the reference path must be readable by the MCP server. It leaves minor gaps such as exact return delivery format and side effects, but the core behavioral contract is clearly exposed.

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 four sentences, each earning its place: it states the operation, the output layout, the alignment guarantee, the intended use case, and the path constraint. It is front-loaded with the core verb and output before adding supporting detail, with no filler.

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

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

The description is solid for a moderately complex compositing tool, but with no output schema and no annotations, an agent still lacks some critical context: how the returned PNG is surfaced, how width/height affect the composite, and what happens if the reference file does not exist. The layout and use case are clear, but the return contract and edge behaviors are underspecified.

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 low at 29%, so the description must compensate. It adds useful meaning for referenceImagePath ('filesystem path readable by the MCP server') and for views by naming the defaults, and it implies that documentId/workspaceId/elementId identify the current Part Studio. However, width, height, and the three ID parameters remain largely unexplained in both schema and 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 highly specific action: render the current Part Studio in four named views and composite them under a reference image. It also names the exact output, a single side-by-side PNG, which clearly differentiates it from standalone rendering tools like render_part_studio_views and from plain load_local_image.

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 a clear when-to-use scenario: 'Use this whenever you want to cross-check feature count / placement / proportion against the brief's reference figure.' It does not explicitly name alternatives or state when not to use the tool, but the intended context is unambiguous enough for an agent to route itself.

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?

There are no annotations, so the description carries the full burden of disclosing behavior. It states that this creates something, but does not mention side effects, permissions, reversibility, failure modes, or what happens to the assembly after creation.

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 with no filler. Every word contributes to understanding the tool's core purpose.

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 three-parameter creation tool with a fully described schema, the description is minimally adequate. However, it omits what the tool returns, whether success is indicated, and any behavioral constraints such as document existence requirements beyond the implied 'existing document.'

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 already documents all three parameters at 100% coverage. The description only adds the 'existing document' context and does not explain relationships such as whether workspaceId must match documentId or any naming constraints.

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 ('Create') and a specific resource ('a new Assembly'), and scopes it to an existing document. This distinguishes it clearly from sibling tools like create_document and create_part_studio.

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 guidance on when to choose this tool over alternatives, no exclusions, and no mention of related prerequisites beyond 'existing document.' It does not differentiate from create_document, create_part_studio, or add_assembly_instance.

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

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

No annotations are provided, so the description must disclose behavioral traits, but it only says 'Perform a boolean operation.' It does not state whether this creates a new feature, modifies/destroys the target bodies, requires specific body ownership, or how the operation affects the existing modeling history. For a mutation tool, this is a meaningful 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 a single, tightly written sentence that communicates the core operation and valid operation types without any filler. It is front-loaded with the action and resource and contains no wasted 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?

Given 7 parameters, 5 required fields, no annotations, and no output schema, the one-line description is not complete enough on its own. It omits the relationship between targetBodyIds and toolBodyIds, the expected result of each boolean type, any prerequisites such as body overlap, and what the tool returns or changes in the model.

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 already documented in the schema. The description adds little beyond restating union/subtract/intersect, which duplicates the booleanType enum. Thus a baseline 3 is appropriate; the schema is doing 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 clearly states the action ('Perform a boolean operation') and the resource ('bodies'), and it enumerates the supported operation types (union, subtract, intersect), which is specific enough to distinguish it from sibling modeling tools like create_extrude or create_fillet. It does not name siblings explicitly, but the operation types make 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 that this tool should be used when a boolean combination of bodies is needed, based on the explicit operation types. However, it provides no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no comparison to alternative feature-creation 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?

No annotations exist, so the description must carry the burden of behavioral disclosure. 'Create' signals mutation, but the description does not mention that this adds a feature to the model/Part Studio history, that the edge IDs must come from existing geometry, or any failure/undo implications. This is a meaningful gap for a mutating CAD 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?

A single sentence that front-loads the operation and clarifies the geometry term ('beveled edge') in a parenthetical. Every word earns its place and there is no redundant or filler content.

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 input schema fully documents all seven parameters, and the description gives the core semantic, but the tool has no output schema and no annotations. The description does not explain what the tool returns, what preconditions must hold (valid edges in the referenced element), or how this relates to subsequent feature operations, leaving an agent to infer those details.

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 documents distance units, deterministic edge IDs, optional variable distance, and the default name. The description itself adds no parameter-level detail; the baseline of 3 is therefore 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 operation ('Create') and the resource ('chamfer (beveled edge)') and narrows the target to one or more edges. It does not explicitly contrast with the closely related sibling create_fillet, so it misses the full differentiation expected for a 5.

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

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

The intended use is implied: call this when a chamfer needs to be added to edges. There is no explicit statement of when to prefer it over alternatives such as create_fillet, nor any when-not-to-use or exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only restates the action. It does not mention that this modifies the Part Studio by adding a feature, whether existing features must already be present, what happens on execution, or whether it returns the created pattern's ID. For a mutation tool with zero annotation coverage, 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?

A single 11-word sentence with no filler, front-loaded with the verb 'Create'. Every word earns its place and the structure is optimally scannable for an agent.

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 being an 8-parameter tool with no annotations and no output schema, the description offers only a one-line purpose. It omits operational context such as the angle/count relationship, default behaviors (360 degrees, Z axis), prerequisites for featureIds, and what response to expect. The rich schema descriptions help but cannot fully compensate for missing execution 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%, so the schema already documents all 8 parameters, giving a baseline of 3. The phrase 'around an axis' adds slight semantic reinforcement to the axis/angle parameters, but the description otherwise does not enrich parameter meaning beyond what the schema provides.

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

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

The description uses a specific verb ('Create'), a clear resource ('a circular pattern of features'), and a mechanism ('around an axis'), making the basic purpose unambiguous. However, it does not explicitly differentiate itself from the sibling tool create_linear_pattern; only the word 'circular' carries that distinction.

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. With 70+ sibling tools including create_linear_pattern, the agent receives no routing information about choosing circular vs linear patterning, what features must exist first, or when this tool is inappropriate.

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

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

With no annotations provided, the description carries the behavioral burden and does meaningful work: it explains that the first instance slides and rotates relative to the second along the mate connector Z-axis, and that optional offsets shift connectors from face centers. It does not disclose return behavior or failure modes, so it is not a 5, but it is substantially transparent for a mutation 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?

Three tight sentences deliver the core purpose, relative motion, prerequisite face IDs, and offset behavior without restating schema details. The most important scoping information is front-loaded, and every sentence contributes unique value.

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 high parameter count and lack of an output schema or annotations, the description plus fully documented schema provide enough context for correct invocation: required IDs, instance roles, motion axis, offsets, and limits are all covered. A minor gap is that the return value and error behavior are not described, but that does not block selection or invocation.

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

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

The input schema already documents all 16 parameters with 100% coverage, providing a baseline of 3. The description adds useful cross-parameter context by clarifying that offsets shift connectors from face centers and that motion occurs along the Z-axis, which helps the agent understand how the optional offset and limit parameters relate to the mate geometry.

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 precise verb and resource: 'Create a cylindrical (slide + rotate) mate between two assembly instances.' It explicitly distinguishes this from sibling mate tools by defining it as slide + rotate, so an agent can tell it apart from create_revolute_mate, create_slider_mate, and create_fastened_mate.

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 clear usage context by describing the kinematic behavior and the prerequisite 'Requires face IDs from Part Studio body details.' It implies when this tool is appropriate versus the revolute/slider alternatives, though it does not explicitly state exclusion criteria or name 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?

With no annotations provided, the description carries the behavior-disclosure burden. It goes beyond a simple 'create' statement by specifying the exact IDs returned in one shot and that no follow-ups are needed, giving the agent useful expectations about side effects and output.

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 tight sentences with no filler: the first states the action, the second delivers the key return-value benefit. The most important information is front-loaded 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 create tool with no output schema, the description adequately explains the expected return values and the workflow benefit. It does not cover edge cases like failures or whether a default Part Studio always exists, but for typical agent use the context is complete.

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

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

The input schema already documents all three parameters (name, isPublic, description) with 100% coverage. The description adds no parameter-level meaning, but the schema is sufficient, 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 states a specific verb and resource: 'Create a new Onshape document.' It also clarifies the tool's unique value by explaining the single-call return of documentId, workspaceId, and default Part Studio elementId, distinguishing it from follow-up tools like get_document_summary and find_part_studios.

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 practical context: when creating a new document, the agent can use this tool and skip the two follow-up calls. It does not explicitly enumerate exclusions with all sibling creation tools, but the guidance is concrete and sufficient for routing.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The one-sentence description does not mention that this mutates the document, requires an existing sketch, can add/remove material, or that REMOVE currently auto-flips direction in certain cases. Those details exist only in the schema, not in the description.

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 with no filler or redundancy. Every word earns its place, and the core action and resource are immediately clear.

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 11 parameters, 5 required inputs, and no output schema, a one-sentence description is not contextually complete. It omits high-level operational context such as the need for an existing sketch, the range of operation types, and what the result or return value looks like. The schema is rich, but the description alone does not orient an agent sufficiently.

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 input schema already documents all 11 parameters, including rich details like depth units, endType behavior, and the oppositeDirection auto-flip. The description itself adds no parameter-level meaning, 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 uses a specific verb and resource: "Create an extrude feature from a sketch." It clearly identifies the operation and differentiates it from sibling tools like create_revolve or create_thicken by stating the sketch-based source.

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. It does not mention prerequisites such as having a sketch already created, nor does it compare against other feature-creation tools like create_revolve or create_thicken.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose key behaviors: it creates a rigid mate, requires face IDs, and explains how offsets shift connectors in the face's local coordinate frame. However, it omits operational consequences such as failure modes, whether mate connectors are created implicitly, or what the tool returns on success.

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 first sentence states the core purpose, and the second sentence provides the critical prerequisite and offset behavior. Every clause earns its place, and the most important information is 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 tool with 14 parameters and no output schema, the description covers the essential selection and invocation knowledge: purpose, mate type, required face IDs, and offset coordinate semantics. It does not detail return values or failure behavior, but the rich parameter schema and focused description make the tool adequately understandable for an agent.

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 each parameter. The description adds meaningful value beyond the schema by explaining that offsets are applied in the face's local XY plane with Z along the normal, and by clarifying that face IDs come from Part Studio body details. This extra semantic context helps an agent correctly populate parameters.

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 a specific verb and resource: 'Create a fastened (rigid) mate between two assembly instances.' The term 'fastened (rigid)' clearly distinguishes this mate type from sibling tools like create_revolute_mate or create_slider_mate. The scope is precise and immediately 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 gives clear usage context: face IDs from Part Studio body details are required, and offsets are optional for positioning connectors. It does not explicitly state when to choose this tool over alternative mate tools, but the 'fastened (rigid)' qualifier and face-placement requirements provide enough context for an agent to infer its intended 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states the action but not side effects such as adding a feature to the feature tree, modifying the solid geometry, or whether the operation is reversible. 'Create' implies mutation but does not disclose what happens beyond that.

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 parenthetical definition increases clarity without extra verbosity. The core action, resource, and scope are 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?

The schema fully documents all seven parameters, and the description states the operation and scope clearly. However, with no annotations and no output schema, the description does not explain the resulting model change or feature lifecycle, which is a notable gap for a create-type operation.

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% parameter description coverage, so the baseline is 3. The description adds only a general 'one or more edges' idea, which the edgeIds parameter already conveys; no parameter-specific meaning is added 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 specifies a clear action ('Create') and resource ('fillet'), with the parenthetical 'rounded edge' clarifying the geometry and 'one or more edges' defining scope. It does not explicitly name or contrast with the sibling create_chamfer, so it stops short of full sibling differentiation.

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

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

No guidance is provided about when to use create_fillet versus alternatives such as create_chamfer. There are no usage conditions, exclusions, or context clues beyond the operation name itself, leaving the agent to infer suitability.

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

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

No annotations are provided, so the description carries the burden, and it uses this well by disclosing a non-obvious behavioral requirement: Onshape has no implicit world-X axis, so the directionEdgeId is mandatory. It also explains how to satisfy that requirement. It does not discuss side effects or errors, but the create semantics are reasonably transparent from context.

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 compact, well-structured, and front-loaded with the core purpose before the key requirement and workflow. Every sentence contributes useful information, and there is no fluff or repetition of schema-defined details.

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 mutating tool with no output schema and 8 parameters, the description covers the hardest part—obtaining and passing directionEdgeId—and references a sibling tool (list_entities) for further help. It does not mention how to obtain featureIds or what happens after creation, but those gaps are partially covered by the schema and surrounding sibling tools, so the description is nearly complete.

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

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

Schema coverage is 100%, which sets a baseline of 3. The description adds real value on top by explaining that directionEdgeId must come from list_entities(kinds=['edges']) or from a dedicated sketch line, and by walking through the intended workflow. This goes beyond the schema's parameter descriptions.

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

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

The description opens with 'Create a linear pattern of features' — a specific verb and resource that clearly identifies what the tool does. The emphasis on a direction edge and the word 'linear' naturally distinguish this from create_circular_pattern without needing to name the 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 workflow context: a deterministic edge id must be obtained first, either from list_entities or from a sketch line drawn as a reference. It does not explicitly contrast with create_circular_pattern or say 'use this for straight-line patterns', so it stops short of full alternatives guidance.

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

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

With no annotations provided, the description carries the full disclosure burden and delivers substantial behavioral detail: offsets are interpreted in the connector's LOCAL frame, flipping primary reverses other axes via the right-hand rule, and this changes how translations map to world space. This goes well beyond a typical create-tool description. It stops short of disclosing side effects like feature-tree footprint, idempotency when a connector already exists on the face, or failure conditions, but the geometric behavior is exceptionally well covered.

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

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

Three sentences with zero waste. The purpose is front-loaded in sentence one, placement and coordinate semantics in sentence two, and the subtle flip behavior in sentence three. Every sentence carries load-bearing information for correct invocation.

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 geometrically complex tool with 11 parameters, no annotations, and no output schema, the description covers the hard parts thoroughly: local coordinate semantics and flip interaction. Gaps remain: no mention of what the tool returns (e.g., connector ID) since there is no output schema, no failure conditions (e.g., non-planar faces), and no clarification of what 'explicit' contrasts with. These are meaningful but secondary to the core geometric behavior, which is fully specified.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining that offsetX/Y/Z are interpreted in the connector's LOCAL coordinate system (X/Y in-plane, Z along normal) — the schema only says 'offset from face center' without specifying the frame. It also enriches flipPrimary by explaining the right-hand-rule axis reversal and its world-space consequences, which the schema's 'Flip the primary (Z) axis direction' does not convey.

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

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

The first sentence states a specific verb ('Create') and an explicit resource ('mate connector on a face of an assembly instance'). It distinguishes itself from the mate-constraint siblings (create_fastened_mate, create_revolute_mate, etc.) by making clear this creates a reference connector, not a mate constraint. Additional placement details (face center, Z-axis along normal) sharpen the purpose further.

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 operational context — the connector is anchored at a face center with axis orientation — which implies when it would be used. However, it never explicitly routes the agent between this tool and its alternatives; for example, it does not say 'use this to define an explicit reference frame before applying a mate, when automatic connector placement is insufficient.' The word 'explicit' hints at such a contrast but does not state 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?

With no annotations provided, the description carries the behavioral disclosure burden. It explains the nature of the created object, the offset sign convention ('Positive follows the reference outward normal; negate or set flip to invert'), and the key downstream behavior of passing the feature_id as a sketch faceId. It does not discuss permissions or document side effects, but the core behaviors of this construction-plance creation tool are clearly disclosed.

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

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

The description is four dense sentences with no filler. Each sentence earns its place: the definition, the motivating use case, the parameter-mode selection, and the downstream usage. It is front-loaded with the core purpose and avoids repeating obvious schema field semantics.

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 is strong overall, but it never explicitly states that exactly one of `plane` or `referenceFaceId` must be provided; the schema lists both as optional, so an agent could satisfy all required fields and omit the reference entirely, resulting in an invalid call. There is also no output schema, so the only return-behavior guidance is the implicit `feature_id` mention, which could be more explicit.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial semantic value beyond the schema. It clarifies how to choose between `plane` and `referenceFaceId`, notes that `referenceFaceId` comes from `list_entities`, gives unit and direction examples for `offset`, and explains the returned feature_id's role in sketch primitives.

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 and resource: 'Create an offset construction plane: a datum plane parallel to a reference plane or face, shifted by a signed distance.' It also distinguishes this from sketch tools by explaining that the new plane becomes a sketch target, so an agent can tell it apart from siblings like create_sketch or create_extrude.

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 when-to-use guidance: 'Use when you need to sketch at a specific Z (e.g. 2.5 mm above the Top plane) without an existing face there.' It also explains the two modes of use, plane vs referenceFaceId, and the downstream sketch-target behavior. It doesn't explicitly name alternative tools or state a formal 'do not use when', but the use case is clear and there is no sibling plane-creation 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?

With no annotations, the description carries the burden of explaining behavior. It discloses the creation side effect and, more usefully, reveals the exact return values: the new elementId and the list of other Part Studios. It also exposes the hidden pitfall about the empty default 'Part Studio 1', which is valuable behavioral context beyond a basic description.

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 concise, well-structured, and every sentence earns its place. It front-loads the primary action, then adds return semantics and guidance about the default Part Studio pitfall in a natural order.

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 three required parameters and no output schema, the description adequately explains what to expect back and how to use the result. It could add more detail about constraints or failure modes, but the key contextual elements—what it creates, what it returns, and how to avoid a common mistake—are present.

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

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

Schema description coverage is 100%, so the schema documents all three parameters, but those descriptions are thin ('Document ID', 'Workspace ID', 'Name for the new Part Studio'). The description adds only general context like 'existing document', not deeper meaning for the parameters themselves, 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 uses a specific verb and resource ('Create a new Part Studio in an existing document'), clearly distinguishing it from other creation tools like create_document and from querying tools like find_part_studios. It also states what the tool returns, leaving no ambiguity about its 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 gives explicit guidance to prefer this tool's returned elementId over re-enumerating via find_part_studios, and frames the tool as the appropriate way to create a Part Studio in an existing document. This directly helps an agent choose it among many 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?

No annotations are provided, so the description carries the full burden. It clearly implies a mutating action ('Create'), but does not disclose potential side effects (e.g., whether it replaces existing mates), authentication requirements, or rate limits. The core behavior is transparent enough for a create action, but additional details are lacking.

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 succinct, using only three sentences to convey the core purpose, requirements, and offset behavior. No redundant information is present, and the structure is 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?

Given the complexity (16 parameters, 7 required), the description covers essential context: it notes the need for face IDs, explains offset behavior, and implies assembly modification. It does not elaborate on return values or how to obtain face IDs, but with 100% schema coverage and no output schema, these omissions are acceptable.

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 every parameter having a description. The description adds valuable semantic details beyond the schema, especially for offset parameters ('Bare numbers = mm; strings like "10 mm" / "0.5 in" respected'), which clarifies unit handling and prevents misuse.

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'), the resource ('a revolute mate'), and the constraint behavior ('first instance rotates relative to the second around the mate connector Z-axis'). It effectively distinguishes this from sibling mate tools like create_fastened_mate and create_slider_mate by specifying the rotational 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?

The description provides some usage context, such as requiring face IDs from Part Studio body details and explaining that offsets shift connectors. However, it does not explicitly mention when to use this tool versus alternative mate types (e.g., slider or cylindrical mates), leaving selection partially 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the basic creation action and does not mention prerequisites like an existing sketch, the effect of operationType (NEW/ADD/REMOVE/INTERSECT) on geometry, or possible failure conditions. This is a significant gap for a mutating 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 a single, front-loaded sentence with no wasted words: 'Create a revolve feature' comes first, followed by the mechanism. It is concise, though the brevity comes at the cost of omitting important usage and behavioral context.

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 8 parameters, 4 required inputs, no annotations, and no output schema, a one-sentence description is insufficient for an agent to call this tool correctly in all cases. The schema documents parameters, but the description does not explain preconditions, operation type behavior, or how this feature interacts with existing geometry.

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 already well documented. The description adds minimal semantic value beyond reinforcing that a sketch is rotated around an axis, but it does not need to compensate because the schema handles the details.

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

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

The description clearly states a specific verb ('Create'), a specific resource ('a revolve feature'), and the defining mechanism ('rotating a sketch around an axis'). This distinguishes it from similar sibling tools like create_extrude and create_thicken, even without naming 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 phrase 'rotating a sketch around an axis' implies the intended use case and naturally separates it from extrusion or thickening. However, it does not explicitly mention alternatives or state when not to use this tool, leaving the agent to infer 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?

With no annotations, the description carries the burden, and it discloses composite geometry, faceId precedence, and a precise cornerRadius bound. It does not describe return values or failure modes, but the behavioral detail it provides is meaningful and not just schema repetition.

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 purposeful sentences: what/why, where, and constraint. The key scoping claim is front-loaded and no sentence is 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?

The description plus rich schema is enough to select and invoke the tool correctly for a 9-param creation tool. It lacks output/return details and failure behavior, but no output schema exists and the schema covers parameter semantics.

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 already documents params, so baseline is 3. The description adds value beyond schema by defining corner1/corner2 as opposite corners of the bounding rect and adding the 'no more than half the short side' constraint on cornerRadius, which is not in the schema.

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

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

Description states a specific action and resource: 'Create a rounded rectangle sketch (4 lines + 4 tangent corner arcs) in ONE feature.' It also differentiates itself from per-primitive tools, so an agent can distinguish it from create_sketch_line/create_sketch_arc/create_sketch_rectangle without opening schemas.

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 says when to use it: instead of hand-rolling 4 lines + 4 arcs with per-primitive tools, citing benefits (fewer turns, no radians/degrees mistakes). Also gives location selection guidance and precedence: pass plane or faceId, and faceId wins if both are given.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the inward default, that the outer bounding box is preserved, that material is removed inside, and the return contract. It does not cover failure modes or prerequisites like requiring a closed solid, so it is not perfect, but it is notably 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?

Three sentences with no wasted words. The purpose is front-loaded, the key input instruction follows, and the default behavior plus return contract close it out efficiently.

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 8 parameters, no annotations, and no output schema, the description covers the core semantics well: what the tool does, which faces to remove, default direction, and what is returned. Some edge-case behavior is left unspecified, but the essential agent guidance 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 coverage is 100%, so the baseline is 3. The description mostly restates faceIds semantics already in the schema, adding only the list_entities source and the return contract, which is not parameter-level detail. It adds marginal value but does not substantially extend 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 opens with a specific verb and resource: "Hollow out a solid body into a thin-walled shell." It clearly differentiates this from siblings like create_thicken and create_extrude by explaining the face-removal mechanism and the resulting wall behavior.

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 provides clear operational guidance: pass face IDs from list_entities, remove those faces, keep the rest as the wall, and inward is the default. It lacks explicit exclusions or named alternatives, but the context makes the primary use case 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?

With no annotations provided, the description carries full behavioral burden and succeeds: it discloses atomicity, faceId precedence, silent short_arc endpoint swapping, required circle/arc seeds, unit handling, constraint aliases, the absence of a magic origin keyword, and the origin-pinning pattern. These are exactly the non-obvious behaviors an agent needs.

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 long, but its length is earned by the tool's complexity. It is well-structured with headers, bullets, and examples, and front-loads the most important decision first: which sketch-creation surface to use. Every section addresses a real invocation concern.

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 highly complex tool with 8 parameters, no output schema, and no annotations, the description covers all invocation-relevant details: entity shapes, constraint formats, units, gotchas, origin anchoring, and mode selection. The only minor omission is an explicit statement of the return value, but this does not undermine completeness for correct invocation.

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

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

Although the schema already has 100% parameter-coverage, the description vastly expands meaning: per-type entity field schemas, sub-point entity refs, constraint type semantics, dimension value units, direction enums, and alias mappings. The schema only names parameters; the description explains how to use them correctly.

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 a specific verb and resource: 'Create ONE sketch feature atomically.' It clearly distinguishes this general sketch-creation tool from the single-primitive sibling tools (create_sketch_rectangle, create_sketch_line, etc.) by covering all entities in one feature, and from edit_sketch by being a create 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 clear usage context for both modes: coordinate-first is 'for simple sketches' and constraint-first is 'for drawing transcription.' It also specifies plane vs faceId selection and precedence. However, it does not explicitly call out when to use the single-primitive sibling tools instead, so it stops short of full alternative routing.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It does disclose one important behavioral rule: `faceId` takes precedence over `plane`, which helps the agent avoid a common mistake. However, it does not describe side effects, whether this creates a standalone sketch or adds an arc to an existing sketch, default behavior when neither surface is provided, or what the agent should expect in the response. The precedence detail is valuable, but overall behavioral coverage is thin.

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 three short sentences with no filler. The purpose is front-loaded in the first sentence, and the second and third sentences compactly convey the surface-selection guidance and precedence rule. 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 100% schema coverage compensates for most parameter-level gaps, making the description workable as a minimal definition. However, for a 14-parameter CAD mutation tool with no annotations and no output schema, the description leaves ambiguity about the sketch lifecycle: does it create a brand new sketch containing an arc, or does it add an arc to an existing sketch? It also gives no indication of return values or follow-up actions. This is adequate but not 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 schema description coverage is 100%, and the input schema already documents every parameter with units, defaults, enum values, and constraints. The description adds only the relationship between `plane` and `faceId`, which is useful but largely redundant with the schema's `faceId` property description. Per the baseline for high schema coverage, the description does not need to repeat parameter details, and it does not do so.

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 a direct verb+object, 'Create an arc sketch', which states exactly what the tool produces and distinguishes it from sibling sketch tools like create_sketch_circle, create_sketch_line, and create_sketch_rectangle. The resource type is specific and recognizable, so an agent can identify the tool's role without inspecting 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 description gives concrete guidance for the main surface-selection ambiguity by telling the agent to pass either `plane` or `faceId`, and explicitly states the precedence rule (`faceId` wins when both are given). It also tells the agent where to obtain `faceId` (from `list_entities`). It does not explicitly compare this tool to alternative sketch-creation siblings or list prerequisites, but the context it provides is clear and actionable.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only restates the faceId-wins precedence and the list_entities source, both of which already appear in the input schema. It does not mention whether the tool creates a new sketch or adds to an existing one, what it returns, or other side effects such as variable constraints beyond the schema descriptions.

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 three short sentences with the core purpose front-loaded, followed by surface-selection guidance and the precedence rule. There is no filler or unnecessary prose; the structure makes the most important information immediately visible.

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 rich schema covers all 12 parameters, defaults, units, and legacy fields, so invocation details are well supported. However, with no output schema and no annotations, the description omits tool-selection context versus other sketch creators, the return value, and whether the circle is created in a new sketch or an existing one. These are moderate gaps, but the schema prevents the definition from being inadequate.

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 parameter descriptions are detailed, covering defaults, units, legacy alternatives, and variable-driven behavior. The description adds no new parameter meaning—it rephrases the plane/faceId relationship already documented in the schema. Therefore 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 first sentence, 'Create a circular sketch,' clearly states the verb (create) and resource (circular sketch), and the word 'circular' differentiates it from sibling rectangle, line, and arc sketch tools. The surface-selection instruction reinforces what the tool operates on. The core function is unambiguous.

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

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

The description gives no explicit comparison to siblings such as create_sketch_rectangle, create_sketch_line, or generic create_sketch, so tool selection is left mostly to inference from the name. It does provide within-tool guidance on choosing plane vs faceId, which is useful but is not the same as saying when to use this tool instead of alternatives. Usage context is implied, 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?

No annotations are provided, so the description carries the full burden. It discloses the faceId-over-plane precedence and the surface-selection options, but does not state whether the operation mutates the document, what side effects occur, what permissions are needed, or what the response contains. For a creation/mutation tool this is a notable 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 with no filler. The core action is front-loaded, and the ambiguous surface-selection behavior is addressed immediately. 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?

With no annotations and no output schema, the description is somewhat thin. It adequately covers surface selection, but omits default behavior details, mutation implications, and return-value expectations. The schema fills the parameter documentation gap, so the description is just adequate for a tool of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only the faceId-wins precedence, which is already present in the schema's faceId parameter description, and the list_entities source for faceId, also already in the schema. It does not materially enrich parameter 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 states a clear action ('Create a line sketch') and identifies the resource. It is distinguishable from siblings like create_sketch_rectangle or create_sketch_circle, though it does not explicitly name those 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 description explains how to choose a sketch surface (plane vs faceId) but provides no guidance on when to select this tool over sibling sketch-creation tools such as create_sketch, create_sketch_rectangle, or create_sketch_circle. Tool-selection context is absent.

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 the precedence behavior and warning, but does not clarify whether the rectangle is added to an existing sketch or creates a new sketch, nor what happens with the optional variable names. Since there are no annotations, more behavioral detail would be expected, but the core behavior is partially addressed.

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 concise, using only a few sentences to convey the purpose and location options. It is well-structured with clear separation between purpose and usage guidance, with no unnecessary verbosity.

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 key aspects needed to invoke the tool, including location and precedence. However, it does not mention what happens after creation (e.g., whether a new sketch entity is produced or appended to an existing one) or the effect of variableWidth/variableHeight. These are minor gaps given the schema already documents parameter meanings.

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?

Every parameter is described in the schema, and the description enhances understanding with details like unit conventions for corner coordinates and the mutual exclusivity of plane and faceId. The descriptions are precise and cover all inputs.

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 creates a rectangular sketch in a Part Studio, and distinguishes it from sibling tools for circles, lines, and rounded rectangles. The purpose is unambiguous and action-oriented.

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 explains the two location options (plane and faceId), when to prefer faceId, and the precedence rule if both are provided. This gives clear guidance on how to choose between them, fulfilling the usage guidance requirement.

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

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

With no annotations, the description carries the burden for behavioral disclosure. It provides valuable behavior specifics: positive travel moves the first instance along the face normal away from the second, swapping instance order reverses slide direction, and optional offsets shift connectors from face centers. These are not expressed in the schema and help the agent predict side-effects. It does not mention return behavior or permissions, but for a creation tool the behavioral details are highly relevant and unusually explicit.

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 compact and each sentence earns its place: purpose, direction semantics, instance-order tip, prerequisite, and offset behavior. The main purpose is front-loaded, and there is no filler or repetition of schema content.

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 16-parameter tool with no output schema, the description covers the areas that are hardest for an agent to infer: how instance ordering determines direction, where face IDs come from, and what offsets do. The schema handles the actual parameter formats, so the description is complete enough for selection and invocation. Missing details like whether min/max limits affect connector positions or what the output represents are not stated, but the core usage context 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 coverage is 100%, so the parameters are already described. The description adds meaning beyond the schema by clarifying that face IDs come from Part Studio body details, that instance order controls slide direction, and that offsets shift connectors from face centers. This is meaningful semantic enrichment rather than repetition.

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 a specific verb and resource: 'Create a slider (linear motion) mate between two assembly instances.' It explicitly calls out the linear-motion type, which differentiates it from sibling mate tools like create_fastened_mate, create_revolute_mate, and create_cylindrical_mate even without opening their schemas.

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: it is for linear-motion mates, explains that first instance slides relative to the second, and gives a prerequisite: 'Requires face IDs from Part Studio body details.' It does not explicitly name alternatives or describe when not to use this tool, so it falls short of a 5, but the linear-motion framing plus the prerequisite is strong, actionable guidance.

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

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

No annotations are present, so the description carries the full burden of disclosing side effects and behavior. It only says 'create,' implying a document-mutating operation, but does not state that a feature is added to a Part Studio, whether the operation is reversible, how operationType affects the geometry, or how failures manifest. This is a significant transparency 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 one-sentence description is terse, front-loaded, and free of filler, which makes the core purpose immediately clear. It is appropriately concise for a basic statement of intent, though the saved space could have been used for usage or behavioral guidance. Overall, the structure is efficient rather than bloated.

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 having 10 parameters, no annotations, and no output schema, the description provides only the core purpose. It omits when-to-use guidance, expected results, and relationships to alternatives such as create_extrude or create_shell. This is not complete enough for an agent to confidently invoke the tool in a complex CAD 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%, and every parameter already has a meaningful description, including units for thickness, the operationType enum, and boolean behaviors. The description adds almost no parameter-level meaning beyond confirming the sketch as the feature source. Baseline 3 is appropriate because the schema carries the semantic load.

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 ('create a thicken feature') and identifies the input ('from a sketch'), making the tool's function unambiguous. This differentiates it from sibling creation tools like create_extrude or create_revolve without requiring schema inspection. It is not merely a restatement of the tool name.

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 guidance on when to use this tool versus alternatives. It does not state prerequisites, such as needing a valid closed sketch, nor does it mention scenarios where another feature-creation tool would be more appropriate. An agent must infer usage entirely from the tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that this is a creation operation, that it returns a new Variable Studio element id, and that it must precede set_variable. It does not cover edge cases like duplicate names or failure modes, but the core mutating behavior and follow-up usage are transparent enough for a simple create 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 three sentences with no filler. The first sentence states the operation, the second gives the key prerequisite and context, and the third explains the return value and usage. Every sentence earns its place and the most critical information is 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?

There is no output schema, so the description correctly and explicitly explains the return value: 'Returns the new VS element id.' It also covers the prerequisite relationship with set_variable and the legacy read-only limitation, making the tool actionable without needing to inspect other definitions.

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 even without extra parameter detail in the description. The description does not add meaning beyond the schema for name, documentId, or workspaceId, but it does explain the output and sequencing rather than parameter formats, which is acceptable given the schema already documents each parameter.

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

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

The description uses a specific verb and resource: 'Create a Variable Studio element in a workspace.' It also distinguishes this tool from related siblings by explaining it is required before set_variable on modern docs and that the legacy Part Studio write path is read-only, so an agent can tell it apart from create_part_studio or set_variable.

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 states when to use this tool: 'Required before set_variable on modern Onshape docs.' It also explains why alternatives are not viable ('the legacy Part Studio /variables write path is read-only') and tells the agent to use the returned elementId with set_variable/get_variables, giving clear routing and sequencing guidance.

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

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

With no annotations, the description carries the full burden. It discloses the coordinate system, the non-destructive nature via a new image_id, and that the input must be a cached image. It does not detail invalid-region behavior, but the schema covers ordering constraints.

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 operational content is front-loaded and efficient. The trailing benchmark claim about CharXiv is motivational rather than functional, and 'use it liberally' is more style than substance, so it does not fully earn 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 5-parameter tool with a complete input schema, the description covers the when, the coordinate semantics, the source image requirement, and the return behavior. The lack of an output schema is mitigated by explicitly stating that a new image_id is returned.

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 explaining the normalized 0..1 bounding-box concept and explicitly stating that (0,0) is top-left and (1,1) is bottom-right, which helps an agent reason about x1/y1/x2/y2.

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 operation: zoom into a cached image by normalized 0..1 bounding box. It also clearly ties the tool to the render_* workflow by positioning it as the follow-up step for inspecting details like faces, edges, or fillets.

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 says to use after render_* when inspecting a detail, and even encourages liberal use. It does not enumerate when not to use it or name alternative zoom/recrop approaches, but the guidance is clear and actionable.

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 clearly warns that deletion is irreversible and indicates it returns a status object. Without annotations, it still conveys the destructive nature and basic side effect, though it does not mention permission requirements or cascading 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 two concise sentences with no redundant wording. It packs the action, intent, irreversibility, and return value efficiently.

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-complexity delete operation, the description fully covers what the tool does, why it is used, its irreversibility, and the return shape. No output schema is provided, but the description supplies the essential return fields.

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 parameter documentId is described in both the schema and description as the ID of the document to delete, so the description adds little beyond the schema. No extra detail is provided about the expected format, source, or required ownership.

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 the tool moves an Onshape document to the trash, distinct from deleting features or other entity-specific operations. The cleanup intent also differentiates it from document creation and search 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?

Explicitly says it is intended for cleanup of throwaway documents created by an agent, giving a clear usage context. It does not explicitly mention alternative tools, but the cleanup intent is enough to guide 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the deletion is permanent, whether permission is required, whether dependent features are affected, or what happens to the model afterward. 'Delete' implies destruction but the description adds no practical behavioral context.

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 filler and places the core action first. It is concise, though it could have used the available space to add sibling differentiation or behavioral notes without much cost.

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

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

For a destructive mutation tool with no annotations, no output schema, and a closely related sibling 'delete_feature_by_name', this description is under-specified. It does not explain how featureId relates to the deletion workflow, warn about irreversibility, or distinguish this tool from its sibling, leaving important context to inference.

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 input schema already documents all five parameters, including the elementType enum. The description adds little parameter-level meaning beyond confirming the target is a Part Studio or Assembly, which is the baseline expectation given 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?

The description states a specific verb ('Delete') and resource ('a feature from a Part Studio or Assembly'), making the core operation clear. However, it does not differentiate this tool from the sibling 'delete_feature_by_name', so an agent must inspect the schema to know that this variant deletes by feature ID.

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 'delete_feature_by_name' or any other alternative. The description only implies the target context (Part Studio or Assembly), but does not state prerequisites, exclusions, or conditions favoring a sibling 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the tool returns an ERROR when zero or multiple features match, which is important for a name-based delete. However, it does not mention the destructive/permanent nature of deletion, potential impact on dependent features, or any permission requirements, leaving notable behavioral 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?

The description is two sentences with no filler. The primary purpose is front-loaded, followed by a concrete example, and the important error-disambiguation behavior is stated efficiently. 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 deletion tool with four standard identifier parameters and no output schema, the description covers the main invocation concerns: target resource, selection by name, and failure behavior on ambiguous or missing matches. It does not describe success return values or irreversibility, but the core call behavior is sufficiently specified for an agent to use 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?

The input schema already documents all four parameters with 100% coverage, including that 'name' is exact and case-sensitive. The description adds helpful examples and clarifies that 'name' refers to the display name rather than the feature ID, but it does not substantially extend the parameter-level 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 uses a specific verb ('Delete') with a specific resource ('Part Studio feature') and a precise selection mechanism ('by its display name'). It clearly distinguishes this tool from the sibling delete_feature, which presumably operates by feature ID, by explicitly calling out that no ID lookup is needed.

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 to use the tool: when the caller has a feature's display name rather than its ID. It implies the alternative (look up the feature ID and use delete_feature) but does not explicitly name it or state exclusions, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the burden, and it does a strong job: it discloses the composite return (feature tree, body topology with deterministic IDs, bounding box, mass properties, multiple images), notes that image_ids can be fed to crop_image, and explains the intended division of labor between text and images. It stops short of stating non-destructiveness, cost/performance characteristics, or failure modes, which keeps this from a 5.

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

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

The description is compact and front-loaded: purpose, output contents, routing rule, and an integration tip (crop_image) each occupy one purposeful sentence. There is no filler or repetition of schema fields beyond the useful default-view note.

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

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

Given there is no output schema and no annotations, the description supplies enough context to predict the response shape (text facts plus image_ids), understand why both are useful, and know how to continue the workflow with crop_image. It is still missing information about the cost/weight of a one-shot snapshot and any failure/error behavior, but the core invocation context is solid.

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 only 33% (views and elementId are described), yet the prose adds little parameter-level meaning: it echoes the default view set and mentions rendered images, but never clarifies documentId, workspaceId, renderWidth, or renderHeight. For a 6-parameter tool with three required IDs, the low schema coverage should have been compensated in the description.

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

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

The first sentence names a specific verb ('snapshot') and resource ('Part Studio's entire design state'), and the description enumerates what is returned: structured text plus rendered images. It also implicitly differentiates from siblings by naming get_features, list_entities, render_part_studio_views, and get_mass_properties, so a model can tell this aggregate tool apart.

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 explicit routing guidance: 'Use this INSTEAD OF chaining get_features + list_entities + render_part_studio_views + get_mass_properties after every mutation.' This tells an agent exactly when to pick this tool over the alternatives and identifies the sibling tools to avoid chaining.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses mutation mechanics, strict ID uniqueness requirements, the need to remove before re-adding an id, and the cascade behavior that auto-drops constraints referencing removed entities. It also names the `cascaded_removals` response signal so the agent knows what to expect.

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 organized into four dense paragraphs, each with a distinct job: general purpose, usage scenario, add semantics, and removal/cascade semantics. It is front-loaded with the core purpose and contains no filler or redundant restatement 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?

Given the tool's complexity, full parameter coverage, and absence of an output schema, the description is unusually complete. It explains what happens server-side, what constraints the caller must satisfy, and how cascaded deletions are surfaced. An agent has enough information to select and 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that any subset of `addEntities`, `addConstraints`, or `removeIds` can be passed, describes strict id semantics, and clarifies that `removeIds` matches both entity and constraint ids with cascade effects. This is material guidance the schema alone does not provide.

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 a precise verb and resource: 'Iterate on an existing sketch without rebuilding it.' It goes on to explain the mechanism (fetch current BTMSketch, splice lists, re-POST), which clearly differentiates this from create_sketch or delete+recreate.

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: for second/third passes like 'adding a hole pattern after the outline lands' or 'tightening a constraint after a regen check.' It also names the alternative workflow it replaces, 'delete+recreate', giving clear selection guidance.

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

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

With no annotations present, the description carries the full burden. It mentions 'read-only' which is a behavioral trait, but does not detail error handling, side effects, or permission requirements.

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

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

The description is extremely concise and to the point, conveying the essential functionality without any unnecessary words or formatting issues.

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?

Since there is no output schema, the description could have mentioned what the evaluation returns, but the simple nature of the tool and the 'querying geometry' hint make it adequate. However, it lacks explicit details about expected 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?

The schema provides descriptions for all parameters, so schema coverage is 100%. The tool description adds no extra meaning beyond the schema, hence the baseline score 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 clearly states the tool evaluates a FeatureScript expression in a Part Studio, with a specific verb and resource. It distinguishes itself from the sibling 'write_featurescript_feature' by noting its read-only 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?

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'read-only, for querying geometry' provides some context but does not name or compare with other tools.

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

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

With no annotations, the description carries the full behavioral burden. It discloses blocking behavior, the destination directory (/tmp/onshape-mcp-exports/), and the returned fields (path, size, final state). It does not mention permissions, cleanup, or whether the operation is read-only, but this is acceptable coverage for an export.

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 concise at two sentences, front-loaded with the core purpose, and every sentence adds meaningful behavior information. There is minor redundancy in naming the write path and return fields, but overall it is appropriately sized and well-ordered.

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 that there is no output schema and no annotations, the description explains the main behavior and return fields, which is good. However, it lacks any differentiation from the sibling export_part_studio, does not clarify the meaning of 'final state', and leaves potential edge cases unaddressed. It is adequate but not fully complete for an agent selecting between many related tools.

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 each parameter. The description adds that the tool blocks and waits for translation, which gives context for timeoutSeconds and pollIntervalSeconds, but it does not significantly expand beyond the schema's existing parameter descriptions.

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

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

The description clearly states a specific action ('Export an Assembly to STL, STEP, or GLTF') with a distinct resource and formats. It is unambiguous on its own, though it does not explicitly distinguish itself from the sibling export_part_studio tool.

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 wording 'Export an Assembly' implies the intended use case but provides no explicit guidance about when to choose this tool over export_part_studio or any other alternative. No exclusions or when-not-to-use conditions are given.

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

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

With no annotations, the description carries the full burden and does so well. It discloses blocking behavior, the download and filesystem side effect, the exact output directory, returned path/size/state, and explicit error behavior on FAILED or timeout. This is far beyond what the schema alone provides.

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 purposeful sentences with no filler. The core purpose and formats come first, followed by behavioral details, return information, and error handling. 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 tool with no output schema and no annotations, this description is well-rounded: it states side effects, output location, return values, and failure modes. Combined with the 100% schema coverage for parameters, an agent has everything needed 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 coverage is 100%, so the baseline is 3. The description adds value by explaining why timeoutSeconds and pollIntervalSeconds exist ('Blocks until Onshape finishes the translation... Raises an explicit error on FAILED or timeout') and by clarifying the meaning of the downloaded artifact, so it earns 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 opens with a precise verb and resource: 'Export a Part Studio,' then enumerates the supported formats (STL, STEP, PARASOLID, GLTF, OBJ). This clearly distinguishes it from the sibling export_assembly tool and tells an agent exactly what the operation produces.

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 clearly scopes the tool to Part Studio exports and gives practical context: it blocks, downloads, and writes to /tmp/onshape-mcp-exports/. It does not explicitly tell the agent to use export_assembly for assemblies, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states what the tool returns, that it relies on OCR, and its known failure mode ('Ø often misreads as ‘9’'), and even instructs how to mitigate that limitation. This is unusually 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?

The description is compact, front-loaded with the core behavior, and every sentence adds value: the output shape, the pixel-position mapping, the usage priority, and the known OCR limitation. The all-caps precaution is effective without bloating the text.

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

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

Even without an output schema, the description tells the agent what the result will contain (grouped callouts with pixel positions) and how to use it (map to features, cross-check important dimensions). For a one-parameter read tool, this fully covers selection and invocation 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?

Schema description coverage is 100% and the sole parameter imagePath is already documented as a filesystem path to a drawing PNG. The description restates 'PNG' but adds no new detail about path format, supported file types, or coordinate conventions. Baseline 3 is appropriate since 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 names a specific verb ('OCR'), a resource ('drawing PNG'), and the exact output ('numeric callouts grouped by kind: length / radius / diameter / thread / angle / count / scale'). It also clarifies that callouts include pixel positions, making it easy to distinguish from sibling image tools like crop_image or render_*.

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 tells the agent when to use this tool ('USE THIS BEFORE READING DIMS BY EYE') and why (Tesseract is more reliable than a vision pass on small text). It also names an alternative for follow-up verification ('cross-check high-significance dims with crop_image at native resolution').

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly implies a read-only search operation and mentions optional name filtering, but does not explicitly state that it makes no modifications or describe any result format or potential pagination.

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. The key scoping information (workspace, filtering by name) is front-loaded, and every word contributes to the meaning.

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

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

The description is adequate for a simple lookup tool, but there is no output schema and no explanation of what the returned elements look like. Ambiguity around whether 'Part Studio elements' means Part Studio tabs or elements inside a Part Studio also remains unresolved.

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 only reinforces the existing namePattern filtering concept without adding substantial new 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 clearly states a specific action ('Find'), a resource ('Part Studio elements'), and a scope ('in a specific workspace, optionally filtered by name'). It conveys the core purpose adequately, though it does not explicitly contrast with siblings like get_elements or describe_part_studio.

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 about when to use this tool versus alternatives such as get_elements or search-related siblings. The description implies a narrow use case but never states exclusions or preferred conditions.

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

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

No annotations are present, so the description is the sole safety signal. The verb 'Get' clearly conveys a read/query operation and explicitly mentions the returned content (instances and occurrences), but it does not disclose whether the result is hierarchical, flat, or includes additional details like transforms.

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 with no filler, and every word contributes to the core meaning. It is concise, though slightly terse to the point of omitting useful contextual details.

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 call itself is simple, with three required ID parameters, and there is no output schema. The description gives a reasonable high-level understanding of the result, but it falls short of fully specifying the return structure or the exact meaning of 'instances and occurrences.'

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 documented in the schema at 100% coverage, so the schema already carries the semantic burden. The description adds no additional meaning or context for the IDs beyond what the schema provides, warranting the baseline score.

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 the verb 'Get' with a specific resource: 'assembly structure including instances and occurrences.' This meaningfully distinguishes it from sibling tools like get_assembly_positions or get_assembly_features, though the term 'structure' remains somewhat abstract.

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, no exclusions, and no mention of related tools with overlapping functionality. An agent must infer usage purely from the name and generic phrasing.

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

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

With no annotations, the description must carry behavioral disclosure. It communicates that this is a read-only retrieval operation ('Get'), specifies the state dimension of returned features, and highlights diagnostic value. It does not mention edge cases or side effects, but nothing in the description suggests mutation or hidden 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?

The description is two sentences, front-loaded with the core action and resource, then adds a practical use case. Every clause earns its place without 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?

The tool is simple with three required, well-described parameters and no output schema. The description adequately conveys what is returned (features and their states) and why it is useful. It could be slightly more precise about the full structure of the returned data, but for the intended inspection/debugging use case it is sufficient.

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 already documented in the schema with clear descriptions, providing 100% coverage. The description does not add additional semantic detail about parameters beyond implying the assembly context, 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 clearly states the operation: get all features from an assembly, with a specific output of current state values (OK, ERROR, SUPPRESSED). It names the resource type (assembly features) and includes example feature kinds (mates, mate connectors), which distinguishes it from the more generic sibling 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?

The description gives clear context for when to use it: 'inspecting existing mates and debugging assembly issues.' It does not explicitly name alternatives or exclusions, but the intended use case is concrete enough to guide an 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?

No annotations are provided, so the description carries the burden of disclosing behavior. It usefully states the world-space coordinate context and the mm unit, but it does not state that this is a read-only operation, what happens for empty or invalid assemblies, or the response format.

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 entire description is a single well-structured sentence that front-loads the action and result, then adds the important unit qualifier. There is no wasted 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-style tool with three clearly documented parameters, the description gives enough to call it correctly: scope, result contents, coordinate space, and units. The lack of an output schema and any error/empty-assembly behavior is a minor gap, not a blocking one.

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 clear definitions for documentId, workspaceId, and elementId. The tool description adds no parameter-level detail 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 uses a specific verb ('Get') with a clear resource ('positions, sizes, and world-space bounds of all instances in an assembly') and adds units. It distinguishes this tool from siblings like get_assembly or get_bounding_box by explicitly scoping it to all assembly instances.

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 when an agent needs instance geometry transforms within an assembly, but it provides no explicit guidance on when to prefer this tool over alternatives like get_bounding_box, transform_instance, or get_assembly. No exclusions or alternatives are named.

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

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

No annotations are provided, so the description carries the full disclosure burden. It clearly discloses the output scope ('all parts'), the key identifiers returned, and the conditional planar-face data, while the 'Get... Returns' phrasing implies a read-only operation. It does not mention coordinate frame, units, or response packaging, but for a non-destructive query tool this is reasonably 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?

The description is three sentences with no filler. The first sentence states the operation, the second specifies the return payload, and the third gives the practical downstream use. Every sentence earns its place, and the most distinguishing information is 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 tool with three standard ID parameters and no output schema, the description gives a solid contract of what is returned and why it matters. It is missing the response structure and coordinate system context for the normal/origin values, which would be useful, but the tool is simple enough that the description is still 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?

Schema description coverage is 100%, so the schema already documents documentId, workspaceId, and elementId adequately. The description adds little beyond labeling the element as a Part Studio, which is helpful but not substantive new parameter semantics. 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 opens with a specific verb+resource: 'Get face-level geometry details for all parts in a Part Studio.' It goes beyond a generic label by enumerating the returned data (face deterministic IDs, surface types, planar normals and origins), which clearly differentiates it from part-level tools like get_parts and more specific ones like get_face_coordinate_system.

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 a use case by stating 'Use face IDs with mate connector tools,' which tells the agent the downstream purpose of the output. However, it does not explicitly state when to choose this tool over alternatives such as get_parts or get_face_coordinate_system, nor does it give exclusions or conditions.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states what the tool returns conceptually, but does not mention units, coordinate frame, axis-aligned versus tight box details, read-only nature, or behavior with hidden/empty parts. It is not misleading, but it is thin.

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?

Single sentence with no filler. It front-loads the action and object, and every word contributes to meaning.

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

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

There is no output schema and no annotations, so the description should explain what the response looks like (e.g., bounding box corners, units, coordinate system). It does not, leaving an agent uncertain how to consume the result. The required IDs are fully documented in the schema, but the output side is incomplete.

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

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

Schema coverage is 100% and the parameters (documentId, workspaceId, elementId) already have plain descriptions in the schema. The description adds no extra parameter context, which is acceptable given the 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?

Description clearly names the action ('Get') and the resource ('tight bounding box of all parts in a Part Studio'). It is specific enough to convey the core intent, though it does not differentiate itself from related siblings like get_body_details or measure.

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 measure, get_mass_properties, or get_body_details. There are no exclusions, prerequisites, or conditions stated, so the agent must infer usage 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Get detailed information' without stating whether this is a read-only operation, whether it has side effects, or any additional behavioral context beyond the obvious.

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 with no redundant words. It efficiently conveys the tool's purpose without 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?

Given the simple input and lack of output schema, the description is adequate for basic understanding. However, it could be more complete by specifying what 'detailed information' entails (e.g., metadata, properties, sketches), especially considering the variety of document types implied by sibling tools.

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 covers 100% of the single parameter (documentId) with a description 'Document ID'. The tool description adds no further meaning beyond the schema, 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 states the verb 'Get' and resource 'document', with 'detailed information' implying a comprehensive retrieval. It distinguishes from siblings like get_document_summary and list_documents by suggesting more depth, though it could be more explicit about what 'detailed' includes.

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 list_documents, search_documents, or get_document_summary. There is no mention of scenarios or trade-offs.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It indicates a read operation but does not clarify what a 'comprehensive summary' actually contains, whether it aggregates data, how large the response might be, or whether any side effects or limitations apply.

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 with no filler. It communicates the core purpose efficiently, though the word 'comprehensive' is vague and could be replaced with more specific detail without harming conciseness.

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 annotations, the description should explain what the tool returns and how an agent should interpret the result. It only says 'comprehensive summary' and that workspaces and elements are included, leaving the exact return structure and meaningful distinctions from other getters unexplained.

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

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

The input schema already provides 100% coverage by describing documentId as 'Document ID', so the baseline is 3. The description adds no additional meaning about the parameter, but none is really needed for such a simple single-parameter tool.

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 verb 'Get' and the resource 'comprehensive summary of a document', and adds scope with 'including all workspaces and elements'. It is understandable and distinct from a plain document fetch, though it does not explicitly differentiate it from sibling tools like get_document or get_elements.

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 get_document, get_elements, or list_documents. The description does not mention scenarios, exclusions, or relationships to sibling tools, so an agent must infer when this summary is the right choice.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only says it returns elements and does not mention whether the response is paginated, how the elementType filter behaves, whether unsupported types are ignored or error, what fields each element contains, or how the result relates to element IDs used by other tools.

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, readable sentence that front-loads the main action and resource. It is concise, though it slightly underspecifies behavior; still, no filler or repetition exists.

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 annotations, the tool is moderately complex: it may return heterogeneous element types and supports an optional filter. The description does not explain the return structure, pagination, or relationship between element types and the optional filter, leaving an agent to guess at important invocation and interpretation details.

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 three parameters. The description adds a little context by naming example element types and clarifying that elementType is an optional filter, which aligns with the schema's wording but does not add significant new meaning beyond it.

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 ('Get') and resource ('all elements') within a workspace, listing examples like Part Studios and Assemblies. However, it does not clearly distinguish itself from sibling tools such as find_part_studios or get_parts, which could overlap in an agent's decision-making.

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 for fetching broad element lists from a workspace, but it provides no explicit guidance on when to choose it over find_part_studios, get_features, or get_assembly. No alternatives are named and no exclusion criteria are given.

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

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

There are no annotations, so the description carries the burden of explaining behavior. It discloses that the tool queries, returns a guaranteed outward normal, tangent axes, and origin, and claims improved reliability over body details normals. The 'Query' framing strongly implies a read-only operation, though it does not explicitly state side-effect absence or error 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?

The description is three concise sentences with no filler. It front-loads the core purpose, then gives the return contents, a reliability comparison, and a concrete use case. Every sentence contributes useful information.

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

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

With no output schema, the description compensates by naming the returned elements (normal, tangent axes, origin) and the intended usage context. It could be slightly more explicit about the coordinate frame's reference or failure cases, but it is sufficient for an agent to understand what to expect and why to call 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?

The input schema already has 100% coverage with individual descriptions for all five required parameters. The tool description adds no additional parameter-level detail, so it stays at the baseline without needing to compensate for schema gaps.

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 specific action ('Query'), the exact resource ('outward-facing coordinate system for a face on an assembly instance'), and enumerates the returned values (Z-axis, X/Y axes, origin). It also distinguishes itself from the sibling get_body_details by claiming greater reliability for normals.

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 an explicit use case: 'Use this to verify face orientations before creating mates.' It also contrasts with body details normals as an alternative. It does not explicitly state when not to use the tool, but the context and comparison provide clear practical guidance.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Get', implying a read operation, but does not explicitly mention safety, side effects, or response characteristics. This is a significant gap given the absence of 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 a single concise sentence with no fluff, front-loading the action. However, it is under-specified for a tool with no output schema, though the conciseness itself is 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?

The tool has no output schema and no annotations, so the description should explain return values and any limitations. It only states the action, leaving out response details, error conditions, and the exact scope of 'features'. This is incomplete for an agent to call 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 coverage is 100%, with each parameter documented (elementId, documentId, workspaceId). The description adds no additional parameter meaning beyond the schema, so it meets 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 'Get all features from a Part Studio', providing a specific verb and resource. It distinguishes from siblings like get_parts and get_assembly_features by targeting features within a Part Studio, though it does not elaborate on what constitutes a 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?

No guidance is provided regarding when to use this tool versus alternatives such as get_elements or get_parts. The description gives no context on selection criteria, 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?

With no annotations, the description carries the disclosure burden. It usefully reveals that values come as [min, mean, max] uncertainty triples, that mass is zero without a material, and that volume/centroid are always meaningful. It stops short of covering units, coordinate frames, or error 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?

Three compact sentences with no wasted words. The main result and scope are front-loaded, and the additional caveats are concise and valuable.

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 no output schema and no annotations, the description covers the essential return content and key caveats well enough for an agent to invoke the tool and interpret results. It omits minor details like units and exact response shape, but these are not critical blockers.

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 already documents partId and elementId, and the description mostly reinforces partId's optional filtering role. documentId and workspaceId are not described in the schema, but their purpose is reasonably inferable from the Part Studio context. This partial compensation earns a middle score.

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 resource (Part Studio bodies) and explicitly lists the returned quantities (volume, mass, center of mass, principal inertia, bbox). It also clarifies scope variation via partId, making it easy to distinguish from geometry/measurement 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?

Clearly implies when to use the tool: when mass properties are needed for all bodies or a specific part. It gives good contextual guidance about supplying partId, but it does not explicitly name alternatives or exclusion conditions.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read-only fetch operation and the scope of what is returned ('all parts'), but it does not mention what part data is included, whether there are filtering limitations, or how the results are structured.

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 states the action and target clearly with no wasted words. It is appropriately sized for a simple getter 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?

The description is adequate for a straightforward fetch operation and correctly identifies that the target must be a Part Studio element. However, with no output schema and no mention of return value shape or limitations, an agent has only a minimal understanding of what result to expect.

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 described in the input schema with 100% coverage, so the schema carries the parameter documentation burden. The description adds no additional semantic detail beyond what the schema already provides.

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

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

The description clearly identifies the operation ('Get all parts') and the target resource ('a Part Studio element'), making the tool's purpose easy to understand. However, it does not explicitly distinguish itself from sibling tools like get_elements or describe_part_studio, which also operate on documents and elements.