FreeCAD MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct and clearly defined purpose with no overlap: analyze_shape for geometric analysis, execute_script for Python execution, get_document_graph for feature tree inspection, get_screenshot for visual capture, get_sketch_diagnostics for sketch constraints, inspect_object for property dumps, list_documents for document listing, reload_handlers for module reloading, and tracked_recompute for change tracking. The descriptions explicitly differentiate their use cases, eliminating ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as analyze_shape, execute_script, get_document_graph, get_screenshot, get_sketch_diagnostics, inspect_object, list_documents, reload_handlers, and tracked_recompute. This uniformity makes the set predictable and easy to navigate for an agent.
Tool Count5/5
With 9 tools, the server is well-scoped for FreeCAD modeling and diagnostics, covering essential operations like analysis, inspection, scripting, and recomputation. Each tool serves a unique function, and the count is neither too sparse nor bloated, fitting typical MCP server ranges of 3-15 tools effectively.
Completeness4/5
The tool set provides comprehensive coverage for inspecting, analyzing, and managing FreeCAD models, including diagnostics, scripting, and document handling. However, there are minor gaps in direct creation or modification tools (e.g., no create_sketch or modify_object), though execute_script can serve as a workaround for such operations.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GNU Lesser General Public License v2.1 or later.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description mentions return content (properties, dependencies, validity, shape metadata) but does not explicitly state side effects, performance impact, or that it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line summary, structured bullet points for return values, and a clear 'Args' section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count, no output schema, and no annotations, the description is fairly complete, covering purpose, parameters, and return content. Missing usage guidelines slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lacks parameter descriptions (0% coverage). The description adds meaning by explaining 'name' and 'doc_name', including the default behavior of using the active document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a 'full property dump and shape analysis' for a single FreeCAD object, distinguishing it from siblings like analyze_shape which focuses solely on shape analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only describes functionality.
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 full burden. It adequately discloses the read-only nature and the fields returned, but does not mention any potential performance implications, required state of FreeCAD, or whether documents in all states are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('List all open FreeCAD documents') and efficiently enumerates the returned fields. Every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema exists, reducing the burden on the description. The description covers the core functionality adequately, though it could mention edge cases like no open documents or documents with errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 required, 100% coverage). With no parameters to document, the description does not need to add parameter semantics beyond what the schema provides. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all open FreeCAD documents and specifies the exact information returned (names, labels, file paths, object counts, modification status). This is a specific verb-resource combination with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_document_graph or analyze_shape. There is no mention of prerequisites, expected 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?
No annotations are provided, so the description must cover behavioral traits. It implies a read-only operation by describing the return structure but does not explicitly state that it has no side effects, authorization requirements, or performance implications. The disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It front-loads the purpose and return details, then provides parameter help. Every sentence adds value, and the structure logically flows from what the tool does to how to use it.
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?
With one parameter, no output schema, and no annotations, the description covers the essential aspects: what it returns and how to specify the document. It could add error handling (e.g., what happens if the document doesn't exist) or mention that the output is a tree, but overall it is sufficiently complete for effective use.
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 single parameter doc_name is described with context: 'Document name. Empty string uses the active document.' Since the input schema has no description (0% coverage), this adds meaningful information beyond the schema, clarifying the default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a structured representation of a document's feature tree and lists the returned fields (TypeId, label, properties, dependency links, validity/touch state). It also positions itself as the primary tool for understanding a FreeCAD model, distinguishing it from sibling tools like inspect_object or get_sketch_diagnostics.
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 calls it the 'primary tool for understanding what a FreeCAD model contains' but does not explicitly state when not to use it or provide alternatives. While the usage context is implied, there is no direct guidance on when to choose this over other tools like analyze_shape or inspect_object.
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 full burden. It implies a read-only analysis by describing returns but does not explicitly state that the tool does not modify the state. The description is adequate but could be more transparent about 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 relatively concise with two paragraphs plus an Args section. It is well-structured and front-loaded with the purpose. However, the first paragraph is a list of returns that could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description comprehensively lists all return values and explains usage context. It fully covers what the tool does and why to use it, leaving no major gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains that 'name' is an object with a Shape (e.g., 'Pad001') and 'doc_name' is the document name with empty string defaulting to active document. This adds meaningful context beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detailed topological analysis of an object's shape' and enumerates specific return values (shape type, volume, area, etc.), distinguishing it from sibling tools like get_sketch_diagnostics or inspect_object by focusing on shape geometry from operations.
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 advises using this tool to 'understand the geometric result of a feature — especially useful for diagnosing why a boolean or pocket operation produced unexpected geometry.' This provides clear context, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It details the return values (list of constraints with types, values, status, etc.) but does not mention whether the tool is read-only, has side effects, or requires specific permissions. The absence of such behavioral context is a gap, though the diagnostic nature hints at safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a leading summary, a list of return contents, a usage statement, and parameter details. It is reasonably concise for the amount of detail, though a minor reduction in verbosity could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains return values covering constraints and geometry. Parameters are fully described, and usage context is provided. For a diagnostic tool with two parameters, this is complete and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter names and types with 0% description coverage. The tool description fully compensates by explaining each parameter: 'name: Sketch object name (e.g., 'Sketch001'). doc_name: Document name. Empty string uses the active document.' This adds essential semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'deep inspection of a sketch's constraint health' and enumerates specific outputs (constraint count, geometry count, degrees of freedom, etc.). It distinguishes itself as the primary diagnostic tool for sketch problems, differentiating it from siblings like 'analyze_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool as 'the primary diagnostic tool for sketch problems — over-constrained, under-constrained, or conflicting sketches,' providing clear context on when to use it. It does not explicitly state when not to use or name alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains return format and purpose. Could include more about error conditions or side effects, but sufficient for a screenshot tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description plus concise Args section, no fluff, efficiently communicates essential information.
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?
Adequately covers purpose, parameters, and return format for a simple tool with two optional parameters and no output schema. Minor gaps in error handling.
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 descriptions are empty (0% coverage), but description's Args section adds brief yet clear meaning to width and height parameters.
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?
Clearly states the tool captures the current 3D viewport as a base64-encoded PNG image, distinguishing it from sibling tools like analyze_shape or execute_script.
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?
Mentions usefulness for visual inspection, providing clear context, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that stdout and stderr are captured and returned. It also lists available objects in the context. However, it does not warn about potential side effects like document corruption or performance impacts, but given the absence of annotations, it provides reasonable transparency about the tool's capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 6 sentences) and well-structured. It front-loads the purpose, then details context, usage guidance, and arguments. Every sentence is meaningful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description covers the essential aspects: what it does, available context, usage guidance, and parameter meaning. It could mention error handling or synchronous execution, but overall it is sufficiently complete for an escape hatch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, requiring the description to provide meaning. The description adds value by explaining that the script runs in FreeCAD's interpreter with access to objects like FreeCAD, App, Gui, and doc. The 'Args: script: Python code to execute.' line is minimal but the broader context sufficiently enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute arbitrary Python code in FreeCAD's interpreter context.' It identifies the specific verb (execute) and resource (Python code in FreeCAD), distinguishing itself from the sibling tools which are for analysis, inspection, and document operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool: 'Use this as an escape hatch for operations not covered by the specific tools above.' It also provides concrete examples (creating objects, modifying properties, running macros) that help the agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses that all handler modules are reloaded and re-registered with the RPC server. While it lacks mention of potential state loss, for a reload operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence contains the action and object, the second explains when to use it. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description is complete. It covers the purpose, usage context, and behavior. There are no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the description correctly indicates no parameters are needed. Schema description coverage is 100% (none to cover), so the description adds value by explaining the zero-parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Hot-reload all FreeCAD addon handler modules.' It specifies the verb 'reload' and the resource 'handler modules,' distinguishing it from sibling tools like analyze_shape or execute_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Call this after editing handler code (in freecad_addon/handlers/) to pick up changes without restarting FreeCAD.' It provides clear context and no alternative tools are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly explains the snapshot and diff process, including the four categories of reported changes. Does not mention potential side effects or performance, but sufficiently details the behavioral mechanism.
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?
Well-structured with a clear opening, bulleted list for output, and a separate Args section. Concise without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description fully covers input, behavior, and output format. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter is doc_name. Schema provides no description, but the description adds 'Document name. Empty string uses the active document.', which adds essential meaning beyond schema 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?
Clearly states 'Recompute a document and track what changed' with specific output metrics. Distinguishes itself from a raw recompute by highlighting the tracking capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this instead of raw recompute to understand the impact of changes', providing clear guidance on when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![FreeCAD-MCP-Server MCP server](https://glama.ai/mcp/servers/theosib/FreeCAD-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/theosib/FreeCAD-MCP-Server)

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/theosib/FreeCAD-MCP-Server'

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