Provides tools for 3D modeling and CAD operations in FreeCAD, including creating basic shapes (boxes, cylinders, spheres), performing boolean operations (union, cut, common), managing documents, and executing custom Python scripts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FreeCAD MCP Server Create a box 50x30x20 and a cylinder radius 10 height 50, then union them"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to interact with FreeCAD for 3D modeling and CAD operations.
Basic Geometry Creation: Create boxes, cylinders, spheres with specified dimensions
Boolean Operations: Perform union, cut, and common operations between objects
Document Management: Save documents and list objects
Custom Script Execution: Execute arbitrary Python scripts in FreeCAD context
Cross-Platform: Supports Windows, macOS, and Linux
Related MCP server: FreeCAD MCP Server
FreeCAD Installation: Install FreeCAD from freecad.org
Node.js: Version 18 or higher
TypeScript: For development
Clone this repository:
git clone https://github.com/lucygoodchild/freecad-mcp-server.git
cd freecad-mcp-serverInstall dependencies:
npm installBuild the project:
npm run buildConfigure FreeCAD path (if needed):
The server attempts to auto-detect FreeCAD installation
Default paths:
Windows: C:\Program Files\FreeCAD 0.21\bin\FreeCAD.exe
macOS: /Applications/FreeCAD.app/Contents/MacOS/FreeCAD
Linux: /usr/bin/freecad
npm startAdd the following to your MCP client configuration (~/Library/Application Support/Claude/claude_desktop_config.json): { "mcpServers": { "freecad-mcp-server": { "command": "node", "args": ["/path/to/free-cad-mcp/build/index.js"] } } } Make sure to replace "/path/to/free-cad-mcp/build/index.js" with the actual path and to restart Claude once you have made the changes
create_boxCreate a rectangular box with specified dimensions.
{
"name": "create_box",
"arguments": {
"length": 50,
"width": 30,
"height": 20,
"name": "MyBox"
}
}create_cylinderCreate a cylinder with specified radius and height.
{
"name": "create_cylinder",
"arguments": {
"radius": 10,
"height": 50,
"name": "MyCylinder"
}
}create_sphereCreate a sphere with specified radius.
{
"name": "create_sphere",
"arguments": {
"radius": 15,
"name": "MySphere"
}
}boolean_operationPerform boolean operations between two objects.
{
"name": "boolean_operation",
"arguments": {
"operation": "union",
"object1": "Box",
"object2": "Cylinder",
"result_name": "Combined"
}
}Operations: union, cut, common
save_documentSave the current FreeCAD document.
{
"name": "save_document",
"arguments": {
"filename": "my_model.FCStd",
"path": "/path/to/save"
}
}list_objectsList all objects in the current document.
{
"name": "list_objects",
"arguments": {}
}execute_python_scriptExecute custom Python script in FreeCAD context.
{
"name": "execute_python_script",
"arguments": {
"script": "box = doc.addObject('Part::Box', 'CustomBox')\nbox.Length = 100"
}
}This server implements the Model Context Protocol, making it compatible with MCP-enabled AI assistants. The AI can:
Generate 3D Models: Create complex geometries by combining basic shapes
Parametric Design: Modify dimensions and parameters based on requirements
Assembly Creation: Build multi-part assemblies using boolean operations
Design Automation: Execute complex modeling workflows through scripting
"Create a bearing housing with a 20mm inner diameter and 40mm outer diameter"
"Make a threaded bolt with M6 threading, 50mm long"
"Design a simple bracket to hold two 10mm rods 30mm apart"
src/
index.ts # Main server implementation
build/ # Compiled JavaScript output
package.json # Dependencies and scripts
tsconfig.json # TypeScript configurationnpm run buildnpm run devVerify FreeCAD is installed and accessible from command line
Update the freecadPath in the server constructor if needed
Check that the FreeCAD executable has proper permissions
Ensure FreeCAD Python environment has required modules
Check script syntax - Python scripts are executed in FreeCAD's Python interpreter
Use list_objects to verify object names before boolean operations
Perform boolean operations between objects
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Type of boolean operation | |
| object1 | Yes | Name of the first object | |
| object2 | Yes | Name of the second object | |
| result_name | No | Name for the result object | BooleanResult |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It omits critical details such as whether the operation modifies the original objects, required object types (solid, mesh), or side effects. The minimal description leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the core purpose. However, the extreme brevity leaves out valuable context, slightly reducing effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no output schema, the description fails to clarify what the tool returns or how the result is used. It does not explain whether a new object is created or the original objects are altered, leaving a significant gap for an AI agent to properly invoke and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the schema. The description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Perform') and resource ('boolean operations') with context ('between objects'). It effectively distinguishes from sibling tools like create_*, which focus on generating primitives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for geometric combinations but provides no explicit guidance on when this tool should be used over alternatives (e.g., execute_python_script for custom logic) or when not to use it. No prerequisites or constraints are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a box/cube in FreeCAD with specified dimensions
| Name | Required | Description | Default |
|---|---|---|---|
| length | Yes | Length of the box in mm | |
| width | Yes | Width of the box in mm | |
| height | Yes | Height of the box in mm | |
| name | No | Name for the box object | Box |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Create a box/cube...', implying a new object is added, but does not disclose any behavioral traits such as permissions, side effects, or limitations. Since no annotations are provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. While efficient, it could be slightly more informative without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with full schema, the description covers the basic purpose but omits what the tool returns (no output schema) and any usage context. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds 'with specified dimensions' but no extra meaning beyond the schema descriptions, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'box/cube in FreeCAD', which distinguishes it from sibling tools like create_cylinder and create_sphere by shape type. However, it lacks explicit differentiation beyond the shape name, which is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like boolean_operation. The description simply states what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a cylinder in FreeCAD
| Name | Required | Description | Default |
|---|---|---|---|
| radius | Yes | Radius of the cylinder in mm | |
| height | Yes | Height of the cylinder in mm | |
| name | No | Name for the cylinder object | Cylinder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'Create' without detailing effects like document state, undo history, or interaction with other objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but lacks structure (no sections, no additional context). Could be expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very sparse description for a creation tool. No mention of default units, behavior when parameters are invalid, or result location. Sibling tools exist but no guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 3 parameters. Description adds no extra meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Create' and specific resource 'cylinder in FreeCAD'. Distinguishes from siblings like create_box, create_sphere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to pick a cylinder over a box or sphere).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a sphere in FreeCAD
| Name | Required | Description | Default |
|---|---|---|---|
| radius | Yes | Radius of the sphere in mm | |
| name | No | Name for the sphere object | Sphere |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It does not mention that the sphere is added to the current FreeCAD document, whether it is placed at origin, or any side effects. The description is too minimal for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core purpose. It is well front-loaded and contains no fluff, though it could be expanded usefully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no nested objects, no output schema), the description is somewhat complete but lacks context about document requirements, object placement, and interaction with existing features. More behavioral details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema descriptions (e.g., radius in mm, default name). No extra clarification is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a sphere in FreeCAD' clearly states the action (create) and the resource (sphere in a specific application). It is specific and actionable, but it does not differentiate from sibling tools like create_box or create_cylinder, which perform analogous operations for different shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create_box, create_cylinder). The agent must infer from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a custom Python script in FreeCAD
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | Python script to execute in FreeCAD context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, error handling, or return values, leaving significant 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but lacks necessary detail. It is front-loaded but sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain the script's effect and results. It fails to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described. The description adds no additional meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a custom Python script in FreeCAD, with a specific verb and resource. It distinguishes from sibling tools that perform specific operations or create objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when it is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all objects in the current FreeCAD document
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies solely on its text. It does not disclose whether the operation is read-only, what exactly is returned (names, types, or full objects), 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words; highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description is mostly sufficient. However, the lack of an output schema and any mention of return format slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter information, but baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all objects in the current FreeCAD document', distinguishing it from sibling tools that create or modify objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a simple listing action, but no explicit guidance on when to use vs alternatives or prerequisites is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current FreeCAD document
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Filename to save (with .FCStd extension) | |
| path | No | Directory path to save the file | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Save' but fails to mention side effects like overwriting, whether it saves as new file or overwrites, or if a document must be currently active. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no waste. However, it is slightly too minimal; it could include essential context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a save operation and lack of output schema or annotations, the description is incomplete. It does not mention that the document must be open, what happens on success/failure, or any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'filename' and 'path' already described. The description adds no extra meaning beyond the schema; baseline is 3. No additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save the current FreeCAD document' clearly states the specific verb 'save' and the resource 'current FreeCAD document'. It distinguishes from sibling tools which involve creating shapes, boolean operations, or listing objects, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any preconditions (e.g., document must be open). It lacks context about when not to use it or what scenarios are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: creating primitives, boolean operations, scripting, listing, and saving. There is no overlap or ambiguity among them.
Most tools follow a verb_noun snake_case pattern (e.g., create_box, list_objects). 'boolean_operation' deviates slightly but still uses snake_case and is descriptively clear.
With 7 tools, the set is well-scoped for a basic FreeCAD interaction. It covers essential operations without being overwhelming or too sparse.
The set covers primitive creation, boolean operations, and scripting (which enables arbitrary functionality), but lacks common CAD operations like extrusion, editing, or transformation tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
DXF and PDF/X-4 for AI agents: structured facts, PNG renders, an interactive in-chat viewer.
AI Hub for AEC — 50+ 3D formats, clash detection, ACC integration via Autodesk Platform Services.
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucygoodchild/freecad-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
