fusion-reconstruct-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct aspect: mesh analysis (planar facets, holes, cross-sections) vs CAD operations (sketch, extrude, fillet, patterns). Even the two circle-related tools (find_circular_holes vs find_circular_faces) are clearly differentiated by boundary vs full-face detection. No ambiguous overlaps.
Naming Consistency4/5The Fusion-specific tools consistently use the 'fusion_' prefix with verb_noun patterns (e.g., fusion_create_sketch, fusion_add_fillet). Mesh tools lack a prefix but share a similar snake_case descriptive style. Minor deviation: 'mesh_summary' and 'fusion_ping' don't follow the verb_noun convention, and the two groups have different prefix conventions.
Tool Count2/534 tools is well beyond the 15-25 range considered heavy. While the complexity of CAD reconstruction justifies many operations, the count is excessive and likely burdensome for an agent to select from. Several tools (e.g., fusion_list_parameters, fusion_fit_view) could be merged or omitted without loss of function.
Completeness5/5The tool surface covers the entire reconstruction pipeline: mesh analysis (facets, holes, cross-sections, solid checks), geometry creation (sketch primitives, profiles, extrude/revolve/loft), feature modifications (fillet, chamfer, patterns, mirror), Boolean operations, shelling, parameter management, and verification (export, compare, screenshots). No obvious dead ends or missing operations for the stated purpose.
Average 3.7/5 across 28 of 34 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. The description provides minimal behavior context beyond the operation itself. It doesn't mention whether the operation is destructive, reversible, requires a document, or other side effects. The only extra context is the edge_selector format reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, two short sentences. The description is not verbose; it's clear and to the point, though it could be seen as under-specified. For the little it says, it's structured appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 3-param tool with nested objects (edge_selector) and no output schema. The description is far too thin. For a CAD operation like chamfer, the agent would need at least an example of the edge_selector format, maybe what units distance_mm expects, and whether it mutates the document. The sibling-reference to fusion_add_fillet helps but is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. Param names are somewhat clear (body_id, distance_mm, edge_selector), but edge_selector is an nested object with no definition, and the description only says 'Same edge_selector format as fusion_add_fillet', which adds some value but leaves the agent to rely on a sibling tool's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it chamfers edges, which is a specific verb+resource. However, the description says 'Same edge_selector format as fusion_add_fillet' and the sibling fusion_add_fillet exists, so it's referring to a known sibling, but not distinguishing it beyond that. It is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, though it implies relationship to fusion_add_fillet. It doesn't explain when to choose chamfer over fillet or other operations, and no prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only adds that the pattern is aligned to the body's own X/Y axes, but fails to mention whether the original feature is kept, how copies are generated, or any side effects. This is insufficient 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently states the core operation and axis alignment, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations and no output schema, this one-sentence description is incomplete. Critical details such as quantity semantics, spacing units, coordinate system implications, and expected outcomes are missing, making correct invocation uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of quantity_x, quantity_y, spacing_x_mm, or spacing_y_mm. It only names feature_id, which duplicates the schema field, and adds no detail about defaults, units, or how the params interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation ('rectangular pattern') and the affected resource ('body/feature produced by feature_id'), and adds directional context ('along the body's own X and Y directions'). This clearly distinguishes it from circular pattern and mirror siblings, though it could be more explicit about creating copies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like fusion_pattern_circular or fusion_mirror. There are no prerequisites, exclusions, or context clues beyond the implicit 'rectangular' in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry behavioral transparency. It implies a mutating operation (adding to a sketch) but doesn't disclose whether it modifies existing geometry, what happens if the sketch doesn't exist, or if the rectangle is axis-aligned. The mention of units (mm) adds some context, but otherwise the behavior is underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is appropriate for conciseness. It front-loads the core action and parameters. However, the extreme brevity borders on under-specification rather than effective conciseness, so a score of 4 reflects efficiency without penalizing should-be-longer content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema or annotations, the description is incomplete. It doesn't explain how coordinates are interpreted (absolute/relative), whether the rectangle is centered or corner-based, or what the return value is. The description only covers the basic action, leaving the agent to guess on critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It mentions 'two opposite corners (mm)', which maps to x1,y1 and x2,y2, but does not clarify what 'sketch_id' is or provide example values. The description adds minimal meaning beyond the bare property names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Add a rectangle to a sketch' using two opposite corners. It distinguishes itself from sibling sketch tools (line, circle) by specifying the rectangle shape and corner-based definition. However, it doesn't explicitly mention the coordinate system or orientation, so it's clear but not fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like fusion_sketch_add_line or fusion_sketch_add_circle. There is no mention of prerequisites (e.g., an active sketch) or scenarios where this tool is preferred. The description only states the what, not the when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It does not state whether the operation is destructive (likely it modifies or replaces existing bodies), whether it returns new bodies, or any side effects on the input bodies. The user must infer the behavior from the schemas (which have no descriptions) and the context of boolean operations. This is insufficient for an agent to understand the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that clearly states the primary behavior and lists the allowed operations. There is no fluff or unnecessary repetition. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of boolean operations on bodies-destructive and requiring clear understanding of parameter semantics-this description is heavily under-specified. There is no mention of return values (since no output schema), no mention of prerequisites (e.g., bodies must overlap), and no explanation of what happens to the original bodies. For a geometry mutation tool, this lacks critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for parameters, and the description only mentions 'operation' with its enum values. It does not explain 'target_body_id', 'tool_body_ids', or 'keep_tools'. With schema coverage of 0%, the agent cannot infer the meaning of these parameters from the description. The description adds little beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs boolean operations on bodies with specific operations (join, cut, intersect). It uses a specific verb ('combine') and names the resource ('bodies'). However, it does not explicitly distinguish from sibling tools like fusion_loft or fusion_revolve, but the boolean nature is clear enough to infer its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, exclusions, or scenarios where other tools might be preferred. The only hint is the operation enum, which implies different use cases, but there is no explicit 'when to use' or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It does not mention side effects (e.g., whether it modifies the document), potential errors (invalid profile, degenerate axis), or the nature of the operation (e.g., whether it creates a new body or cuts). The available parameters (operation, target_body_id) hint at such behaviors, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core functionality without extraneous words. It is well-structured and easy to read, with no redundancy or ambiguity in phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex, involving a revolve operation with multiple parameters (angle, operation, target body). The description only covers the basic revolve action and axis definition, omitting details about how parameters affect the outcome, what the operation does (e.g., cut vs. join), and what the tool returns. Without additional context, a user may not fully understand how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides parameter names but no descriptions. The description adds some context for axis_start and axis_end (two 2D points in the sketch's coordinate system) and mentions units (mm), but it does not explain other parameters like profile_index, angle_deg, operation, or target_body_id. Since schema coverage is 0%, the description should compensate more, but it only partially clarifies the axis parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: revolving a sketch profile around an axis defined by two points in the sketch's coordinate system. It uses a specific verb ('Revolve') and specifies the resource ('sketch profile') and the axis definition, distinguishing it from other modeling tools like extrusion or loft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool over alternatives. It lacks context such as prerequisites (e.g., needing a valid sketch with a closed profile), typical use cases, or comparison with similar tools like fusion_extrude. Users are left to infer when a revolve is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states what the tool returns but does not mention read-only status, error handling for invalid/missing files, or the nature of the sanity-check. This leaves important behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence that front-loads the core information without filler. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and no output schema, the description gives a basic understanding of the return content (size, volume, sanity-check) but lacks details on output structure, specific metrics, or error conditions. It is sufficient for a simple tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter file_path has zero schema description, and schema coverage is 0%. The description partially compensates by indicating the target is an 'STL/3MF file,' which clarifies acceptable file types, but it does not explain path format or access requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (STL/3MF file) and the type of output (size, volume, sanity-check info), making the tool's purpose distinct from siblings like find_circular_holes or get_cross_section. The missing explicit verb is offset by the noun 'summary' which implies a retrieval/analysis operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any indication of exclusions or prerequisites. Sibling tools such as check_solid or compare_meshes are not mentioned, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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. It confirms the operation applies a pattern to the feature's body, but is silent on whether this mutates the document irreversibly, creates new features alongside the original, requires specific document state, or what the return value is. For a state-modifying tool with zero annotation coverage, this is under-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with no filler. It packs purpose, resource scoping, and axis clarification into a compact form. Minor deduction for slightly stilted phrasing, but every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately simple mutation tool with 4 parameters and no output schema, the description covers the core semantics adequately. However, it omits details like the effect of defaults (quantity=4, angle=360), whether the pattern replaces or duplicates the original feature, or what response to expect. Adequate but leaves the agent to infer common behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It does clarify 'axis' (base-plane axis "x", "y", "z") and partially feature_id (the body/feature the pattern is applied to). However, 'quantity' and 'total_angle_deg' are left to their self-evident names/defaults. The description partially compensates for poor schema coverage but doesn't fully close the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation (create a circular pattern) applied to a specific resource (body/feature identified by feature_id) around a base-plane axis. The grammar is slightly awkward ('produced by feature_id'), but it distinguishes reasonably from the sibling fusion_pattern_rectangular. A small deduction for not explicitly contrasting with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied—the name and 'circular pattern' suggest when to use it (vs. rectangular). There is no explicit when-to-use guidance, no mention of preconditions (e.g., the feature must already exist), and no reference to alternatives in the toolset. A sentence about when NOT to use it would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: 'join'/'cut'/'intersect' combine into target_body_id and require it. However, it does not mention side effects like timeline impact, body mutation, or return values. With no annotations, the description carries the full burden and only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded, and free of filler. It conveys the core purpose and a critical parameter constraint in just two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, no output schema, and no parameter descriptions in the schema. The description covers only operation and target_body_id, omitting essential meaning for the required parameters and other options. This is incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the operation enum values and the conditional requirement for target_body_id, but it leaves sketch_id, profile_index, distance_mm, symmetric, and taper_angle_deg completely unexplained. Since schema description coverage is 0%, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Extrude a sketch profile,' which is a specific verb+resource that clearly distinguishes this tool from siblings like fusion_revolve and fusion_loft. It also lists the operation variants, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use extrude versus alternative operations. The description does not mention prerequisites, typical use cases, or situations where another 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.
- Behavior2/5
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 behavioral traits. It mentions 'new, empty', which indicates the document starts fresh, but it does not disclose potential side effects (e.g., whether it replaces a current design), naming behavior, or any required permissions. Given zero annotation coverage, the description provides only minimal insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, directly stating the action and context. It is front-loaded and efficient, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with no output schema, the description provides the core purpose and a hint of usage context ('to reconstruct the part in'). However, it lacks any explanation of the optional parameter and does not describe what the tool returns or how to proceed after creation. While minimal, it is adequate for such a basic tool, but still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—the description does not mention the 'name' parameter at all. The schema lists it as optional with a default of null, but the description adds no meaning about how the name is used or its significance. The description fails to compensate for the low schema coverage, leaving the parameter's purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Create a new, empty Fusion design document' with a specific verb and resource. It is distinct from all sibling tools, which operate on existing documents rather than creating them, so it differentiates itself well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the phrase 'to reconstruct the part in', which implies this is the starting step in a workflow, but it does not explicitly state when to use it versus alternatives or when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only adds the unit (mm) and the point roles. It does not disclose whether the operation mutates the sketch, what happens on invalid geometry, whether the arc is constrained, or what result is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is front-loaded with the actionable verb and object and contains no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no annotations and no output schema, the description is quite thin. It names the geometry and unit but omits coordinate system, sketch precondition, return/result behavior, and failure semantics, leaving an agent to guess important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description maps the coordinate pairs to start (x1,y1), end (x2,y2), and point-on-arc (x3,y3), and states mm units. This meaningfully fills in what the bare schema omits, though per-parameter details are not fully elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific action (Add), target (sketch), geometry (3-point arc), and unit (mm). It explicitly defines the three points as start, end, and point-on-arc, differentiating it from sibling tools like fusion_sketch_add_line or fusion_sketch_add_circle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the available alternatives (line, rectangle, circle, etc.), nor does it mention prerequisites such as an existing sketch_id or when a different arc method would be better. The only implied context is from the tool name/description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it exports a body to an STL file, which implies file creation, but it does not mention side effects (e.g., overwriting existing files), return values, possible errors (e.g., invalid body_id or unwritable file path), or whether it modifies the document. For a tool that performs I/O and likely has failure modes, this is significantly under-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that is front-loaded with the primary action ('Export one body to an STL file') and includes a brief example. There is no wasted verbiage, and the structure is clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file export, potential errors, integration with mesh comparison), the description is incomplete. It lacks information about return values (if any), error handling, prerequisites (e.g., an open document, body existence), and how it fits with sibling tools beyond the compare_meshes example. The absence of an output schema and annotations amplifies the need for richer description, which is not provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain body_id or file_path beyond their names. It mentions 'one body' informally, but for body_id, it does not clarify that it expects a valid body identifier from the Fusion document, nor does it specify the expected format for file_path (absolute vs. relative, file extension, etc.). The names are somewhat self-explanatory, but the description adds no additional semantic value to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'one body' to an STL file, making the purpose specific and distinguishable from siblings like render_orthographic_views or get_cross_section. The mention of compare_meshes() adds a concrete use case, though it is not strictly needed for purpose definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'e.g. so mesh_tools.compare_meshes() can check the reconstruction against the original' provides a clear context for when to use this tool (preparing a body for mesh comparison). It does not explicitly state when not to use it or mention alternatives, but the example is sufficient to infer the primary use case. However, it lacks explicit guidance on prerequisites like document state or whether multiple bodies are supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the prose discloses no behavioral constraints: there is no mention that it is a read-only query, no mention of how 'suppressed' features are displayed/output, and no edge cases for huge timelines or permissions. The availability of safety information is unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences; no wasted words; the element order is listed clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema query operation, the listed fields and the record scope are sufficient for purpose, but it does not explain output format, possible ordered return, or behavior on suppressed features. Overall, reasonably complete, but still some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema covers 100% of inputs, so there are no parameter semantics gaps to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific action verb 'List' on the 'feature timeline (creation order, name, type, suppressed)', and identifies it as Fusion's own full record of every feature created. It lacks an explicit alternative tool when the intended use is unclear, and 'suppressed' is not defined, but the resource is distinct enough for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('Fusion's own record of every feature created so far') but does not provide explicit guidance on when to use this tool versus other listing tools, nor does it state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 says 'check' but does not disclose return values, error behavior, or side effects (e.g., whether it actively connects or only reports status). The agent is left guessing what 'check' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, precise sentence with no unnecessary words. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter check with no output schema, the description is minimal but lacks details about the response format or how to interpret the result. It would be more complete if it stated what a successful check returns or how failures are reported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. With no parameters, the description has no semantic burden to add, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'check' and names the exact resource: 'Fusion 360 is running with the bridge add-in started.' This clearly distinguishes it from sibling tools that perform modeling or analysis operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 using it as a precondition before other Fusion operations. The description only states what it does, not when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior: it saves a screenshot of the current viewport and the output format (PNG). However, with no annotations, it carries the full burden and does not mention file overwrite behavior, whether an active Fusion document is required, or if any side effects occur. It is adequate for a simple tool but has gaps in disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one front-loaded sentence with no redundancy. Every word adds meaning, and the structure places the verb and object first for quick scanning. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the essentials. However, in the context of many fusion_* siblings, it could briefly note when to use this vs. export/render tools, or clarify that it captures the current viewport state. It is complete enough for a simple use case but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify the parameter. It adds value by specifying 'file_path' as the destination and implying PNG format. Yet it does not mention whether the extension must be explicit, path restrictions, or default behaviors. It compensates partially for the schema's minimal string type, scoring a middle 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save a screenshot of the current Fusion viewport to file_path (PNG)' uses a specific verb (save) and resource (screenshot of current viewport), clearly distinguishing it from sibling tools like render_orthographic_views. The scope ('current Fusion viewport') is precise and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives, nor are there any exclusions or prerequisites (e.g., 'use this instead of export_stl when you need a raster image'). The intended use case must be inferred entirely from the verb and context, which is only minimally sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and parameters, but does not mention side effects (e.g., modifying the sketch), error conditions, coordinate system conventions, or required states (like sketch existence). It fails to disclose any constraints (e.g., radius must be positive) or what happens if inputs are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action and immediately clarifying the parameters. There is no wasted or redundant information; it earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add-circle operation with 4 required parameters, the description covers the core semantics but omits sketch_id and any prerequisites or return behavior. Since there are no annotations and no output schema, the description should have provided a bit more context, such as stating that the circle is added to the referenced sketch or any validation details. It is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains cx and cy as the center and radius_mm as the radius in mm, which adds meaning beyond the schema. However, sketch_id is not described at all, leaving a required parameter undefined. The description partially covers 3 of 4 parameters, but not fully, and units for cx/cy are only implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: adding a circle to a sketch, with specific parameters (center coordinates and radius). It differentiates from sibling sketch tools like fusion_sketch_add_line or fusion_sketch_add_rectangle by specifying the geometric shape. The verb 'add' and resource 'circle' are precise, and the context (sketch) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a circle is needed in a sketch, but does not explicitly provide when-to-use vs alternatives, prerequisites (like an active sketch), or exclusions. It offers no guidance on when not to use this tool or mention alternative approaches. Only implied from the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds one useful behavioral detail—coordinates are in the sketch's own mm space—but it does not disclose side effects, whether an existing editable sketch is required, or what is returned 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this is too thin: it leaves parameter semantics, return behavior, and prerequisites unstated. The coordinate-frame note is helpful but does not make the description complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only says 'line segment' and 'mm coordinates.' It never explicitly maps x1/y1/x2/y2 to endpoints or explains sketch_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Add a straight line segment to a sketch') and adds coordinate-frame scope ('in the sketch's own mm coordinates'). This clearly differentiates it from sibling tools like fusion_sketch_add_circle or fusion_sketch_add_rectangle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance or named alternatives. The phrase 'straight line segment' only implies it is the right tool for lines rather than arcs, circles, or rectangles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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. It does not state that the tool is read-only, what errors might occur, or any side effects. The 'get' prefix implies read-only, but it is not explicitly stated, and the description adds no information about limitations or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states what the tool returns, the second gives a direct use case. No fluff or redundant phrasing. It is front-loaded with the main purpose and follows with actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a simple getter: it enumerates the returned geometry components and provides a concrete use case. However, given no output schema or annotations, it would benefit from clarifying how to obtain body_id (e.g., from fusion_list_bodies) and distinguishing this from mesh_summary. The lack of parameter explanation is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, body_id, has zero schema description coverage. The description does not explain what body_id is, where to obtain it, or its format. It only appears as a string ID, leaving the agent without clear guidance on how to populate it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get detailed geometry of one body, including specific face and edge properties. It distinguishes itself from sibling tools by focusing on solid body geometry with face/edge details, and even hints at a specific downstream use (building edge selectors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: to obtain edge midpoints for building edge_selector for fusion_add_fillet and fusion_add_chamfer. It implies the primary context (geometry inspection) but does not explicitly state when not to use it or mention alternatives like mesh_summary for mesh geometry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation ('list') but does not explicitly state that the tool has no side effects or does not modify the design. It also does not disclose any potential performance or scope implications, though for a simple enumeration this is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no annotations, no output schema), the description is adequate but could benefit from mentioning what the returned parameters include (e.g., names and values) and whether they are design-specific. This would enhance completeness for an agent deciding whether to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameters. The baseline for no parameters is 4, and the description's mention of 'all' and 'user parameters' clarifies the scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all user parameters defined in the design, with a specific verb ('list') and resource ('user parameters'). It distinguishes itself from the sibling fusion_set_parameter, which modifies parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While it's reasonable to infer it should be used before setting parameters, the description does not state this or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('List') and describes output fields, but it does not explicitly state that the tool only reads data, nor does it explain the threshold behavior implied by 'large enough to matter' (likely tied to the min_area parameter). The description adds some value but leaves room for interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point. It includes some illustrative examples of flat faces (top/bottom/side walls, bosses, counterbore floors) that add context without being overly verbose. It is concise but not perfectly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and moderate complexity, so the description need not detail return values, but it does mention them (normal, area, footprint size). It lacks specifics about the min_area parameter, how coplanar groups are defined, and any prerequisites or error conditions. Adequate for a simple listing tool but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely references 'large enough to matter,' which hints at min_area but does not clarify its purpose, units, or effect on results. file_path is self-explanatory, but min_area needs more explanation. The description does not adequately cover the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists coplanar face groups (flat regions) and provides their normal, area, and in-plane footprint size. This distinguishes it from sibling tools like 'find_circular_faces' or 'get_cross_section' by focusing specifically on planar regions. The addition of a use case (spotting sketch planes) further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool: 'useful for spotting the flat faces that become sketch planes.' It also hints at the type of output (normal, area, footprint size) that helps an agent decide if this is the right tool. However, it does not mention alternatives or when not to use it, so a small deduction for lacking exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry disclosure. It mentions potential false positives and timeouts via the reference to find_circular_holes, but does not detail side effects, permissions, or performance guarantees. The cross-reference adds transparency but is indirect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using two short paragraphs to convey purpose and key caveats. The language is efficient, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. It provides typical use cases and references important pitfalls, but given the complexity of the operation and its 5 parameters, the failure to explain most parameters and the heavy reliance on a cross-reference leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain all parameters, but it only touches on min_loop_points and min_area, and even then via cross-reference. It omits explanations for min_radius, max_circularity_error, and file_path, leaving the agent without guidance on these critical inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detects facets whose entire boundary is a circle, with typical examples (flat top of cylindrical boss/pad, bottom of blind hole). It distinguishes from the sibling find_circular_holes by focusing on faces rather than holes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides typical use cases and implicit selection criteria (circular faces vs holes), and strategically cross-references find_circular_holes' docstring for parameter rationale. However, it does not explicitly state when NOT to use this tool or alternative commands, relying on the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 does not disclose behavioral traits such as whether the operation modifies the body in place, is reversible, requires specific permissions, or has any side effects. It only describes inputs and gives an example. This is insufficient 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficient. It leads with a clear one-sentence purpose, then dedicates lines to the edge_selector parameter, which is the only non-trivial part. Every sentence contributes to understanding, with no fluff. The structure is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 params, nested object) and no output schema, the description covers the essential usage. It explains the main selector mechanism and references helper tools. However, it does not mention expected side effects (e.g., fillet applied to solid body) or error conditions, and it does not clarify the units for radius_mm. These gaps are minor because the purpose is clear, but there is room for improvement (e.g., stating the operation modifies the body).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must add meaning. It excels at explaining edge_selector, which is the only complex parameter, with detailed JSON examples and a caveat about 'midpoint lies within max_distance_mm'. It does not explain body_id or radius_mm, but these are straightforward (ID string and numeric radius). The description adds significant value beyond the schema for the key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Round edges with a fillet.' which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like fusion_add_chamfer (which would be for chamfering). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance for the complex edge_selector parameter, with examples for 'all_edges' and 'near_points'. It references helper tools (mesh_tools.find_circular_holes/faces, fusion_get_body_info) for obtaining points, implying typical use cases. However, it does not explicitly state when NOT to use this tool or mention alternatives like fusion_add_chamfer, so it lacks explicit exclusions but is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists the output fields (index, area, centroid) and implies a read-only operation by using 'List', but it does not explicitly state that the tool has no side effects, nor does it mention failure modes (e.g., sketch with no closed regions) or permissions. The description adds some value beyond the action name but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource, and then provides the purpose. Every word earns its place, with no redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is quite complete: it states what is returned (index, area, centroid) and why to use it. It could additionally mention edge cases like an empty sketch or the exact return format, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, sketch_id, with 0% description coverage. The description does not elaborate on sketch_id beyond the tool name and context, but the meaning is self-evident from the tool purpose. Since the schema provides no help, the description could have explicitly defined sketch_id, but the omission is minor given the simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'closed regions (profiles) Fusion has found in a sketch'. It clearly distinguishes this from sibling tools by focusing on sketch profiles rather than bodies or meshes, and it specifies the output fields (index, area, centroid).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'use this to pick the right profile_index for extrude()/revolve() when a sketch has more than one closed region.' This gives clear context, though it does not explicitly name alternative tools or state when not to use it. It does imply the usage scenario effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It explains the mirror action and offset, but does not clarify whether the operation creates a new body or modifies the original, nor does it mention any limitations (e.g., only planar faces) or potential side effects. This leaves ambiguity about the tool's output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the primary action ('Mirror the body/feature') and then provides necessary details (plane options, offset purpose). No redundant or filler content; every clause adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (plane selection, offset), the description covers the core semantics but lacks a few completeness elements: it doesn't state whether a new body is created or the original is replaced, doesn't mention that only planar faces are supported, and omits any note about units or error handling. Without annotations or an output schema, these gaps leave the agent partially informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description is crucial. It explains feature_id as the 'body/feature produced by feature_id', plane as three allowed values, and offset_mm as 'offset along that plane's normal'. This adds meaningful context beyond the schema, though it does not mention the default values (plane=YZ, offset=0) or units for offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: mirror a body/feature across a specified plane, with an optional offset. It uses specific terms like 'mirror', 'body/feature', 'base plane' with enumerated options ('XY', 'XZ', 'YZ'), and distinguishes this from other fusion operations by focusing on the mirror action and offset scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'use this for a mirrored pair that isn't touching along the mirror line (e.g. two parts with a real gap between them)'. This tells when to use the offset feature, but does not explicitly mention when not to use the tool or name alternatives among the sibling tools, though no direct mirror alternative exists in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states that the tool returns paths, not image bytes, which is a crucial behavioral trait not evident from the schema. It also clarifies the output is PNG files. It does not cover error conditions or side effects like file creation, but the key transparency point about output format 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and purpose. The second sentence adds an essential note about return type. No fluff or redundancy, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description covers the main aspects: what it does, output type, and intended use. It does not explain parameter details, but that is partially a param-spec issue. The description is sufficiently complete for a simple rendering tool, though it could mention that four separate files are produced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the parameters. It does not explain that file_path is the source CAD file or that out_dir controls output location. Since the parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema descriptions, the score is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool renders front/top/right/isometric silhouette views to PNG files, with the explicit purpose of helping a vision-capable LLM see the part's shape before reconstruction. This distinctly differentiates it from siblings like fusion_screenshot (likely a single view) and get_cross_section (cross-section, not silhouette).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to get an overview of the part's shape before reconstructing it. It also instructs to open the returned paths with a file-reading/vision tool. However, it does not explicitly mention when not to use it or mention alternative tools, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 ray-casting approach, mesh.contains, units in mm, and a concrete known failure mode when a ray passes exactly through a mesh edge/vertex. It could go further by mentioning mesh validity or coordinate system assumptions, but it is substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The primary purpose is front-loaded in one clear sentence. The second paragraph is longer but contains necessary caveats and usage context. It is economically written with no filler, though it could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters, no annotations, and an existing output schema, the description covers the core behavior, units, algorithm, and an important failure mode. The main gaps are file_path semantics and mesh validity requirements; otherwise it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'points' by specifying they are (x, y, z) coordinates in mm, but it does not clarify the file_path parameter at all, nor does it fully specify the expected nesting of point arrays or coordinate frame. This partial compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: for each (x, y, z) point, report whether it is inside or outside the solid via mesh.contains / ray-casting. It also distinguishes itself from get_cross_section by explaining that sibling tool only traces the outer boundary, so this tool handles internal cavity checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use this tool before assuming a region is solid, e.g., before extruding or lofting to fill a volume. It also warns against relying on get_cross_section for internal cavities and advises cross-checking with points just off axis-aligned coordinates to avoid ray-edge miscalculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 that the surface distance is approximate, computed by sampling points, and reports units in mm. It does not explicitly confirm read-only behavior or describe the exact return shape, but the algorithmic detail is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the core verb and includes useful metric details without fluff. Every phrase adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only comparison tool with no annotations and no output schema, the description captures inputs, method, and reported quantities. It could be slightly improved by explicitly stating the expected return structure or clarifying whether both inputs must be STL paths, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It successfully maps 'original_path' to the original mesh and 'candidate_path' to the reconstructed model, and 'sample_count' is implied by 'sampling points'. However, it does not explicitly describe each parameter or the sample_count's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Compare a reconstructed model... against the original mesh') plus the exact metrics computed (volume/bounding-box deltas, mean/max surface distance in mm). It distinguishes itself from single-mesh tools like 'mesh_summary' by focusing on pairwise comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear use case: comparing a reconstructed/exported STL against an original mesh. It does not explicitly state when not to use it or name alternatives, but the intended scenario is unmistakable from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses that the tool lists all solid bodies and indicates the output fields, but it does not mention side effects, errors, or whether an active design is required. Adequate for a simple read-only listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence, front-loaded with the action and output, followed by a practical usage hint. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema listing tool, the description covers the essential return values and purpose. It lacks edge-case details (e.g., empty design behavior) but is otherwise complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivially 100%. The description adds value by clarifying the tool's output semantics (id, name, volume, bounding box), which is more useful than explaining parameters that don't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' plus resource 'all solid bodies in the design' and enumerates returned fields (id, name, volume, bounding box). It also distinguishes itself from siblings by explicitly tying to getting a body_id for combine/fillet/export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use ('use this to get a body_id for combine/fillet/export'), giving actionable context. It does not mention alternatives or when not to use, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the false-positive failure mode (cyclic quadrilaterals) and the performance risk ('slow enough to time out an MCP client') when min_area is not applied, plus the default heuristic 4*pi*min_radius**2. This goes well beyond a generic read-only description, though it does not fully describe the output structure or file requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and uses three tight paragraphs, each earning its place: behavior, the false-positive trap, and the performance safeguard. There is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and no annotations, the description covers purpose, false positives, and performance timeout risk, making it largely complete for a detection tool. It misses guidance on max_circularity_error semantics and explicit differentiation from find_circular_faces, but is still robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), so the description compensates substantially for min_loop_points and min_area, explaining the rectangle false-positive trap and the performance rationale. However, max_circularity_error is left unexplained, and min_radius is only implied through the min_area formula, so the compensation is not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence specifies the operation ('Detect circular through-holes / blind-hole rims') and the target resource ('sitting inside a flat facet'), and clarifies the result unit as 'one inner boundary loop of a facet that fits a circle well.' This clearly differentiates from sibling find_circular_faces by focusing on holes/rims rather than faces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening sentence gives clear context for when to use the tool: finding circular holes or blind-hole rims in flat facets. It does not explicitly name alternative tools or state when not to use it, but the parameter discussion (e.g., using min_loop_points to avoid rectangle false positives) provides practical selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It states the action (zoom/fit to visible geometry) which implies a non-destructive viewport state change, but doesn't explicitly disclose that it modifies view state without altering geometry, or mention any side effects. For a zero-parameter view tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two-clause single sentence, front-loaded with the key action (zoom/fit viewport), and the second clause adds practical context. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema view manipulation tool with simple sibling relationships (naming fusion_screenshot), the description fully covers what's needed. It could mention that it changes view state only, but nothing else is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there's nothing for the description to explain beyond what the schema shows (100% coverage by virtue of having no properties). Baseline 4 applies for zero-param tools; not much compensational need.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource-target pattern: 'Zoom/fit the Fusion viewport to the visible geometry.' This clearly distinguishes it from siblings like render_orthographic_views (a different rendering operation) and fusion_screenshot (capture, not view adjustment). The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs when to call it: 'call before fusion_screenshot for a useful picture'. This names a sibling tool and gives concrete usage sequencing guidance, making it clear how this fits into the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the lofting operation morphs between cross-sections, but does not disclose whether the operation consumes the source sketches, modifies existing bodies, or has any side effects on the model tree. The default operation 'new_body' is in the schema, not the description, so it misses the chance to clarify that it creates a new body unless combined. It is decent but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the first delivering the primary purpose and usage distinction, and the second providing essential parameter detail. It is front-loaded, concise, and every word contributes to understanding the tool. No unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a modeling operation with three parameters and no annotations or output schema, the description covers the core behavior and the most complex parameter (profiles) well. It also adds a valuable constraint ('2+ profiles') and the flexibility that planes need not be parallel. It lacks details about the operation semantics (e.g., how `operation` affects behavior) and the return value, but these are inferable from the schema defaults. Overall, it is nearly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It provides a substantial explanation of the key parameter `profiles`: 'Each entry in `profiles` is {"sketch_id": ..., "profile_index": ...}, given in loft order.' This adds structure and ordering semantics not visible in the schema (which only says array of objects). The other parameters (operation, target_body_id) are not explained, but their names and defaults are self-explanatory. Given the low coverage, this is a solid contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Loft through 2+ sketch profiles to build a shape that tapers/morphs between cross-sections.' It uses a specific verb (loft) and resource (sketch profiles), and distinguishes it from extrude by noting when to use it instead. This is above the baseline of many tool descriptions, which often just repeat the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'use this instead of extrude when the profile isn't constant along its length,' providing a clear alternative selection rule. It also notes that profiles are 'given in loft order (they don't need to be parallel planes),' which clarifies sequencing and geometric flexibility. This offers strong guidance for when to invoke the tool versus siblings like fusion_extrude or fusion_revolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that the tool creates or updates parametersholidays and explicitly states that referencing in later numeric fields is not supported – a key behavioral trait. It doesn't mention side effects or permissions, but for a simple setter, this is acceptable. It goes beyond just saying
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, clearly structured: first states the action with an example, second explains the limitation and purpose. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema tricks, the description covers the essential purpose, the create/update behavior, and a key limitation. It's sufficient for an agent to understand when and how to use it. Could mention that it also updates existing parameters, but that's implied by 'Create (or update)'. Overall, complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides an example that clarifies both parameters: name and expression (with value format). That gives the agent sufficient context to understand the semantics without needing schema descriptions. The example is concrete and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create (or update) a Fusion user parameter' with an explicit example. It distinguishes itself from other fusion tools by explaining its specific purpose (maintaining a parameter table) and a limitation (no referencing later). This is specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use it (to keep the parameter table meaningful for a human) and explicitly warns about a limitation (not supported for numeric field references). It doesn't compare to direct siblings like fusion_list_parameters, but given the context of many fusion_* sibling tools, it's clear enough. No explicit exclusions, but the limitation serves as a
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 explains the mutation (hollowing), the effect of remove_face_indices and direction, and provides an example. It does not explicitly state permanent modification or lack of undo, but the verb 'hollow out' makes this evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 80 words, front-loaded with the primary action, then detailed parameter guidance. Every sentence provides value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity modeling tool with no output schema, the description adequately covers the operation, parameters, and a concrete example. It does not mention return values or error cases, but these are less critical for a body-modifying operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds essential meaning to remove_face_indices (origin and matching method) and direction (inside/outside/both semantics). body_id and thickness_mm remain self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Hollow out a solid body into a shell') that clearly distinguishes this from sibling modeling tools like extrusion or fillet. The scope is unambiguous and the example reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear when-to-use guidance: passing remove_face_indices to open faces versus omitting for a closed shell. It references how to obtain face indices from fusion_get_body_info, but does not explicitly compare with alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 creation behavior and the plane specification options in detail. It doesn't mention side effects like making the sketch active, but for a creation tool, the core behavior is 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the purpose and then efficiently explains the two parameter modes and a typical use case, achieving high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters with no schema descriptions and no output schema, the description exhaustively explains the parameters and a concrete use case. It lacks explicit mention of the sketch becoming the active context for subsequent operations, but that is inferable from sibling tools. The description is sufficiently complete 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining plane values ('XY', 'XZ', 'YZ'), offset_mm meaning, and origin/normal as length-3 lists in mm. It also clarifies the mutually exclusive use of plane vs origin+normal, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a sketch on a plane' and explains the two modes of specifying the plane. It distinguishes this tool from siblings like fusion_sketch_add_line (which add geometry) by focusing on sketch creation itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each parameter approach: 'Either pass `plane`... or pass an explicit `origin` + `normal`'. It also provides a practical use case (mesh cross-section alignment), making the intended usage very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavior: it explains the output structure (outer/hole loops, 2D points in plane's u,v), the coordinate system convention, and the simplification process (Douglas-Peucker) including the effect of setting tolerance to 0. This is detailed behavioral disclosure beyond any structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but packed with information. It leads with purpose, then elaborated on output and parameters. It is a single paragraph but well-organized, flowing from output format to coordinate system to simplification. Every sentence adds value, though it could be slightly more tightly written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 explicitly describes the return format (polygon with outer/hole loops and point coordinates). It also covers the coordinate system convention relevant for downstream sketch tools, making the tool's output immediately usable. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does remarkably well. It explains the meaning of simplify_tolerance_mm with units and behavior, clarifies that plane_origin and plane_normal define the slice plane, and explains the 2D coordinate system relative to the plane axes. This adds substantial value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Slice the mesh with a plane') and the result ('return the resulting 2D profile(s)'). It specifies the exact purpose of drawing a matching Fusion sketch on that plane, making it distinct from sibling tools like mesh_summary or list_planar_facets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context for when to use this tool: it is needed to obtain profiles for sketching. It explains the coordinate system alignment with fusion_create_sketch and the meaning of the simplification tolerance, but it does not explicitly mention alternatives or conditions where this tool should not be used. Nevertheless, the usage guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ab7646/fusion-reconstruct-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server