FreeCAD MCP for Codex

by hashbolic

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources and actions, so an agent can usually tell them apart. A few pairs overlap in scope — inspect_shape and get_bounding_box both return bounds, and split_by_plane and split_for_print_bed both split shapes — but the descriptions make the intended use reasonably clear.
Naming Consistency4/5
The set is predominantly lower_snake_case with an action+object pattern like list_documents, create_box, and export_step. It is not perfect because freecad_health is a noun-style outlier and the boolean_* tools use an adjective prefix instead of a clear verb.
Tool Count2/5
At 36 tools this is well past the 25+ threshold for an over-large set, and several niche print-preparation helpers such as screw boss, heatset boss, fan mount, vent pattern, and print-bed splitter broaden the surface beyond a tight CAD API. The count is not an extreme 50+ disaster, but it should be trimmed or consolidated for a more focused server.
Completeness3/5
The set covers document lifecycle, object inspection, primitive modeling, boolean operations, filleting/chamfering, splitting, and STEP/STL import/export, so the primary solid-modeling workflow is usable. Missing first-class operations like delete/rename/copy objects and any sketch/extrude/parametric capabilities leave notable gaps for general FreeCAD use, partially papered over by execute_freecad_python.
Average 3.1/5 across 36 of 36 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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?
Annotations are absent, so the description carries full responsibility for disclosing behavior. It hints at atomicity with 'validated transaction', but does not state whether the operation mutates the document, requires editable objects, affects existing geometry, or returns errors. This is insufficient for a likely mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, but it is overly terse. It sacrifices necessary behavioral and parameter context rather than structuring information effectively.
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?
For a tool with 4 parameters, 0% schema coverage, no annotations, and no explanation of result handling, the description is far from complete. Even though an output schema exists, the description still fails to explain what the tool returns, when to invoke it, or what 'validated transaction' concretely means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter meaning. object_a, object_b, result_name, and doc_name are all left unexplained. The only implicit link is 'two shapes' loosely mapping to object_a and object_b.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('fuse') and resource ('two shapes'), making the core action clear. It is distinguishable from sibling boolean_cut and boolean_common by the word 'fuse' implying union, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 boolean_cut, boolean_common, or other siblings. There is no mention of prerequisites, context, or conditions that would select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the tool is read-oriented and returns diagnostics, but it does not mention side effects, failure modes, behavior on invalid BReps, or any operational constraints.
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 a single front-loaded sentence with no filler. It is concise and immediately communicates the core action, though it omits important supporting context.
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?
With no annotations, no parameter descriptions, and no usage guidance, the description is too thin for an agent to confidently invoke this tool in the right situation. The output schema helps explain return values, but the missing context around when and how to use it remains a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. The parameters `doc_name` and `object_name` are only given minimal titles in the schema; the description does not explain their roles, defaults, or relationship.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Validate'), a clear resource ('an object's BRep'), and the outcome ('return structured geometry diagnostics'). This distinguishes it from nearby sibling tools like check_collision or get_bounding_box, though it does not explicitly contrast with inspect_shape or inspect_object.
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?
There is no guidance about when to use this tool versus alternatives such as inspect_shape, check_collision, or measure_distance. The description gives no contextual trigger, exclusion criteria, or recommended workflow.
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 must carry the full burden of behavioral disclosure. It only says 'Create and validate,' but it does not explain side effects on the active document, whether validation can fail, how errors are surfaced, or what happens to the object after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action, containing no filler words. However, it is under-specified rather than effectively concise, and the unexplained 'validate' phrase does not earn its place without elaboration.
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?
Even though an output schema exists, the description still lacks essential context about where the box is created, how validation behaves, and what the parameters control. Given the number of sibling tools and the absence of annotations, this one-sentence description is not complete enough for reliable tool selection and invocation.
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%, and the description does not explicitly explain any of the five parameters. The word 'box' weakly implies width/height/length, but the description adds no real meaning beyond the self-evident property names and defaults already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and names a concrete resource ('Part box'), so an agent can tell this tool creates a box feature. It does not explicitly differentiate from sibling create_* tools, but the object type is distinct enough that the core purpose is clear, even though 'validate' could be more precise.
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 about when to choose create_box instead of the many sibling creation tools such as create_cylinder or create_shell. There is no mention of prerequisites, document state, or exclusions, so the agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the result is empty, but it does not mention whether the document becomes active, whether duplicate names are allowed, whether the document is in-memory only, or any other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core action efficiently, though it could add more useful context without becoming verbose.
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 lack of annotations and the presence of many sibling document and geometry tools, the description is too sparse. It does not explain when to create a new document versus opening one, nor does it clarify behavioral side effects, even though the existence of an output schema reduces the need to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'name' or 'label' parameters. The agent is left to infer semantics from the bare property names, with no explanation of the relationship between an internal name and a display label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create an empty FreeCAD document.' This is clear and distinguishes the action from reading or modifying documents, though it does not explicitly differentiate itself from sibling tools like open_document or save_document.
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?
There is no guidance about when to use create_document versus open_document, list_documents, or other document lifecycle tools. The description simply states what it does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior on its own. It only mentions the environment-variable gate and says nothing about arbitrary code execution mutating documents, side effects, failure modes, or timeout behavior. This is insufficient for a code-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, but the main clause merely restates the tool name and the only added content is the allow-flag condition. It is under-specified rather than genuinely well-structured.
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?
Arbitrary Python execution is high-risk and high-complexity, yet the description offers only a single gating condition. A complete definition would explain that code runs in FreeCAD's Python environment, may modify the current document, and what timeout_ms does. The output schema may cover returns, but not usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention code or timeout_ms at all. An agent receives no explanation of what code should contain, how timeout_ms works, or how the parameters relate to execution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Execute FreeCAD Python', which essentially restates the tool name and gives little detail about what counts as 'FreeCAD Python' or what execution entails. It is vaguely distinguishable from siblings because no other execute tool exists, but an agent still has to infer that this runs arbitrary Python code in FreeCAD.
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 explicit clause 'only when FREECAD_ALLOW_EXECUTE_PYTHON=true' provides a clear precondition for invoking the tool. It implies the exclusion case (do not call when the flag is not true), though it does not discuss alternatives or when to prefer specific sibling tools.
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 must carry the full behavioral disclosure burden. It only states that a STEP file is imported; it does not mention side effects, whether the target document is modified in place, whether a new document is created, overwrite behavior, or error conditions. This is insufficient for a mutating file-import 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 a single concise sentence with no wasted words. However, the phrase 'target document' introduces ambiguity and the description provides no supporting structure or context beyond the bare action, so it is concise but slightly under-specified.
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?
Although an output schema exists, this is a mutating import tool with three parameters and zero annotation coverage. The description does not explain what the import operation does to the document, what parameters are required, what the output represents, or any necessary preconditions. An agent would need additional context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides no parameter-level semantics. It does not explain the meaning or relationship of name, doc_name, or file_path beyond a loose hint from 'target document' and 'STEP file'. The description completely fails to compensate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and resource ('a STEP file'), and the format distinction separates it from import_stl/export_step. However, 'target document' is vague and does not explicitly clarify whether it means the current active document or the optional doc_name parameter.
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 about when to choose this tool over alternatives, when not to use it, or any prerequisites such as whether an existing document must be open. The only usage signal is the implicit meaning of 'import', which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It indicates a read-only listing operation but does not disclose what happens when doc_name is omitted, whether all object types are included, or how visibility is represented. This leaves meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It is concise and directly states the action and result, although it could add a brief note about the doc_name parameter without becoming bloated.
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?
The tool has one optional parameter, no annotations, and an output schema, but the description fails to explain how doc_name affects the result or how this tool fits with sibling tools. An agent can invoke it with no arguments, but cannot reliably know how to target a specific document or when this tool is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter doc_name has no schema description. The tool description does not mention doc_name at all, so an agent receives no guidance on what this parameter means or how to use it. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'List', names the resource ('objects'), and enumerates the returned fields: names, labels, types, and visibility. This helps distinguish it from list_documents, though it does not explicitly state that objects belong to a document or current scope.
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?
There is no guidance on when to use list_objects versus sibling tools like list_documents or inspect_object. The description does not mention using the optional doc_name to scope the listing, so an agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states the basic outcome ('Create a hollow cylindrical screw boss') and does not disclose side effects like adding an object to the active document, unit expectations, coordinate placement, or whether the operation is destructive. This is insufficient for a mutating CAD tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise, readable, and free of filler. It loses a point because the brevity omits important context that could have been added in a few more words without becoming bloated.
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?
For a 5-parameter tool with no annotations and zero schema description coverage, the description is too sparse. It does not explain how doc_name and name are used, how the boss relates to the active document, or hoe it differs from similar sibling tools like create_heatset_insert_boss. The presence of an output schema helps with return values but does not compensate for missing invocation context.
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, but it provides no parameter-specific meaning beyond the names in the schema. The word 'hollow' hints at hole_radius, and 'screw boss' implies outer_radius and height, but there is no explanation of name, doc_name, required relationships, or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a hollow cylindrical screw boss.' This makes the tool's core function clear. However, it does not distinguish it from closely related siblings like create_heatset_insert_boss or create_cylinder, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_cylinder, create_heatset_insert_boss, or create_shell. There is no mention of prerequisites, typical scenarios, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden, but it only states the operation itself. It does not disclose whether the tool modifies the object in place, creates a new result, requires specific selection state, or how doc_name and result_name affect behavior.
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 a single, efficient sentence with the action front-loaded and no redundant words. It is appropriately concise for conveying the core operation, though it relies on the schema and surrounding context for the missing parameter details.
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?
For a mutating CAD tool with five parameters, no annotations, and zero schema description coverage, this description leaves too much to inference. It covers the central action and one parameter behavior, but omits tool-selection guidance, behavioral effects, and semantics for most parameters.
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 for all five parameters. It clarifies edge_indices through the 'selected vs. all edges' distinction, but radius, object_name, doc_name, and result_name receive no semantic grounding in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fillet') and resource ('selected edges'), and adds a meaningful scope condition: all edges when edge_indices is omitted. However, it does not explicitly differentiate itself from sibling tools like chamfer_edges, leaving the distinction to the verb alone.
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 fillet_edges versus alternatives such as chamfer_edges or other edge-modification tools. It only implies a usage mode via the edge_indices omission behavior, but no explicit context, exclusions, or alternative routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It states that a save operation occurs, but does not disclose whether an existing file at the path is overwritten, whether the original document remains open, or how doc_name selects the document to save. The term 'new' hints at a non-destructive save-as, but critical side effects are left unclear.
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 a single, front-loaded sentence with no wasted words. It is appropriately concise, though its brevity leaves out meaningful detail about parameters and behavior.
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?
For a tool with no annotations and 0% schema description coverage, this description is incomplete. It fails to clarify the role of doc_name, overwrite behavior, or whether the active document is implied when doc_name is null. The output schema covers return values, but critical input and side-effect semantics are missing.
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. It adds meaning to path by indicating it is an FCStd path, but it does not explain doc_name at all. The optional document name parameter is only self-evident from its schema title, not from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: saving a document to a new path in FCStd format. It uses a specific verb and resource and is distinguishable from siblings like open_document and list_documents. However, it does not explicitly state whether the active document or the document named by doc_name is saved.
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 gives no guidance on when to use this tool compared to alternatives, and no exclusions or conditions are provided. An agent must infer from the tool name and sibling context that this is for save-as behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that two new objects are returned, but it does not state whether the original shape is preserved or deleted, how the plane is derived from normal/offset, or whether the new objects are added to a document. The phrase 'axis-aligned plane' also creates ambiguity because normal accepts an arbitrary number array.
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 a single focused sentence with no filler and is easy to parse. Its brevity is good, though it achieves economy by omitting important parameter and side-effect details.
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?
With four parameters, no annotations, and no property descriptions, the description does not give an agent enough to call the tool correctly. The output schema covers return values, but the input semantics, plane definition, and side effects are left to inference. A minimal viable description with clear gaps.
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 for the undocumented parameters. It adds a hint about axis-avoalignment that relates to normal, but it does not explain offset, doc_name, or object_name, nor the expected format of normal. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Split'), names the resource ('a shape'), specifies the operation ('by an axis-aligned plane'), and states the outcome ('return two new objects'). It is clear, but it does not explicitly differentiate this tool from siblings such as split_for_print_bed or boolean_cut.
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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no context about when splitting is appropriate. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. 'Save' implies overwriting the existing file but does not disclose what happens if the document is not open, if doc_name is null, whether it uses the active document, or what the output/return value contains.
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?
One short sentence with no waste and the key scoping detail ('existing path') front-loaded. It is concise, but it is also so terse that it sacrifices useful usage and behavioral context, so it is not a perfect example of effective conciseness.
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?
For a tool with no annotations, a single undocumented optional parameter, and an output schema, the description is too minimal. An agent cannot confidently determine how to pass doc_name, what happens when it is omitted, or what success/failure looks like. It also does not clearly route to save_document_as for different behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage for the single parameter doc_name is 0%, and the description adds no guidance about how doc_name is used, whether it is required, or what null means. The param name is somewhat self-explanatory, but the description fails to explain the parameter's role or the default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'save' and resource 'document' clearly state the operation, and the qualifier 'to its existing path' distinguishes it from the sibling save_document_as. However, it does not explicitly identify whether it acts on the active document or the document named by doc_name, leaving slight ambiguity.
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 phrase 'existing path' implies this is for already-created documents, and implicitly contrasts with save_document_as for new paths. But it does not explicitly state when to use this versus alternatives, nor mention prerequisites like the document being open.
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 burden and does disclose one important behavior: the document is closed without an automatic save. However, it does not clarify what happens to unsaved changes (discarded, prompted, or preserved in memory), which is the key behavioral risk of a close 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 a single sentence with no filler and the key qualifier is front-loaded near the action. It is concise, though the word 'automatically' adds slight ambiguity and could have been replaced with a clearer statement about unsaved changes.
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?
For a close operation with no annotations, an agent needs to know whether to save first, what happens when doc_name is null, and whether unsaved changes are lost. The description provides none of this context, despite the surrounding sibling tools making save-before-close a relevant workflow.
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% and the description does not explain the doc_name parameter or the meaning of null/default. Since the description's only mention is 'a FreeCAD document', it adds no real parameter-level meaning beyond what the parameter name itself implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close'), the resource ('a FreeCAD document'), and a key qualifier ('without saving it automatically'), making the core purpose understandable. It does not explicitly name or differentiate sibling close-related flows such as save_document, so it falls just short of full differentiation.
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 about when to prefer this tool over save_document, save_document_as, or open_document, or about prerequisites such as saving before closing if changes must be kept. The qualifier implies no auto-save but does not instruct an agent on sequencing or avoiding data loss.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It states that a cylinder is created and validated, but does not explain whether a document must be open, whether the cylinder is added to the active document, what validation entails, or how doc_name affects behavior.
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 a single short sentence with no filler, front-loading the action and object. It is concise, though it sacrifices useful detail.
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 that this is a creation tool with five parameters, no annotations, and no parameter descriptions, the description is too thin to support correct invocation. It does not explain side effects, prerequisites, or parameter semantics, even though the presence of an output schema reduces the need to document return values.
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%, and the description adds no parameter information. While the parameter names like radius, height, angle, and doc_name are somewhat self-explanatory, the description does not clarify units, the meaning of angle, or the role of doc_name.
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 'Create' and names the precise resource 'Part cylinder', which clearly distinguishes it from sibling tools like create_box and create_shell. It leaves no ambiguity about what the tool produces.
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?
There is no guidance on when to choose this tool over the many sibling creation tools, nor any mention of prerequisites such as an open document. Usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It states the side effect ('Create') and the result ('open-top shell'), but does not mention which document receives the object, how wall thickness relates to outer dimensions, units, placement, or any other side effects. It is not misleading, but it is too thin 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 a single compact sentence with no filler, and the key purpose is front-loaded. The bracket notation is slightly terse but does not hurt readability.
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?
The definition is enough to identify the tool, but not enough to invoke it confidently in all cases. It does not explain wall thickness semantics, units, whether the shell lands in the active document, or how `doc_name` and `name` are used. An output schema exists but does not compensate for these parameter and behavioral 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?
Schema description coverage is 0%, so the description must add meaning. It does clarify that the required `outer` array should be populated as [length, width, height]. However, `wall` is left as a bare number with no explanation of thickness or units, and `name`/`doc_name` are only inferable from their property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a rectangular open-top shell', which clearly distinguishes this from solid primitives like create_box or create_cylinder. The input order is hinted by '[length,width,height]'. It does not explicitly contrast with create_box, but the core 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use create_shell versus create_box or other modeling tools. There is no mention of prerequisites, contexts, or exclusions, so the agent must infer the appropriate use case from the tool name and general CAD knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only conveys scope ('selected or all') and format, but does not mention file overwriting behavior, handling of empty selections, what 'shaped objects' means, or what happens when object_names and doc_name are omitted.
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 a single, front-loaded sentence with no wasted words. It is concise, though the lack of supporting detail is a structural limitation.
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?
While an output schema exists and reduces the need to explain return values, the description is too sparse for a 3-parameter export tool with no annotations. Critical invocation details like the meaning of doc_name, the role of file_path, and the exact behavior of object_names are missing.
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 coverage is 0%, so the description must compensate for the three undocumented parameters. It partially clarifies object_names by contrasting 'selected or all', but file_path and doc_name semantics are entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Export'), a resource ('selected or all shaped objects'), and the output format ('STEP'). This distinguishes it from sibling export_stl by format, though it does not explicitly name the alternative.
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 the tool is used when exporting objects to STEP format, and 'selected or all' gives a basic scoping hint. However, it does not explicitly state when to prefer this over export_stl or mention any exclusions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Export selected or all shaped objects to STL' and does not mention whether the file is overwritten, whether a document must be open, what happens to the file path, or what output is returned. The output schema may cover return values, but the description lacks meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no filler. Every word contributes to the core purpose. It loses a point because the terseness leaves no room for usage or behavioral guidance, but as conciseness alone it is strong.
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 four parameters, zero annotations, and no schema parameter descriptions, the description is not complete enough. It fails to explain the meaning of multiple parameters, the side effects of writing a file, and when to use this tool versus siblings. The output schema might document return values, but that does not compensate for the missing usage and behavioral context.
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 for all four parameters, but it only vaguely hints at object_names with 'selected or all shaped objects'. It does not explain file_path, doc_name, or mesh_tolerance. The description adds minimal semantic value beyond the schema's raw parameter 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 states a specific verb ('Export'), a specific resource ('selected or all shaped objects'), and the target format ('STL'). It clearly differentiates from sibling export_step by naming the STL format, and from import_stl by the export direction. This gives an agent enough to idntify the tool's core funtion.
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 does not state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It implies usage through the format name, but there is no explicit guidance about when to choose export_stl over export_step, import_stl, or other file-related tools. An agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not say whether the original object is modified, whether new objects are created, how pieces are named, or how the axis parameter affects the split. This lack of side-effect transparency is significant for a splitting 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 a single efficient sentence with no wasted words, and the core purpose is front-loaded. It is appropriately concise, though it sacrifices behavioral and parameter detail that other dimensions capture.
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?
The tool has five parameters, no annotations, and zero schema description coverage, making the description the only source of guidance. It omits axis semantics, side effects, naming behavior, and practical usage context; the output schema may define return values but cannot compensate for missing operational guidance.
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 needed to clarify parameters, but it explains none of them. The parameter names like object_name, bed_length, and bed_width are somewhat self-explanatory, but axis is ambiguous and doc_name is entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'split' and the target outcome: converting a long object into print-bed-sized, axis-aligned pieces. It is specific enough to distinguish this from generic split tools like split_by_plane, though it does not explicitly name an alternative.
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 phrase 'long object into print-bed-sized pieces' implies the tool is for cases where an object exceeds the print bed, but it does not explicitly say when to use this tool versus alternatives such as split_by_plane. There is no guidance on prerequisites or exclusions.
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 reveal the important fallback to all edges when edge_indices is omitted, but it does not state whether the operation modifies the original object, creates a new result, or how result_name affects behavior. This is a significant gap for a mutating CAD operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence, front-loads the main action, and contains no filler. Every word contributes to understanding the core behavior.
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?
For a mutating tool with five parameters, no annotations, and no schema descriptions, this description is too thin. It omits key context about result creation, default document behavior, and relationship to the similar fillet_edges tool, leaving agents to guess important invocation details.
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 for the five parameters. It only clarifies edge_indices behavior through the omission fallback; object_name, distance, result_name, and doc_name are left entirely to their property names. The description adds minimal parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (chamfer) and the resource (selected edges), and adds the scope distinction that omitting edge_indices applies to all edges. It is unambiguous even though it does not explicitly contrast with fillet_edges.
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 gives conditional usage context ('all edges when edge_indices is omitted') but provides no guidance on when to choose chamfer_edges over alternatives like fillet_edges. There is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the creation intent. It does not disclose whether the boss is created in the active document, whether doc_name overrides that, whether the operation is synchronous or asynchronous (relevant given get_operation_status), or any 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 a single front-loaded sentence with no filler or repetition. Every word earns its place, and it is immediately scannable by an agent.
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?
Although an output schema exists and the parameter names are somewhat self-descriptive, the absence of annotations and 0% schema description coverage leave too much implicit. An agent does not know how the dimensions relate (e.g., outer_radius must exceed insert_radius) or how doc_name affects the target document.
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 for the five parameters, none of which have descriptions. The phrase 'sized for a heat-set insert' weakly clarifies insert_radius, but it does not explain outer_radius, height, name, or doc_name, leaving their exact meaning and units unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Create') and a concrete resource ('a hollow boss sized for a heat-set insert'), making the tool's purpose clear. The heat-set-insert qualifier differentiates it from sibling tools like create_screw_boss and create_cylinder, though the distinction is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use when creating a boss for a heat-set insert, as opposed to screw bosses or vent patterns. However, it does not explicitly state when not to use it, nor does it mention the active-document requirement or any prerequisites.
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 of behavioral disclosure. It states that the tool reports intersection volume, which is a useful behavioral detail, but it does not explicitly confirm the operation is read-only, describe units, or mention failure behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the core action and immediately states the reported result.
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 description is clear at a high level and the presence of an output schema reduces the need to describe return values. However, because there are no annotations and no parameter descriptions, important operational context is missing: whether object_a/object_b are names or geometry, whether a document must be specified, and what tolerance means.
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 for missing parameter documentation. It maps 'two shapes' to object_a and object_b, and 'intersection volume' to the result, but it does not explain what the strings represent, how tolerance is used, or the role of doc_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('two shapes'), and adds a concrete output ('intersection volume'). It is clear what the tool does, though it does not explicitly distinguish it from siblings like check_geometry or boolean_common.
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 about when to use this tool versus siblings such as check_geometry, get_bounding_box, or boolean_common. The intended use is implied by the wording, but alternatives and conditions are never discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the plate has through-slots and a regular array, but does not explain side effects like creating geometry in the active document, whether it modifies existing objects, units, orientation, or any required document state. This is insufficient for a creation tool with zero annotation coverage.
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 with no wasted words. It front-loads the core action and object clearly, making it easy to parse.
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 an 8-parameter CAD tool with no annotations and no usage guidance, this one-line description leaves major invocation questions unresolved: coordinate system, units, slot orientation, how depth relates to plate geometry, and whether an open document is required. The output schema does not cover these input semantics.
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% and the description name no parameters beyond implying 'regular array' and 'through-slots'. The 8 parameters (depth, width, height, spacing, slot_width, slot_length, doc_name) receive no added context about meaning, units, relationships, or defaults, so the description fails to compensate 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 ('Create') and resource ('vent plate with a regular array of through-slots'), which clearly distinguishes it from sibling shape-creation tools like create_box or create_cylinder. The mention of through-slots adds precision about the geometry being produced.
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?
There is no guidance on when to use this tool versus alternatives such as create_fan_mount, create_screw_boss, or boolean_cut. The description states only what the tool does, not the conditions or context in which it should be selected.
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 behavioral burden. 'Return' clearly implies a read-only inspection operation, and the output categories are specified. However, it does not disclose details such as mass-property units, behavior on invalid shapes, whether doc_name is required for objects outside the active document, or error conditions.
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 terse sentence with the verb front-loaded. Every word contributes meaning by listing specific output categories, and there is no filler or redundant phrasing.
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, has an output schema, and the description lists what will be returned, so it is minimally adequate. However, it lacks usage context and leaves both parameters semantically undocumented, making the overall definition incomplete for an agent deciding whether and how to invoke it.
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 needed to compensate by explaining the parameters. It does not explain that object_name refers to a shape-bearing object or that doc_name scopes the lookup to a specific document. The parameter names are somewhat self-explanatory, but no additional semantic value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('shape') and enumerates the exact output categories: shape type, validity, topology counts, mass properties, and bounds. However, it does not explicitly differentiate this tool from sibling tools like inspect_object or get_bounding_box, so it is clear but not fully distinguished.
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 about when to use this tool versus alternatives such as inspect_object, get_bounding_box, or check_geometry. The agent receives no context about which situations call for this tool, leaving the selection decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'one validated transaction,' which suggests atomicity and validation, but it does not disclose whether the operation modifies object_a in place, creates a new result, or what happens to existing 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 a single, front-loaded sentence with no filler. Every word contributes to the core meaning, and the primary operation is stated immediately.
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?
For a boolean operation with four parameters and no annotations, the description is too thin. It omits the role of result_name and doc_name, the effect on input objects, and preconditions for valid subtraction, even though an output schema exists.
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 description adds meaning to the two required parameters by defining their roles in the subtraction operation ('object_b from object_a'). However, it says nothing about doc_name or result_name, both of which have no schema descriptions, leaving optional parameter semantics incomplete.
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 ('Subtract') and names the exact resources and direction ('object_b from object_a'), making the operation unambiguous. It also distinguishes itself from sibling boolean operations like boolean_fuse and boolean_common by describing the cut/difference behavior clearly.
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 does not explicitly state when to use this tool versus alternatives such as boolean_fuse or boolean_common. The word 'Subtract' implies a difference operation, but there is no direct guidance about selection criteria, prerequisites, or exclusionary conditions.
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 indicates an import that affects a document, but does not state whether the target document must already exist or be open, what objects are created, or whether existing data is affected. This is a meaningful transparency gap for a mutation-like 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 a single, front-loaded sentence with no filler or repetition. It is concise to the point of being sparse, but it is well-structured for a simple operation.
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?
The tool has no annotations, low schema coverage, and several sibling tools with similar naming. The description does not explain how the target document is selected, whether an open document is required, or what happens on import. An agent could not reliably call this tool without additional documentation.
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 by explaining parameter intent. It only hints at 'target document' and 'STL mesh'; it does not clarify the roles of file_path, doc_name, or name. The description adds minimal meaning 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 states a specific verb ('Import'), a specific resource ('STL mesh'), and a destination ('target document'). This clearly differentiates it from import_step and export_stl, which are the most similar siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for importing STL files, but it does not explicitly state when to choose it over import_step or export_stl. The usage context is inferable from 'STL', but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool mutates placement, but does not disclose coordinate system conventions, whether values are absolute or relative, how document targeting works, or what happens on invalid input.
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?
A single, front-loaded sentence conveys the core operation with zero wasted words. It is concise without sacrificing the key semantic distinction between position and rotation.
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?
With 0% schema description coverage and no annotations, the description is under-specified for a mutation tool. It omits the role of doc_name and does not explain how the placement applies within a document context, leaving an agent to guess at required conventions.
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 description adds meaning to position and rotation by interpreting them as XYZ coordinates and Euler angles, which is valuable beyond the raw numeric-array schema. However, it leaves the doc_name parameter undocumented and does not clarify array lengths or units.
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 ('Set') on a clear resource ('an object's XYZ placement') and distinctly names the orientation parameters as yaw/pitch/roll Euler angles. This differentiates it from the sibling creation, inspection, and boolean tools effectively.
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?
There is no guidance on when to use this tool versus alternatives, and no mention of prerequisites such as the object needing to already exist in a document. The description implies the action but does not clarify the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It communicates the basic behavior: a non-mutating PNG capture of the active view. However, it does not disclose what happens if no document or view is active, whether the image is returned directly or saved to disk, or how view_angle affects the output.
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, direct sentence with no filler. It front-loads the core action and output format while keeping the entire definition minimal.
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?
Although an output schema exists, the tool has four parameters with zero schema descriptions and no guidance on valid values or behavior when parameters are omitted. The description is too thin to fully support correct invocation, especially for view_angle and active-document semantics.
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%, and the description adds no parameter detail. Width, height, doc_name, and view_angle are only hinted at by their names and defaults, leaving the accepted values for view_angle and the meaning of doc_name null ambiguous.
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 ('Capture') with a concrete resource ('PNG of the active FreeCAD 3D view'), clearly stating what the tool does. It is easily distinguished from sibling tools, none of which focus on rendering or capturing the current 3D view.
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?
There is no guidance on when to use this tool versus alternatives, such as when a document must be open or when another capture/export path might be preferred. No prerequisites, exclusions, or alternative tool references are provided.
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 must carry the behavioral disclosure burden. It only states the object created; it does not say whether the plate is added to the active document, where it is placed, what units are used, or what side effects occur. 'Four clearance holes' is the only behavioral detail beyond the term 'create.'
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 one concise, front-loaded sentence with no filler. Every word earns its place by identifying the object and its key geometric features.
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?
Despite the output schema, this is a 6-parameter creation tool with no annotations and no parameter descriptions. Missing context includes target document behavior, units, hole layout constraints, and coordinate placement, so an agent would need to infer too much before calling it.
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, but it only loosely implies that size is the plate side and hole_radius/hole_spacing describe the clearance holes. Parameters such as doc_name, name, and thickness are not explained beyond their titles/defaults.
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 verb and resource: 'Create a square fan mounting plate with four clearance holes.' This clearly identifies the object and distinguishes it from generic create_box/create_cylinder tools and from other mounting/vent features.
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 the tool is for creating fan mount plates, and the name aligns with that use. However, it gives no explicit guidance on when to prefer it over alternatives like create_box, create_screw_boss, or create_vent_pattern, and names no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. 'Inspect' implies a side-effect-free operation, and the description lists the data scope (properties, links, shape summary), which is useful. However, it does not disclose failure behavior, whether a document must be open, or potential performance costs of computing a shape summary, leaving some behavioral ambiguity.
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 nine-word sentence that front-loads the verb and directly names the output categories. There is no filler, redundancy, or unnecessary repetition. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The existence of an output schema covers return-value details, so the description need not explain those. However, it still lacks usage differentiation from inspect_shape, an explanation of the optional doc_name parameter, and any error or prerequisite context. Without annotations, these omissions prevent an agent from reliably choosing and invoking the tool correctly in all cases.
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%, and the description does not clarify the parameters. It refers generically to 'an object', which maps to object_name, but says nothing about the optional doc_name or how it disambiguates documents. Only the schema's parameter titles provide any semantic anchor.
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 verb ('Inspect') and a concrete resource ('an object's properties, links, and shape summary'). It implicitly differentiates itself from the sibling 'inspect_shape' by covering properties and links in addition to shape, and from 'list_objects' which merely enumerates objects. The action and scope are immediately clear.
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?
There is no guidance on when to use this tool versus alternatives such as inspect_shape or list_objects. No prerequisites, exclusions, or workflow context are provided. The verb 'inspect' implies a read-only use case, but it does not help an agent decide among inspection siblings.
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 burden of disclosing behavior. It usefully states the return value and coordinate frame, which gives the agent a clear behavioral model. However, it does not mention failure behavior for missing objects or whether the object must be in the current document.
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?
A single, tightly-worded sentence with no filler. The core behavior and coordinate system are front-loaded, and every word contributes meaning.
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 and has an output schema, so return value details are not the description's responsibility. Still, the description leaves doc_name semantics and document-selection behavior implicit, and provides no guidance for a multi-document environment. It is adequate but not complete.
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%, and the description does not compensate by explaining the parameters. 'object_name' is reasonably inferable, but 'doc_name' and its optional/current-document semantics are completely undocumented. The agent would have to guess the role of doc_name.
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 names the specific verb ('Return'), the resource ('an object's axis-aligned bounding box'), and the coordinate space ('document coordinates'). This clearly distinguishes it from sibling inspection tools like inspect_object, inspect_shape, and measure_distance.
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?
There is no guidance on when to use this tool versus alternatives, such as inspect_shape or measure_distance, nor any mention of required document context. The description only says what the tool does, not when it should or should not be selected.
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 must carry the behavioral burden, but it only states that the operation occurs in 'one validated transaction.' It does not disclose whether the input shapes are modified, whether a new shape is created, how the result is stored, or what validation actually involves. This is minimal behavioral 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 a single front-loaded sentence with no wasted words. Every phrase contributes either to what the tool does or to its transactional behavior.
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?
For a tool with four parameters, zero schema description coverage, no annotations, and related boolean siblings, the description is too sparse. It does not clarify how the transaction relates to documents, what the result shape becomes, or how this operation differs from boolean_cut and boolean_fuse. The presence of an output schema helps with return values, but the operational context remains incomplete.
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 for parameter meaning. It implicitly identifies 'two shapes' as object_a and object_b, but it says nothing about the optional doc_name or result_name parameters, leaving half the parameters unexplained.
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, 'Intersect', with a clear resource, 'two shapes', making the operation unambiguous. It also distinguishes the tool from the sibling boolean_cut and boolean_fuse operations, since intersection is a distinct boolean result.
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 'Intersect two shapes' clearly conveys when to use this tool: when the agent needs the common volume or overlapping region of two shapes. However, it does not explicitly name alternatives or conditions for when NOT to use it, though the intent is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It conveys that the tool is read-only in tone and returns structured health information, but it does not say whether a FreeCAD connection is required, whether it can fail, or what side effects (if any) occur. The output categories do add some behavior 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?
A single, front-loaded sentence that names the exact output categories without filler. Every word contributes to the meaning.
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 (no parameters) and has an output schema, so the description need not detail return values. The main gap is contextual: when to call this health check versus the related operation-status tool, but that gap is already penalized in usage guidelines.
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?
This tool has zero parameters, so there is no semantic burden on the description to explain inputs. The baseline for no-parameter tools is 4, and the description does not need to compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and a specific resource (bridge, FreeCAD version, GUI health), so an agent knows what the tool produces. It does not explicitly differentiate from the sibling get_operation_status, but its focus on health/version makes the purpose reasonably distinct.
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 gives no guidance on when to call this tool versus alternatives such as get_operation_status or execute_freecad_python. It does not state whether it should be used as a preflight check, after failures, or in place of other diagnostics.
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 burden of describing behavior. It discloses the core action and the return value, but it does not explain side effects like the document being loaded into the active session or what happens if the file does not exist. The output schema fills in some of the return-structure gap.
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, front-loaded sentence with no filler. Every word contributes: the action, the document type, and the return value are all stated without 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 with one required parameter and an output schema, so the description does not need to detail return values. However, it lacks context about session side effects, error behavior, and how this tool relates to other document-management siblings, leaving some operational details to inference.
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?
Schema description coverage is 0%, so the description must add meaning beyond the raw 'path' property. It does so by specifying that the document is an FCStd file, which clarifies what the path should point to. It does not cover path format or invalid-path behavior, but the single string parameter is largely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('FCStd document') and states that the tool returns an identity. This is clear enough to distinguish it from siblings like create_document, close_document, and list_documents, though it does not explicitly name the alternatives.
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 the tool is for opening an existing FCStd document, but it gives no explicit guidance about when to use it versus create_document, list_documents, or other sibling tools. Context makes the basic usage inferable, but there is no direct routing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate that the tool is non-destructive and designed for polling until completion, which is useful. However, it does not explain whether calls block, how status is reported, what happens on failure, or how 'definitively complete' is determined.
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, front-loaded sentence with no filler. Every word contributes to clarifying the tool's purpose and the key scenario ('timed-out operation'), making it highly efficient.
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?
For a one-parameter polling tool with an output schema, the description is close to sufficient, and return-value details are already covered by the output schema. However, it omits crucial lifecycle context: how the agent obtains an operation_id, whether polling is one-shot or repeated, and what to do if the operation never completes.
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?
The schema lists only operation_id with no description, and schema coverage is 0%. The tool description does not explain where operation_id comes from or how it relates to the timed-out operation. This leaves the agent to infer the parameter's meaning solely from its name.
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 verb, resource, and outcome: poll a timed-out FreeCAD operation until it is definitively complete. This clearly distinguishes it from all sibling tools, none of which are operation-status related, and leaves no ambiguity about 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 implies the correct usage context: after a FreeCAD operation has timed out, call this tool to poll for completion. It does not provide explicit when-not-to-use guidance, but the clear scenario of 'timed-out operation' and the lack of similar sibling tools make the intended context reasonably obvious.
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?
There are no annotations, so the description carries the behavioral burden. It discloses that the computation is Euclidean and that inputs are XYZ coordinate points, implying a pure calculation with no side effects. It does not discuss degenerate inputs, coordinate order, or error behavior, though the output schema covers the return shape.
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?
A single front-loaded sentence with no filler, repetition, or irrelevant detail. Every word contributes to understanding the tool's purpose and inputs.
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 pure-calculation tool, the description combined with the schema and output schema is nearly sufficient. The main missing explicit detail is coordinate ordering and required array length, but 'XYZ points' plus the straightforward operation makes correct invocation likely.
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 only provides parameter names and types (array of number) with 0% description coverage. The phrase 'XYZ points' adds meaningful semantics: each array should represent a 3D point and the two parameters are the endpoints. However, it stops short of explicitly specifying exact array length and ordering, even though 'XYZ' strongly implies [x, y, z].
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 names a precise verb (measure), a specific mathematical operation (Euclidean distance), and the exact resource (two XYZ points). This cleanly distinguishes it from other geometry tools like get_bounding_box or check_geometry.
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 use case is immediately clear: call this tool whenever a straight-line distance between two 3D points is needed. It does not explicitly list exclusions or alternatives, but no sibling tool appears to provide distance measurement, so the omission is minor.
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, but the verb 'List' clearly signals a read-only, non-mutating operation and the qualifier 'open' scopes it to the active session. Error or empty-list behavior is not described, but the presence of an output schema covers return-value 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?
A single, front-loaded sentence with no filler words. Every word adds meaning: 'List' gives the action, 'open' gives the scope, and 'FreeCAD documents' gives the resource.
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 tool's minimal complexity, zero parameters, and available output schema, the description is complete enough for an agent to select and call it. It could be slightly richer by naming list_objects as the alternative for inspecting document contents, but that is a small gap.
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 and the schema documents this completely with empty properties. The baseline for a zero-parameter tool is 4, and there is nothing for the description to add about parameter semantics.
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 action ('List') and a precise resource ('open FreeCAD documents'), which clearly distinguishes this from sibling tools like list_objects. An agent can understand the tool's job immediately without needing to inspect the schema.
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 the use case: whenever the agent needs the set of currently open FreeCAD documents. However, it does not explicitly mention alternatives or when not to use it, leaving comparison with sibling tools such as list_objects to inference.
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:

[![Codex-FreeCAD-MCP MCP server](https://glama.ai/mcp/servers/hashbolic/Codex-FreeCAD-MCP/badges/card.svg)](https://glama.ai/mcp/servers/hashbolic/Codex-FreeCAD-MCP)

Score Badge

Copy to your README.md:

[![Codex-FreeCAD-MCP MCP server](https://glama.ai/mcp/servers/hashbolic/Codex-FreeCAD-MCP/badges/score.svg)](https://glama.ai/mcp/servers/hashbolic/Codex-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/hashbolic/Codex-FreeCAD-MCP'

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