freecad-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.19
Disambiguation4/5
Most tools have clearly distinct purposes, aided by detailed descriptions. However, 'fillet' vs 'fillet_edges' and 'execute_code' vs 'execute_code_async' are close pairs that could cause misselection, as the names don't immediately convey their different scopes.
Naming Consistency3/5
The tool names mix patterns: verb_noun (create_object, list_documents), bare verbs (pad, pocket, loft), and noun_noun (linear_pattern, measure_gap). While each name is readable and mostly intuitive, the lack of a consistent convention makes the set feel less predictable.
Tool Count2/5
With 36 tools, the surface is large and exceeds the 25+ threshold that typically signals bloat. Several tools overlap in purpose (fillet/fillet_edges, measure/measure_gap, execute_code/execute_code_async), inflating the count without adding distinct value, though the complexity of CAD does justify a larger set.
Completeness3/5
The server covers a broad range of CAD workflows—sketching, padding, pocketing, patterning, booleans, fillets, lofts, sweeps, part families, measurement/verification, and FEM. However, common operations like revolve, mirror/shell, and document lifecycle management (e.g., close/delete document) are missing, leaving notable gaps for a full-featured CAD tool.
Average 4.4/5 across 36 of 36 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 32 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.json to 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?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states that it returns a success/failure message and a screenshot. It does not mention whether it modifies the current document, requires an active document, or has 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. It opens with a one-sentence purpose, then uses clear 'Args' and 'Returns' sections. Every sentence serves a purpose, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is somewhat adequate. However, it lacks usage context and any safety or side-effect information, especially since annotations are absent. For a simple insert operation, it covers the basics but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides one line: 'relative_path: The relative path of the part to insert.' This adds basic meaning over the schema's bare title 'Relative Path', but it is still minimal and does not explain the path's base directory or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb ('Insert') and resource ('a part from the parts library addon'). This distinguishes it from siblings like 'get_parts_list' (which lists parts) and 'create_object' (which creates from scratch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or specific scenarios where this tool should be preferred. The sibling list includes related tools like 'instantiate_family' and 'get_parts_list', but the description offers no differentiation.
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 full burden. It discloses the return value ('a message... and a screenshot') but omits critical behaviors: whether the object must exist, how obj_properties merges or replaces existing properties, and any side effects on the document. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action and use case. The Args section repeats schema information, but the overall structure is clear and no sentences are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 params with a nested object, no annotations, and an output schema (not detailed), the description does not provide enough context. It lacks error handling, prerequisites, and the structure of obj_properties. It also doesn't help choose between edit_object and the many sibling operations like pad, pocket, or fillet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The parameter descriptions merely restate the parameter names: 'doc_name: The name of the document to edit the object in' provides no additional detail about how obj_properties should be structured or what property names are valid. This adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit an object in FreeCAD' and specifies a use case: 'used when the create_object tool cannot handle the object creation.' This differentiates it from create_object, though not from other editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names an alternative (create_object) and describes when to use this tool: 'when the create_object tool cannot handle the object creation.' However, it doesn't provide broader guidance on when not to use it or how it relates to other editing operations like pad or pocket.
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 for behavioral disclosure. It mentions that the operation returns a success/failure message, but it does not disclose potential side effects, permissions, or behavior when a document with the same name exists. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, and Examples, front-loading the purpose. It is slightly verbose for a one-parameter tool but every section adds value, and the example is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers input, output, and example usage. An output schema exists (even if not shown), and the description already explains the return message. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'name' parameter (coverage 0%), but the description explicitly states 'The name of the document to create' and provides an example. This adds meaning beyond the schema, effectively compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new document in FreeCAD', which is a specific verb and resource. It distinguishes itself from sibling tools like create_object or create_sketch by focusing on document-level creation, and the example reinforces the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or reference other tools. The example shows basic usage but lacks contextual 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 carries the full burden of behavioral disclosure. It does not clarify side effects (e.g., whether the active view changes), output format (e.g., file path, base64), or any permissions or limitations. The return value is only vaguely described as 'A screenshot of the active view.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with Args/Returns sections and is mostly concise. Minor redundancy exists ('Get a screenshot of the active view' repeated in the Returns), but it remains easy to scan and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter documentation is strong, but behavioral context is thin: no side effects, no output format, no usage guidance. The inconsistency between 'active view' in the title and selectable view_name also creates ambiguity. An output schema exists, so return details are less critical, but the description still leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the bare schema: it explains width/height in pixels with viewport defaults, focus_object behavior (fits all objects), and enumerates valid view names. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a screenshot of the active view.' The verb 'Get' and resource 'screenshot' are specific, and the detailed view_name enum distinguishes this from sibling tools like get_object and get_objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or alternative tools mentioned. The description only states the basic operation, leaving the agent to infer usage 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?
With no annotations provided, the description alone must disclose behavioral traits. It mentions the return value (message and screenshot) but does not state that deletion is permanent, irreversible, or whether it affects dependent objects or requires confirmation. This lack of safety/impact disclosure is significant for a destructive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, an Args list, and a Returns line. Every sentence serves a clear function with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required string parameters) and the description covers its purpose, arguments, and return value. However, it lacks any mention of prerequisites (e.g., document must exist), error behavior, or side effects beyond the obvious deletion, leaving some gaps for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema offers no descriptions for the two parameters (0% coverage), but the description's Args section explicitly explains both doc_name and obj_name, adding meaning beyond the schema. It clarifies the document and object references, compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('an object in FreeCAD'), clearly distinguishing it from siblings like create_object, edit_object, and get_object. No other sibling tool has 'delete' in its name, so 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states the action without providing explicit guidance on when to use this tool versus alternatives. It implies usage for deleting objects but offers no exclusions or alternative tool references. The context is clear from the purpose, but no explicit usage guidance is given.
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 burden of disclosing behavior. 'Get' implies a read-only operation, but it does not explicitly state there are no side effects, nor does it mention any permissions or limitations. The description is minimally adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, there is no fluff, and it is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema available. The description covers the essential purpose, and the output schema handles return details. However, it does not mention any prerequisites or usage context, so slightly less than a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain parameter semantics. The baseline for no parameters is 4, and the description adds no misleading or extra information, so this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (the list of parts in the parts library addon). It is specific and distinguishes from sibling tools like insert_part_from_library, which inserts rather than lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, not the context or exclusions, leaving the agent to infer when listing parts is appropriate.
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 transparency burden. It discloses that the circle is 'fully-constrained' and that coordinates are in 'sketch-local space,' which is useful. However, it does not mention permissions, error conditions, or side effects, and the mutation aspect is only implicit in the verb 'Add.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a compact argument list. It is front-loaded with the primary purpose and contains no redundant words. The structure is clear, scannable, and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no visible output schema, the description covers the essential context: what it does, the parameters, and the coordinate space. It does not explain return values, but the presence of an output schema may cover that. It is sufficiently complete for a basic geometry-adding operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for its 5 properties (0% coverage), so the parameter list in the description is essential. It gives brief definitions for each parameter and adds context like 'sketch-local space' for x and y. This compensates for the schema gap, though it could detail units or coordinate system further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a fully-constrained circle to a sketch, centered at (x, y).' This is a specific verb+resource that distinguishes it from sibling tools like add_rectangle and add_polygon. The 'fully-constrained' detail adds precision about the geometry's behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when adding a circle to a sketch) but does not explicitly address when to use it instead of alternatives like add_rectangle or add_polygon. No exclusions or alternative tools are mentioned, leaving usage guidance at an implied level.
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 burden. It discloses the return format ('a list of document names'), which is helpful. However, it does not explicitly state that the operation is read-only, has no side effects, or describe behavior when no documents are open. The lack of such detail is a gap, but the verb 'Get' and the nature of listing imply a safe read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and immediately followed by the return type. Every word earns its place, with no irrelevant detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists, no nested objects), the description is complete. It clearly states what the tool does and what it returns. With an output schema present, the return value specification is adequately covered, and the mention of 'FreeCAD' provides the necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description adds no parameter-specific information because there are none to describe. The baseline for zero parameters is 4, and the description is consistent with this, providing no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('the list of open documents in FreeCAD'), making the purpose unambiguous. It clearly distinguishes this from siblings like create_document or get_objects, which have different actions and targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to know which documents are currently open, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For example, there is no guidance like 'use this instead of get_objects to enumerate documents rather than objects within a document.'
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 discloses that the tool returns the object and a screenshot, adding useful behavioral context. However, it does not explicitly state that the operation is read-only or free of side effects, though the 'get' wording implies 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and neatly structured with separate Args and Returns sections. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter, the description covers purpose, parameters, and return behavior, and an output schema exists to detail the return type. It lacks explicit sibling differentiation or usage caveats, but nothing critical is missing for a basic read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter titles with no descriptions, so the description compensates by explaining doc_name ('name of the document to get the object from') and obj_name ('name of the object to get'). This gives clear meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get an object from a document' and further explains it retrieves properties for inspection. It distinguishes itself from siblings like get_objects (plural) and get_view by focusing on a single object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it to retrieve object properties to see what can be checked or edited. It implies a pre-edit inspection usage, but does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It adds valuable context about the rectangle being 'fully-constrained' and 'locked in place,' which is a meaningful side effect. However, it does not mention potential failures, permissions, or what happens to existing sketch geometry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief introductory sentence, a short paragraph on the constraint benefit, and a clear Args list. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 geometry-add tool. It covers purpose, benefit, and parameter semantics. It doesn't discuss prerequisites like whether the sketch must exist or be open, but the sibling tools (e.g., create_sketch) imply this context. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the Args section fully compensates by describing all six parameters with meaningful details. For example, 'width' is clarified as 'along the sketch's local X axis' and coordinates are specified as 'sketch-local space,' adding semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add a fully-constrained rectangle to a sketch, corner at (x, y).' This is a specific verb + resource, and it distinguishes the tool from siblings like add_circle and add_polygon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is advantageous: 'the sketch is immediately safe to pad/pocket — no separate dimensioning step needed.' This gives clear context for use, though it does not explicitly name alternative tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of safety disclosure. It states that the body must already exist ('existing PartDesign::Body') and constrains plane to three values, giving useful preconditions. However, it does not explicitly state that this write operation modifies the document, nor does it cover failure cases or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact summary plus an Args block, with no redundant phrasing. The opening sentence captures the core action, and the workflow sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description doesn't need to explain return values. It provides the essential workflow, parameter meanings, and a pointer to subsequent operations. Missing details like error handling are understandable for a CAD tool, but the core invocation is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds one-line explanations for each parameter, including the exact allowed plane strings, which the schema leaves unspecified. This fully compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an empty sketch attached to a PartDesign Body's base plane, and explicitly names the accepted plane values. This distinguishes it from sibling tools like add_rectangle or pad, which operate on the sketch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to populate the sketch with add_rectangle/add_circle/add_polygon and then pad or pocket, providing a clear sequence. It doesn't explicitly say when to use this over alternatives, but the workflow strongly implies its role as the initial sketch-creation step.
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 burden of behavioral disclosure. It mentions a critical prerequisite (base_feature must be solid) but does not detail side effects, error conditions, or return behavior. The output schema may cover return values, but other behavioral traits are partially revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, front-loaded with purpose, and structured with a clear Args list. The cross-reference to fillet's docstring is a useful pointer without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema descriptions and a 6-parameter tool, the description provides complete parameter explanations and a key constraint. The output schema likely covers return values, so the description adequately covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section thoroughly explains each parameter, including examples for 'edges' ('Edge3', 'Edge7') and units for 'size' ('in mm'). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bevel edges of a solid feature (PartDesign::Chamfer)', using a specific verb ('Bevel') and resource ('solid feature'). It also references the PartDesign::Chamfer feature, distinguishing it from siblings like fillet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns 'base_feature MUST be a solid feature, never a sketch' and points to fillet's docstring for further reasoning. This provides clear when-not-to-use guidance, though it does not fully enumerate alternatives beyond the fillet cross-reference.
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 convey behavior. It does state the return value (list of objects plus a screenshot) which is helpful, but it does not explicitly say whether the operation is read-only or whether there are side effects, permissions, or other caveats. For a getter, this is a moderate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and includes a clear Args/Returns structure. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, an existing output schema, and a straightforward purpose, the description is complete. It explains what to expect and how to invoke the tool. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, but the tool description includes an Args section explaining 'doc_name: The name of the document to get the objects from.' This fully clarifies the only parameter and exceeds the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all objects in a document' with a specific verb and resource, and distinguishes from sibling tools like get_object (singular) by indicating it returns all objects. It also explains the purpose ('to see what you can check or edit'), making it 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: use this tool to retrieve objects for inspection or editing. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for a simple tool with obvious applicability.
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 discloses key behavioral traits: it is a bounding-box approximation ('v0 of a joint model') and has limitations regarding rotation and non-axis-aligned cases. It does not mention return format or edge cases, but the output schema likely covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then use case, then limitations. Every sentence adds value, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, use case, and limitations, which is sufficient given the output schema exists. It lacks details like signed vs. absolute gap or overlapping parts behavior, but those are not critical for an initial measurement tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by naming all parameters and explaining axis values ('x', 'y', 'z'). However, part_a, part_b, and doc_name only receive minimal restatement ('Name of the first part'), adding little beyond the schema's field titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Measure the real gap between two parts' bounding boxes along one axis.' It also clarifies it is an axis-aligned bounding-box measurement, not a face-to-face mate, distinguishing it from the sibling 'measure' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'Use this before building a part meant to span two others' and explains the reasoning. It also provides exclusions: 'does not handle rotated parts or non-axis-aligned relationships,' making the usage boundaries clear.
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 provided, the description carries the full burden. It discloses failure conditions (unconstrained sketch, invalid solid) and states that the tool always reports volumeBefore/volume/isValid/boundingBox to confirm actual material addition. This goes beyond the schema, which does not explain the meaning of these output fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose statement, followed by failure conditions and output validation, then a list of arguments. It is not overly verbose and front-loads the key information. The argument list is plain text but remains readable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex CAD operation with 7 parameters and no annotations, the description covers the essential aspects: purpose, preconditions, failure modes, and parameter meanings. It also mentions output validation. It does not elaborate on the output schema structure (already present in the schema) or prerequisites like document/body existence, which are implied by parameter names. Overall, it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains all 7 parameters: doc_name, body_name, sketch_name, name, length (in mm), midplane (symmetrical extrusion), and reversed_ (flip direction). Each parameter gets a meaningful explanation, making the tool usable without additional documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Extrude a fully-constrained sketch into a solid (PartDesign::Pad).' This distinguishes it from sibling tools like pocket (which removes material) and other feature tools. The mention of 'PartDesign::Pad' anchors it to a specific CAD feature type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is for adding material via extrusion, and it fails under specific conditions (sketch not fully constrained, invalid solid). It also indicates the tool is for cases where you need to verify material was added via the reported volume. However, it does not explicitly contrast with alternatives like pocket or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses important traits: points are connected in order, loop closes automatically, coordinates are in sketch-local space, and the resulting polygon is fully-constrained. It does not cover failure modes or side effects, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the main purpose, the second adds key behavioral distinctions, and the Args list gives precise parameter semantics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a straightforward parameter set and an output schema, so the description covers the essential usage, coordinate system, auto-close behavior, and shape-specific use case. It omits prerequisites (e.g., that the document/sketch must already exist), but overall it is sufficiently complete for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no parameter descriptions (0% coverage), but the description's Args section fully explains all three parameters, including the points format ('[x, y]' in sketch-local space) and the minimum count of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('fully-constrained closed polygon to a sketch from [x, y] points'), and explicitly differentiates from sibling tools by stating it is the only way to express L, T, hexagon, or custom outlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly communicates when to use the tool ('only way to express an L, T, hexagon, or other custom outline'), giving strong contextual guidance, but it does not name specific alternatives or state explicit when-not scenarios.
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 behavioral burden. It explains that the tool 'forces an explicit decomposition up front' and 'returns any similar builds already verified,' implying a state-tracking and query operation. It notably says 'before creating any geometry,' signaling non-destructive scope. However, it doesn't explicitly state whether the tool modifies the document or session state beyond tracking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary, then uses paragraphs and a list for args. While longer than average, every sentence earns its place (usage, rationale, follow-up, args). The rationale about plan-shape mistakes adds value but could be tightened slightly without losing impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its complexity (prerequisites, follow-up, two actions), the description covers when, how, and why to call it, plus parameter details. It doesn't describe return values, but an output schema exists. It omits edge cases like error handling or behavior when no similar builds are found, but overall the description is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for 0% schema coverage. It defines each parameter: doc_name as 'the document this build is happening in,' prompt as 'close to verbatim,' and expected_components with an example component list. It also explains how prompt and expected_components should be used, adding meaning well beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Start tracking a non-trivial build, and check for similar prior examples.' It clearly distinguishes itself from siblings by positioning as the FIRST step for multi-part assemblies and referencing finish_build as the follow-up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'Call this FIRST for anything beyond a single simple part... before creating any geometry.' It also states the mandatory follow-up with finish_build, giving a clear usage workflow and distinguishing from one-shot build tools.
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 of behavioral disclosure. It reveals that the tool rejects a sketch base with an explanation, thereby preventing the otherwise silent 'shape is invalid' failure, and it explains the underlying mechanism of the Tip becoming broken. This goes beyond the basic 'round edges' 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: the opening sentence states the purpose, the warning paragraph is critical and earns its length, and the Args list is structurally clean and efficient. Every sentence adds value, with no redundant filler or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six required parameters and a notably dangerous pitfall (filleting a sketch). The description covers the operation, the base_feature constraint, and the edge/radius parameters thoroughly. Since an output schema exists, return values need not be described, and no critical usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions, so the description fully compensates by listing every parameter with context. 'base_feature' is clearly constrained to solid features, 'edges' is given a concrete example format, and all six parameters are explained. This adds meaning well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Round edges of a solid feature (PartDesign::Fillet)', a specific verb and resource that clearly identifies the operation and object type. It distinguishes this tool from chamfer (rounding vs. beveling) and fillet_edges (solid vs. sketch) by emphasizing the solid-feature requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for solid features and strongly warns never to use a sketch, explaining the resulting broken tip and subsequent failures. While it does not name alternative tools such as chamfer or fillet_edges, it provides a clear when-to-use and when-not-to-use condition.
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 provided, the description carries the full burden. It discloses the tool's purpose and the kernel's tolerance for degenerate input, adding valuable behavioral context beyond the schema. It does not cover error cases or side effects, but for a measurement tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it fronts the purpose, then provides a motivational usage note, and ends with parameter documentation. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple string parameters and an existing output schema, the description is complete. It covers what the tool does, why it is useful, and all parameters. Return value details are delegated to the output schema, so no redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a dedicated Args section with clear one-line definitions for both doc_name and obj_name. Since schema description coverage is 0%, this fully compensates and explains the meaning and role of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures an object's real geometry with a specific list of metrics (volume, area, bounding box, isValid, face/edge/vertex counts, and cylindrical-vs-planar counts). This specificity distinguishes it from siblings like measure_gap, which measure distance/gaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to use this tool to verify the results of mutating operations, with a strong rationale about FreeCAD's kernel tolerating degenerate input. This provides clear context, though it does not explicitly name alternatives such as measure_gap for exclusion.
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 that the tool computes 'the real geometric intersection' rather than using heuristics, and it reveals a common failure mode where an 'open-top enclosure' yields 0 material at the floor. This gives valuable insight into the tool's behavior beyond the basic operation, though it does not explicitly state whether the operation is read-only or has 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary, followed by a rationale with a concrete example, and ends with parameter definitions. No filler; every sentence contributes meaning, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers the core behavior, parameter constraints, and a key failure scenario, making it complete for a geometric probe tool. It omits error handling, but that is not essential for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description fully compensates by defining each parameter: doc_name, obj_name, box_min as the minimum corner, and box_size with a positivity constraint. This gives the agent all necessary information to construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states the tool's function: 'Check whether solid material actually exists inside an axis-aligned box.' It also distinguishes itself from alternatives by contrasting with 'inferring it from a screenshot or trusting that a cut/pad did what was intended,' providing a specific verb+resource and clear differentiation from siblings like get_view or measure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool when you need direct geometric verification rather than visual inference or assumptions from modeling operations. It provides a concrete failure example illustrating when probing is necessary, but it does not explicitly name alternative tools to use instead, so it lacks the most explicit 'use this instead of X' guidance.
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 of behavioral disclosure. It explains the internal behavior (closes the stale in-memory copy and reopens from disk), describes potential failure modes (document not loaded, no associated file), and notes that the return message will confirm or describe the failure. While it doesn't explicitly warn about unsaved changes being lost, the overall behavior is disclosed well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the opening sentence immediately states the core purpose. Subsequent sections (Args, Returns, Examples) are clearly labeled and concise. Every sentence earns its place, providing necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a simple behavior, the description is complete. It covers the purpose, use case, parameter semantics, return values, and includes an example. The output schema exists and the description appropriately explains what the return will be, so no further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the description fully compensates with an Args section that explains doc_name is 'The name of the open document to reload' and instructs that it 'Must match the name shown by list_documents.' This adds meaning beyond the bare schema field name, giving the agent precise guidance on how to provide the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Close and re-open a document to pick up external file changes.' This is a clear verb+resource+scope, and it distinguishes the tool from siblings by specifying the unique use case of re-syncing with on-disk changes. It is not a tautology and clearly communicates the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this AFTER the document's .FCStd file has been modified by something outside of FreeCAD's GUI process.' It also provides a concrete example (headless freecadcmd script) and explains why it is needed (the GUI is unaware of external changes). It does not explicitly list when-not-to-use or alternatives, but the context is clear and sufficient for the intended use case.
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, but the description discloses important behaviors: a no-op cut fails loudly instead of silently succeeding, and the typical cause (non-overlap) is explained. It also describes a powerful pattern for preserving internal structure. However, it does not state whether the base/tool solids are consumed, modified, or left intact, which is relevant for a boolean operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every section contributes: purpose, alternative-tool contrast, failure behavior, a usage pattern, and parameter documentation. It is well-structured with a clear intro and an Args block. The length is justified by the complexity and the absence of annotations/schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no enums and no schema descriptions, the description provides a complete picture: what the operation does, when to use it, failure semantics, a sophisticated pattern example, and all parameter meanings. The presence of an output schema further reduces the need to explain return values, so the description covers everything an agent needs to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by documenting every parameter in the Args section. It explicitly lists allowed values for 'operation' ('cut', 'fuse', 'common') and explains that multiple tools are automatically combined for a cut, which is critical semantic detail beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with a specific verb+resource: 'Cut, fuse, or intersect ARBITRARY existing solids.' It clearly identifies this as the assembly boolean primitive and distinguishes it from 'pocket' by naming the alternative tool and its limitations. The scope ('arbitrary existing solids') 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'use this whenever the tool is a separate object' with concrete examples (hollowing a piston, subtracting a shaft, merging bosses). It also contrasts with pocket and notes the failure mode when no material is removed, helping agents choose and verify the right 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 of behavioral disclosure. It explains the default behavior (ruled=False produces a smooth surface) and the effect of ruled=True (straight transitions), plus the solid vs. surface output. It does not mention error handling or side effects, but for a CAD loft operation, the disclosed traits are sufficient to set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the one-line purpose leads, followed by a helpful contrast with 'pad', then usage instructions, parameter explanations, and an Args list. Each sentence earns its place with informative content, and the formatting improves readability without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a loft command with five parameters and an output schema (which presumably documents return values), the description covers the main conceptual points, parameter meanings, and usage context. It could be more explicit about requirements like closed profiles or coplanar sketches, but it already states '2+ profile objects' and that they are 'usually sketches placed at different heights', which is sufficient for an experienced CAD user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides titles and types, with zero descriptions within the schema itself. The description's 'Args' section adds full meaning for every parameter: 'solid: Produce a solid rather than a surface', 'ruled: Straight transitions instead of a smooth blend', and 'profiles: Names of 2+ profile objects (usually sketches), in order.' This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Blend between two or more profiles — tapered and organic shapes.' It clearly distinguishes itself from the sibling tool 'pad' by stating that 'pad extrudes ONE profile at a constant section' and that lofts are needed for tapering/blending. This makes the purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with 'pad' and gives concrete when-to-use guidance: 'Real parts taper and blend... Those need a loft.' It also provides ordering instructions ('Give the profiles in order along the blend') and notes that profiles are usually sketches on different planes. This goes beyond simple context by naming an alternative and defining the appropriate scenario.
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 present, so the description must fully disclose behavior. It clearly states the operation creates a new PolarPattern feature, explains the axis_sketch constraint in detail, and imposes a minimum occurrences threshold (>=2). While it doesn't discuss failure modes or side effects on existing geometry, the description adequately conveys the tool's behavior for this CAD operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-sentence purpose, a focused usage caveat, and a compact Args block. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, several with non-obvious constraints (e.g., axis_sketch must own the datum). The description covers these, provides usage examples, and references the sibling linear_pattern for extra context. The existence of an output schema (not shown) covers return values. Minor gap: no mention of prerequisites like the body needing to be active, but overall the description is robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by documenting every parameter with meaningful explanations, including the valid enum values for axis, the interpretation of angle as total angular span, and occurrences as total copies including the original. This far exceeds the schema's bare field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Repeat features radially' and identifies the exact resource (PartDesign::PolarPattern). It also differentiates from sibling linear_pattern by name and states 'This is the tool for bolt circles and gear-tooth rings,' making its purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly references linear_pattern for the rationale behind the axis_sketch requirement, and states the tool is for bolt circles and gear-tooth rings, giving clear when-to-use context. It also warns about the Profile link limitation, providing both usage and exclusions.
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, the description fully explains critical behavioral nuances: name collisions are silently resolved by appending a suffix, return object_name may differ from the requested name, and this tool only reports whether the FreeCAD call raised rather than verifying volume/isValid/fullyConstrained. This goes well beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to five JSON examples, but each example demonstrates distinct object types and property schemas, which are highly valuable. The narrative is dense and front-loaded; while it could be trimmed, the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema lacks descriptions for 5 parameters and has nested objects, the description compensates thoroughly: it covers type prefixes, when to avoid this tool, naming collision behavior, FEM-specific property keys (CharacteristicLengthMax/Min vs legacy), and return semantics. It is exceptionally 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explicitly describes doc_name, obj_type, obj_name, and obj_properties, and examples show detailed property structures (e.g., Placement for cylinders, References for FEM constraints). However, analysis_name is only introduced in examples and not described in Args, leaving a minor gap for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new object in FreeCAD' and clarifies the allowed object type prefixes. It explicitly contrasts with sketch-based workflows (create_sketch/pad/pocket), distinguishing this generic creation tool from its siblings like create_sketch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: 'For sketch-based solids... prefer create_sketch + add_rectangle/add_circle/add_polygon + pad/pocket instead', with a reason (those tools verify results), and it includes examples for FEM objects. This clearly tells the agent when to use this tool vs alternatives.
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?
The description discloses that returned records include full prompt/tool-call/outcome details and warns that dimensions, names, and positions may differ. It does not explicitly state read-only behavior, but 'search' implies non-mutating. Given no annotations, this is a reasonable level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: a one-sentence purpose, a returns statement with caveats, usage guidance, and a clear Args section. Every sentence adds value, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a search/reference operation with an output schema, and the description sufficiently explains what is returned, the limitations of results, and when to use it mid-build. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), but the description fully compensates: query is defined as 'a natural-language description of what you're building' and top_k as 'maximum number of examples to return (default 3).' This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Search the verified-build corpus for prior examples similar to a request.' It identifies a distinct resource and function, and differentiates from siblings by framing it as a reference tool, specifically mentioning begin_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: 'Useful to call again mid-build for a specific sub-assembly, not just once via begin_build,' directly contrasting with a sibling tool. It also advises using results as reference rather than copying mechanically, which clarifies appropriate use.
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 discloses behavioral nuances: all objects are named with a prefix to allow coexistence, the L-bracket template encodes a sweep instead of an extrusion, the flanged disc uses a verified bolt-hole pattern, and the box enclosure uses a separate cutter solid to preserve a floor. This goes well beyond what the schema or annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, bulleted family definitions, and an Args section. Every sentence adds necessary information about behavior, parameters, or naming, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with multiple families and free-form parameters, and the description covers all essential aspects: family choices, parameter semantics, modeling pitfalls, and naming behavior. Since an output schema exists, omitting return-value details is acceptable. The description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and parameters is a free-form object, so the description carries the entire burden. It not only lists each family's parameters but also specifies which are optional and their default values, adding meaning far beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Build a named part family from parameters instead of a manual op sequence.' It also enumerates the specific families, making its scope unambiguous and distinct from sibling tools like create_object, pad, or sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'instead of a manual op sequence' provides explicit contextual guidance for when to use the tool. It clearly differentiates this from manual modeling workflows, though it does not explicitly name alternative tools or describe when NOT to use it. The family-specific details further clarify applicability.
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 carries full responsibility for behavioral disclosure. It thoroughly explains how bbox_min is computed from the current real bounding box, the order of rotation relative to bbox/origin moves, the silent Body substitution in PartDesign, the expect_size verification, and the role of rotation_center. This is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries unique information. It is well-organized with a purpose statement, mode options, rotation order, an important warning, and a parameter list. All information is relevant and necessary for correct usage, and it is front-loaded with the core concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, output schema present), the description is remarkably complete. It covers all parameters, edge cases (PartDesign body substitution), verification (expect_size), and advanced usage (rotation_center). It even references response fields for confirmation, which is appropriate since the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description must fully compensate. It explains every parameter: doc_name, obj_name, bbox_min vs origin, rotation structure, rotation_center purpose, and expect_size as a validation aid. It adds real semantic value beyond the raw schema, including usage examples and common mistakes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Position an object by its real bounding box instead of a derived offset.' It clearly distinguishes the tool's purpose from simple offset-based placement and outlines two distinct modes (bbox_min and origin), making its function unambiguous relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Pass exactly one of bbox_min or origin,' rotation behavior, and specific use cases for rotation_center (posing a linkage). It also cautions about PartDesign Body substitution. However, it does not explicitly name alternative sibling tools or state when NOT to use this tool, so it stops short of full alternative guidance.
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 the effect of the frenet parameter, noting it 'keeps the profile's orientation consistent' and that the alternative 'can twist the section unpredictably.' It also implies solid vs. surface but does not explicitly state whether the tool mutates the document or creates a new object, which is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening summary, explanatory paragraph, and a clear Args list. Every sentence provides useful information—there's no fluff or repetition. The length is justified by the complexity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description needn't detail return values. It covers purpose, usage, parameter semantics, and critical behavioral nuances (frenet twist). It is complete enough for an agent to select and invoke sweep correctly, especially with sibling tools like pad and pocket available for contrast.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by defining each parameter in the Args block: profile ('a sketch or face'), path ('a wire, arc, or spline'), solid ('Produce a solid rather than a surface'), and frenet ('Keep the profile orientation consistent'). This adds meaning the schema lacks, so the tool is easy to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a profile along a path — genuinely curved parts,' which clearly states the action and resource. It explicitly differentiates from pad/pocket/loft by noting that sweep is for bends or curves those operations cannot express, such as a bent shaft or pipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'This is how you get curvature that pad/pocket/loft cannot express,' and gives concrete examples like a shaft, pipe, curved rib, or hose. It also clarifies that the path can be an arc or spline, providing clear guidance versus alternatives.
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, the description carries full burden. It discloses the unverified nature, the fact that it reports only whether code raised (with typed tools being safer), and the specific patterns rejected before execution (process-level imports, eval/exec/open, dangerous Sketcher calls). This goes well beyond basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into purpose, guidance, safety restrictions, args, and returns. Every sentence adds value; the front-loaded purpose immediately informs the agent. Length is justified by the complexity of a code-execution tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complexity, the description covers what the tool does, when to use it (as a last resort), safety constraints, parameter meaning, and return value structure. The presence of an output schema reduces the burden on describing return values in detail, and the summary is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema says nothing beyond 'code' being a string, but the description adds meaningful constraints (rejecting specific code patterns) and states 'The Python code to execute.' While it doesn't detail the execution environment, the single parameter is well contextualized by the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Execute arbitrary Python code in FreeCAD,' using a specific verb and resource. It clearly distinguishes itself from sibling tools by labeling itself as an 'unverified escape hatch' and listing the preferred typed alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'prefer the typed tools... for normal geometry work,' with a clear rationale (typed tools validate results). It also enumerates what kinds of code are rejected, giving concrete usage boundaries.
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?
No annotations exist, so the description carries full burden. It discloses failure behavior ('A radius bigger than the local geometry allows makes the operation fail rather than silently filleting a subset') and the why behind fusion failures, going far beyond basic function. This is transparent and builds trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured, front-loading the purpose and using paragraphs for context, differentiation, and warnings. The 'real machined parts' rationale is useful but could be trimmed; still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-rich tool with no annotations and empty schema, the description covers all parameters, failure modes, and practical sequencing advice (fillet before fusion). The output schema exists, so return-value documentation is not needed. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's Args section is the sole parameter explanation. It defines each parameter clearly, including units (mm), 1-based edge indexing, optionality, and the semantics of `max_edge_length`. This fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Round the edges of ANY solid'—a specific verb and resource—and immediately clarifies its scope (any solid, not just PartDesign features) which distinguishes it from the sibling `fillet` tool. It clearly states what the tool achieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with the `fillet` tool ('Unlike the `fillet` tool... this works on any solid'), provides conditional guidance for `max_edge_length`, and gives a critical 'IMPORTANT' warning about filleting before fusing. This is textbook usage direction.
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 carries the behavioral burden. It discloses that this is an unverified escape hatch, that code is rejected based on dangerous patterns, that execution happens on a background thread with restrictions on FreeCADGui/doc mutations, and that it returns immediately. This is rich, honest, and goes far beyond basic safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is meticulously structured: a lead sentence, a risk warning, usage limits, thread-safety restrictions, comparison with the alternative, a numbered typical usage pattern, and an args/returns section. Every paragraph adds necessary information, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous execution, thread-safety restrictions, security filtering), the description is remarkably complete. It covers what the tool returns, what it cannot do, how to use it safely, and even provides a multi-step workflow. No information needed for safe invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists 'code' with zero description coverage. The description compensates by explaining what constitutes valid background-safe code, listing rejected constructs, and providing a typical usage pattern. While the Args line is minimal, the prose fully contextualizes the parameter's meaning and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Execute Python code in FreeCAD without waiting for completion.' It clearly distinguishes itself from sibling execute_code by emphasizing the async/background nature and explicitly contrasting with the typed tools. The purpose is unambiguous and differentiates well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this ONLY for long-running background computations that do NOT touch the FreeCAD GUI or mutate the FreeCAD document tree directly.' It also names the alternative: 'use execute_code instead' for document/GUI-touching code. This is textbook usage differentiation.
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 carries full responsibility for behavioral disclosure. It does so thoroughly: it reveals that components are re-measured with `measure` and never trusted from prior tool self-reports, that the build is only exported if every component is a valid shape AND the count matches begin_build's declaration, and that failures are reported but not saved. This gives the agent a complete picture of the tool's side effects and decision logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-sentence summary, a usage paragraph, a detailed behavior paragraph, and an Args section. Despite its length, every sentence contributes unique information about when to use the tool, how verification works, and what conditions trigger a save. The organization makes it easy for an agent to parse quickly while retaining all necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of annotations or schema descriptions, the description is remarkably complete. It covers the workflow context (after begin_build), the verification method (measure), the success/failure criteria (valid shapes and count match), the outcome (exported or reported with reason), and parameter semantics. An output schema exists, so the lack of explicit return-value detail is acceptable; nevertheless, the description still mentions that failures are 'reported back to you with the specific reason,' offering a partial preview of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero description coverage (only field titles), so the description must compensate. It includes an Args section that explains doc_name as 'The document passed to begin_build for this build' and component_names as 'Names of every component you built (should match, in count, what you declared in begin_build's expected_components).' This adds crucial context about how the parameters relate to the build lifecycle and the count-matching requirement, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Close out a build: re-verify every claimed component, and save it as a reusable example if it actually checks out.' This clearly states the tool's function and outcome, and distinguishes it from siblings like begin_build or measure by framing it as the finalization step that only saves verified builds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Call this after begin_build and after you believe the build is complete.' It also explains the verification and export conditions, implying that it should not be used before the build is complete or when components are known to be invalid. This provides clear contextual guidance relative to the build workflow.
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 carries the behavioral burden. It exposes non-obvious failure modes: passing a feature reference 'resolves to a nested link FreeCAD rejects, or silently patterns nothing', and patterning a pattern produces 'a perfectly valid solid that changed nothing, which this tool now reports as a failure rather than a success.' It even includes a verified example to clarify 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though the description is lengthy, every sentence serves a purpose. It starts with a concise definition, then addresses critical pitfalls, provides a concrete example of correct usage, and ends with a neatly formatted Args list. The length is justified by the complexity of the tool and the number of potential mistakes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is contextually complete for an unannotated tool. It covers prerequisites (axis_sketch must own the datum), constraints (originals must be base features), failure modes (silent failures, false successes), and even a verified operational example. There is no output schema shown, but the description doesn't need to explain return values if the output schema exists elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for every parameter: axis_sketch (must own the axis datum), axis (explicitly lists H_Axis/V_Axis/N_Axis), originals (must be base features, not patterns), length ('Total span of the pattern in mm'), and occurrences ('Total number of copies, including the original (>= 2)'). Even doc_name, body_name, and name are explained clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Repeat features along a sketch axis (PartDesign::LinearPattern).' It uses a specific verb ('repeat') and resource ('features along a sketch axis'), and the mention of the PartDesign feature type distinguishes it from sibling tools like polar_pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance with both positive requirements and negative constraints: 'axis_sketch/axis MUST name the sketch that owns the H_Axis/V_Axis/N_Axis datum — never a feature's Profile link', 'originals MUST be base features (a Pad or Pocket), never another pattern', and a clear directive for building a grid: 'do NOT pattern a row along the perpendicular axis; put the whole row in ONE sketch'. It also gives an alternative approach using add_circle.
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 available, the description fully discloses critical behavioral traits: failure when no material is removed, midplane-based ThroughAll, the one-directional ThroughAll pitfall, and the inherent floor limitation. This goes beyond basic operation and teaches the agent about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence definition, followed by a concise failure-mode section, a NOTE, and a clean Args list. Every sentence carries critical information; there is no wasted text. Structure is logical and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations, this description covers all parameters, explains key edge cases, and references alternatives. The presence of an output schema (not shown) means return values need not be described. The tool is fully contextualized for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args section is essential. It explains every parameter including relationships: 'length: Cut depth in mm (ignored if through_all=True)' and 'through_all: Cut all the way through, from the midplane.' This adds meaning well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Cut material out of a body with a sketch profile (PartDesign::Pocket).' This clearly distinguishes it from sibling operations like pad (adds material), boolean, and fillet. The tool's role as a subtractive feature 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context, including when the tool fails (profile over empty space) and how through_all behaves. It also names alternative approaches for a common use case: 'For a container cavity, use instantiate_family("box_enclosure", ...) or build the cavity as a separate cutter solid.' This is clear guidance on when to choose something else.
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 takes full responsibility for behavioral disclosure. It reveals that SolverCcxTools is auto-created if missing, that execution blocks the GUI thread and all RPC calls, and that on failure it returns error details and the working directory. It also specifies the return values (max von Mises stress, displacements, node count, working directory).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Prerequisites, behavior, Returns, Args). Every sentence provides necessary information, and the length is justified given the tool's complexity. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive: it covers prerequisites, execution mode, side effects (auto-creation), failure handling, return values, and all parameters. The presence of an output schema further reduces the need to document returns, but the description already does so. It is fully sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It clearly defines doc_name ('Name of the FreeCAD document'), analysis_name ('Name of the Fem::AnalysisPython object'), and timeout ('Seconds to wait for the solver (default 600)'). This adds crucial context beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run the CalculiX solver on an existing Fem::FemAnalysis container and return summary results.' It specifies the verb (run), the resource (CalculiX solver on Fem::FemAnalysis), and the outcome (return summary results), distinguishing it from sibling tools that focus on object creation/editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists explicit prerequisites in the document, telling the agent exactly what must exist before using the tool (geometry, analysis container, material, mesh, constraints). It also provides a clear when-not: 'do not fan out parallel requests' due to synchronous blocking. This is strong usage guidance.
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:

[![freecad-mcp MCP server](https://glama.ai/mcp/servers/maximedns5/freecad-mcp/badges/card.svg)](https://glama.ai/mcp/servers/maximedns5/freecad-mcp)

Score Badge

Copy to your README.md:

[![freecad-mcp MCP server](https://glama.ai/mcp/servers/maximedns5/freecad-mcp/badges/score.svg)](https://glama.ai/mcp/servers/maximedns5/freecad-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/maximedns5/freecad-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server