Allows to control FreeCAD from Claude Desktop, providing tools for creating, editing, and deleting objects, executing Python code, inserting parts from library, getting views, running FEM analysis, and more.
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 Create a 100mm cube at the origin"
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.
Claude Desktop から FreeCAD を操作できる MCP サーバーです。
会話履歴はこちら: https://claude.ai/share/7b48fd60-68ba-46fb-bb21-2fbb17399b48
Related MCP server: FreeCAD MCP
FreeCAD のアドオンディレクトリは以下の通りです。
OS | バージョン | パス |
Windows | FreeCAD 1.1 |
|
Windows | FreeCAD 1.0 |
|
macOS | FreeCAD 1.1 |
|
macOS | FreeCAD 1.0 |
|
Linux (Ubuntu) | — |
|
Linux (Debian) | — |
|
Linux (Arch / CachyOS) | FreeCAD 1.1 |
|
addon/FreeCADMCP ディレクトリを上記のアドオンディレクトリにコピーしてください。
git clone https://github.com/Yaeshio/FreeCAD-MCP-For-YDGA.git
cd FreeCAD-MCP-For-YDGA
# Linux (Ubuntu/Debian)
cp -r addon/FreeCADMCP ~/.FreeCAD/Mod/
# Linux (Arch/CachyOS, FreeCAD 1.1)
mkdir -p ~/.local/share/FreeCAD/v1-1/Mod/
cp -r addon/FreeCADMCP ~/.local/share/FreeCAD/v1-1/Mod/
# macOS (FreeCAD 1.1)
cp -r addon/FreeCADMCP ~/Library/Application\ Support/FreeCAD/v1-1/Mod/# Windows (PowerShell) - プロジェクトルートから実行
# FreeCAD 1.1
robocopy addon\FreeCADMCP "$env:APPDATA\FreeCAD\v1-1\Mod\FreeCADMCP" /E /NFL /NDL
# FreeCAD 1.0
robocopy addon\FreeCADMCP "$env:APPDATA\FreeCAD\Mod\FreeCADMCP" /E /NFL /NDLインストール後、FreeCAD を再起動してください。
ワークベンチ一覧から 「MCP Addon」 を選択すると使用できます。
「FreeCAD MCP」 ツールバーの 「Start RPC Server」 をクリックして RPC サーバーを起動します。
デフォルトでは FreeCAD を開くたびに手動で RPC サーバーを起動する必要があります。自動起動を有効にするには:
MCP Addon ワークベンチに切り替えてから 「FreeCAD MCP」 メニューを開く
「Auto-Start Server」 にチェックを入れる
設定は freecad_mcp_settings.json に保存され、次回以降の FreeCAD 起動時に自動的に RPC サーバーが起動します。
無効にするには同じメニューの 「Auto-Start Server」 のチェックを外してください。
事前に uvx をインストールしてください。
Claude Desktop の設定ファイル claude_desktop_config.json を編集します。
通常ユーザー向け
{
"mcpServers": {
"freecad": {
"command": "uvx",
"args": [
"freecad-mcp"
]
}
}
}トークンを節約したい場合は --only-text-feedback を追加します（スクリーンショットなし）。
{
"mcpServers": {
"freecad": {
"command": "uvx",
"args": [
"freecad-mcp",
"--only-text-feedback"
]
}
}
}開発者向け（ローカルクローンを使用）
git clone https://github.com/Yaeshio/FreeCAD-MCP-For-YDGA.git{
"mcpServers": {
"freecad": {
"command": "uv",
"args": [
"--directory",
"/path/to/freecad-mcp/",
"run",
"freecad-mcp"
]
}
}
}デフォルトでは RPC サーバーは localhost のみで待ち受けます。別のマシンの FreeCAD を操作したい場合は以下の手順で設定してください。
「FreeCAD MCP」 ツールバーで:
「Remote Connections」 にチェックを入れる — 次回再起動時に RPC サーバーが 0.0.0.0（全インターフェース）でバインドされます。セキュリティのため、「Allowed IPs」 で許可した IP アドレスまたは CIDR サブネットからの接続のみ受け付けます（デフォルト: 127.0.0.1）。
「Configure Allowed IPs」 をクリックし、許可する IP アドレスまたは CIDR サブネットをカンマ区切りで入力します。例:
192.168.1.100, 10.0.0.0/24設定変更後は RPC サーバーを再起動してください。
--host フラグに FreeCAD が動作するマシンの IP アドレスまたはホスト名を指定します。
{
"mcpServers": {
"freecad": {
"command": "uvx",
"args": [
"freecad-mcp",
"--host", "192.168.1.100"
]
}
}
}--host の値は起動時に検証されます（有効な IPv4/IPv6 アドレスまたはホスト名が必要）。
ツール名 | 説明 |
| FreeCAD に新しいドキュメントを作成する |
| FreeCAD にオブジェクトを作成する |
| FreeCAD のオブジェクトを編集する |
| FreeCAD のオブジェクトを削除する |
| FreeCAD 上で任意の Python コードを実行する |
| GUI に触れない長時間処理を非同期で実行する |
| パーツライブラリ からパーツを挿入する |
| アクティブビューのスクリーンショットを取得する |
| ドキュメント内の全オブジェクト一覧を取得する |
| 指定オブジェクトのプロパティを取得する |
| パーツライブラリ のパーツ一覧を取得する |
| ドキュメントをディスクから再読み込みする |
| 開いているドキュメントの一覧を取得する |
| CalculiX ソルバーで FEM 解析を実行し、最大 von Mises 応力・最大変位・節点数などの結果を返す。使用例は |
neka-nat/freecad-mcp をフォークしています。
Create a new document in FreeCAD.
Args:
name: The name of the document to create.
Returns:
A message indicating the success or failure of the document creation.
Examples:
If you want to create a document named "MyDocument", you can use the following data.
```json
{
"name": "MyDocument"
}
```
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions return messages ('success or failure'). It does not disclose potential side effects, permissions needed, or error behaviors beyond a simple success/failure.
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 concise and well-structured with Args, Returns, and Examples sections. It could be slightly more succinct, but it's clear and organized.
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?
The tool is simple with one parameter and an output schema exists, so the description is mostly adequate. However, it lacks depth on error scenarios or behavior beyond success/failure, which 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?
The parameter 'name' is explained in the description as 'The name of the document to create,' and the example reinforces its usage. With schema description coverage at 0%, the description adds necessary meaning.
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 'Create a new document in FreeCAD.' The verb 'Create' and resource 'document' are specific, and it distinguishes from sibling tools like create_object, delete_object, etc.
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 versus alternatives (e.g., when to create a document vs. an object). The description lacks contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new object in FreeCAD. Object type is starts with "Part::" or "Draft::" or "PartDesign::" or "Fem::".
Args:
doc_name: The name of the document to create the object in.
obj_type: The type of the object to create (e.g. 'Part::Box', 'Part::Cylinder', 'Draft::Circle', 'PartDesign::Body', etc.).
obj_name: The name of the object to create.
obj_properties: The properties of the object to create.
Returns:
A message indicating the success or failure of the object creation and a screenshot of the object.
Examples:
If you want to create a cylinder with a height of 30 and a radius of 10, you can use the following data.
```json
{
"doc_name": "MyCylinder",
"obj_name": "Cylinder",
"obj_type": "Part::Cylinder",
"obj_properties": {
"Height": 30,
"Radius": 10,
"Placement": {
"Base": {
"x": 10,
"y": 10,
"z": 0
},
"Rotation": {
"Axis": {
"x": 0,
"y": 0,
"z": 1
},
"Angle": 45
}
},
"ViewObject": {
"ShapeColor": [0.5, 0.5, 0.5, 1.0]
}
}
}
```
If you want to create a circle with a radius of 10, you can use the following data.
```json
{
"doc_name": "MyCircle",
"obj_name": "Circle",
"obj_type": "Draft::Circle",
}
```
If you want to create a FEM analysis, you can use the following data.
```json
{
"doc_name": "MyFEMAnalysis",
"obj_name": "FemAnalysis",
"obj_type": "Fem::AnalysisPython",
}
```
If you want to create a FEM constraint, you can use the following data.
```json
{
"doc_name": "MyFEMConstraint",
"obj_name": "FemConstraint",
"obj_type": "Fem::ConstraintFixed",
"analysis_name": "MyFEMAnalysis",
"obj_properties": {
"References": [
{
"object_name": "MyObject",
"face": "Face1"
}
]
}
}
```
If you want to create a FEM mechanical material, you can use the following data.
```json
{
"doc_name": "MyFEMAnalysis",
"obj_name": "FemMechanicalMaterial",
"obj_type": "Fem::MaterialCommon",
"analysis_name": "MyFEMAnalysis",
"obj_properties": {
"Material": {
"Name": "MyMaterial",
"Density": "7900 kg/m^3",
"YoungModulus": "210 GPa",
"PoissonRatio": 0.3
}
}
}
```
If you want to create a FEM mesh, you can use the following data.
The `Shape` property is required (legacy `Part` is also accepted).
On FreeCAD 1.x the size limits are `CharacteristicLengthMax/Min`;
the legacy `ElementSizeMax/Min` keys are also accepted.
```json
{
"doc_name": "MyFEMMesh",
"obj_name": "FemMesh",
"obj_type": "Fem::FemMeshGmsh",
"analysis_name": "MyFEMAnalysis",
"obj_properties": {
"Shape": "MyObject",
"CharacteristicLengthMax": 10,
"CharacteristicLengthMin": 0.1
}
}
```
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes | ||
| obj_type | Yes | ||
| obj_name | Yes | ||
| analysis_name | No | ||
| obj_properties | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as error handling, side effects (e.g., behavior if the object already exists), or required permissions. The mention of returning a success/failure message and screenshot is minimal.
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 quite lengthy due to multiple examples. While front-loaded with a clear one-liner, the subsequent examples repeat similar patterns and could be condensed. Adequate but not concise.
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 (5 parameters, nested objects, output schema), the description covers many object types and properties through examples. However, it lacks information on error conditions, prerequisites, and details about the return value (despite an output schema existing).
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?
The input schema has 0% description coverage, but the description compensates with detailed examples that illustrate the usage of each parameter, especially obj_properties. The examples add significant meaning beyond the raw schema, covering diverse cases like FEM constraints and materials.
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 'Create a new object in FreeCAD' and specifies valid object type prefixes, differentiating it from sibling tools like delete_object or edit_object. Examples cover a range of object types, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description lists object types and provides examples but does not indicate when to prefer this tool over others like edit_object or get_object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an object in FreeCAD.
Args:
doc_name: The name of the document to delete the object from.
obj_name: The name of the object to delete.
Returns:
A message indicating the success or failure of the object deletion and a screenshot of the object.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes | ||
| obj_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive nature by using 'delete' and mentions the return value includes success/failure and a screenshot. However, it lacks details on side effects, permissions, or irreversibility, which is important given no annotations.
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 uses a structured Args/Returns format, which is adequate, but could be more concise. The key action is only stated in the first line, and the rest is somewhat verbose for a simple operation.
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 tool with two simple parameters and an output schema, the description covers the basics. However, it omits error conditions, prerequisites, and side effects, leaving room for improvement.
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?
With 0% schema coverage, the description adds meaningful context by explaining each parameter's role (document name and object name), compensating 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an object in FreeCAD, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'edit_object' or 'create_object', though the name itself is 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an object in FreeCAD.
This tool is used when the create_object tool cannot handle the object creation.
Args:
doc_name: The name of the document to edit the object in.
obj_name: The name of the object to edit.
obj_properties: The properties of the object to edit.
Returns:
A message indicating the success or failure of the object editing and a screenshot of the object.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes | ||
| obj_name | Yes | ||
| obj_properties | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions returning a success/failure message and screenshot, but lacks details on side effects, permissions, or error handling for missing 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?
Description is structured with intro, arguments, and returns, but includes redundant listing of parameters that are already in the schema. Could be slightly more concise.
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 that an output schema exists (not shown), the description adequately covers return values and basic behavior. Still, more detail on nested obj_properties 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 0%, so description must compensate. Parameter descriptions are basic and add little beyond names, especially 'obj_properties' which is vague despite being a nested object.
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 that the tool edits an object in FreeCAD and positions it as an alternative when 'create_object' cannot handle creation, distinguishing it from sibling tools.
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?
Provides a specific condition for use (when create_object cannot handle creation), but does not contrast with other sibling tools like delete_object or get_object, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary Python code in FreeCAD.
Args:
code: The Python code to execute.
Returns:
A message indicating the success or failure of the code execution, the output of the code execution, and a screenshot of the object.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose the risks of arbitrary code execution, such as potential destructive actions or access to the FreeCAD environment. With no annotations, the description carries the full burden of behavioral disclosure and fails to warn adequately.
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 concise with a single clear sentence followed by structured Args and Returns sections. However, the Args/Returns duplicate information available in the schema and output schema, slightly reducing efficiency.
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 capability to execute arbitrary code in a complex application (FreeCAD), the description omits critical context about permissions, side effects, error handling, or timeouts. The existence of an output schema partially compensates but not enough.
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?
The only parameter 'code' has no schema description (0% coverage). The description only restates 'The Python code to execute,' adding no meaning beyond the schema. The parameter remains underdocumented.
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 'Execute arbitrary Python code in FreeCAD,' which specifies the verb and resource. However, it does not distinguish from the sibling 'execute_code_async' tool, leaving ambiguity about synchronous vs. asynchronous execution.
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 'execute_code_async' or other tools. No prerequisites or context for invocation are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Python code in FreeCAD without waiting for completion.
Use this ONLY for long-running background computations that do NOT touch the
FreeCAD GUI or mutate the FreeCAD document tree directly.
This tool runs the submitted code in a background thread and returns
immediately. Because it does not run on FreeCAD's main GUI thread, the code
must NOT call FreeCADGui APIs, manipulate the active view or selection, create
or edit document objects, change object properties, call doc.recompute(), or
save documents.
For code that touches FreeCAD documents, document objects, FreeCADGui, the
active view, selection, recompute, or save operations, use execute_code instead.
execute_code runs on the FreeCAD GUI thread and is the safe default for normal
FreeCAD automation.
Use execute_code_async only for background-safe work such as long-running
pure OCCT geometry calculations (e.g. fuse/cut/loft on already-fetched shapes)
or other CPU-bound computations that do not interact with the document or GUI.
Typical usage pattern:
1. Fetch shapes into local variables first (via execute_code on the GUI thread).
2. Store intermediate results in a module-level Python variable (not in the
FreeCAD document) so execute_code can read them later.
3. Run the heavy computation via execute_code_async.
4. After the expected computation time has elapsed, apply results to the
document via execute_code (which runs on the GUI thread).
Args:
code: Background-safe Python code to execute.
Returns:
A message confirming that background execution has started.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description thoroughly discloses behavior: runs in background thread, returns immediately, restrictions on GUI/document access. It also outlines a four-step usage pattern, providing full transparency.
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 detailed but well-structured with clear sections (when to use, what not to do, typical pattern). Every sentence serves a purpose, though slightly verbose; could be tightened without losing information.
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 complexity (async execution, threading constraints), the description covers all necessary context: purpose, restrictions, alternatives, usage pattern, and return value. The output schema is mentioned, making it complete.
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 0%, so the description must add meaning. While not listing parameters explicitly, it explains the 'code' must be background-safe Python, which adds context beyond the schema's minimal 'Code' title. The usage pattern further clarifies what code is acceptable.
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's purpose: 'Execute Python code in FreeCAD without waiting for completion.' It explicitly distinguishes itself from the sibling 'execute_code' by specifying thread context and allowed operations.
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 explicit guidance: 'Use this ONLY for long-running background computations...' and clearly states when not to use it (GUI/document modifications). It names the alternative 'execute_code' and explains the typical usage pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an object from a document. You can use this tool to get the properties of an object to see what you can check or edit.
Args:
doc_name: The name of the document to get the object from.
obj_name: The name of the object to get.
Returns:
The object and a screenshot of the object.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes | ||
| obj_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only but does not explicitly confirm safety or side effects. It does mention returning an object and screenshot, adding minimal context.
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?
Description is clear and front-loaded with purpose. Could be more concise, but structure with Args/Returns is helpful.
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 low complexity and output schema existence, description covers core functionality (object + screenshot). Lacks details on potential errors or prerequisites.
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 0% coverage; description adds explicit explanations for doc_name and obj_name in the Args section, compensating well.
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 'Get an object from a document' and explains its use to retrieve properties. It effectively distinguishes from siblings like create_object, delete_object, and edit_object.
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 when needing object properties but lacks explicit when-not or alternative guidance (e.g., when to use get_object vs get_objects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all objects in a document. You can use this tool to get the objects in a document to see what you can check or edit.
Args:
doc_name: The name of the document to get the objects from.
Returns:
A list of objects in the document and a screenshot of the document.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a list and a screenshot, but lacks explicit statement of read-only behavior 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?
The description is brief with two sentences and an Args/Returns block. It is well-structured but includes some redundancy (first sentence restates name). Still concise overall.
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 and an output schema, the description adequately covers purpose, parameter, and return value. It does not mention limitations like pagination, but that is acceptable for a straightforward 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 0%, so param description is essential. The description explains doc_name as 'the name of the document to get the objects from', adding basic meaning beyond the schema, but no format or constraints.
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?
Description explicitly states 'Get all objects in a document', using a specific verb and resource. It distinguishes from sibling tool 'get_object' by indicating all objects, making the purpose clear.
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 notes the tool can be used to see what you can check or edit, providing some context. However, it does not mention when to avoid this tool or suggest alternatives like get_object for single objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of parts in the parts library addon.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral disclosure. It only says 'Get' without mentioning readonly nature, authentication needs, or any side effects. The description adds no value beyond the tool's name.
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 sentence that immediately conveys the purpose. It is concise and front-loaded with no wasted words.
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 and an existing output schema, the description is mostly complete. It could optionally mention that this list is used before inserting parts, but it is not necessary.
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?
The input schema has no properties, so there are no parameters to describe. Schema description coverage is 100% vacuously, meeting the baseline of 4 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 'Get the list of parts in the parts library addon', specifying a concrete action ('Get') and resource ('parts list in the parts library addon'), distinguishing it from sibling tools like 'get_objects' or 'insert_part_from_library'.
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 such as 'get_objects' or 'insert_part_from_library'. No context is given about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a screenshot of the active view.
Args:
view_name: The name of the view to get the screenshot of.
The following views are available:
- "Isometric"
- "Front"
- "Top"
- "Right"
- "Back"
- "Left"
- "Bottom"
- "Dimetric"
- "Trimetric"
width: The width of the screenshot in pixels. If not specified, uses the viewport width.
height: The height of the screenshot in pixels. If not specified, uses the viewport height.
focus_object: The name of the object to focus on. If not specified, fits all objects in the view.
Returns:
A screenshot of the active view.
| Name | Required | Description | Default |
|---|---|---|---|
| view_name | Yes | ||
| width | No | ||
| height | No | ||
| focus_object | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get a screenshot' implying a read-only operation with no destructive side effects, but it does not disclose any performance implications, authorization requirements, or error handling behavior.
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 well-structured with clearly labeled sections for Args and Returns, but it includes some repetitive wording (e.g., 'The following views are available:' could be more concise). Overall, it is clear 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?
Given the tool's simplicity (screenshot capture) and the presence of an output schema, the description is sufficiently complete. It covers all parameters, their defaults, and the return type, though it could mention expected output format or dimensions.
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 0%, so the description must add meaning. It explains view_name with all enum values, width and height defaults, and focus_object purpose. This adds substantial value beyond the bare schema.
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 'Get a screenshot of the active view', specifying the verb (Get) and resource (screenshot of view). It also enumerates all available views, distinguishing it from sibling tools like get_object or get_objects which retrieve object data.
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 explains how to use the tool by listing parameters and options, but it does not explicitly state when to use this tool versus alternatives (e.g., using get_object for individual object details). No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a part from the parts library addon.
Args:
relative_path: The relative path of the part to insert.
Returns:
A message indicating the success or failure of the part insertion and a screenshot of the object.
| Name | Required | Description | Default |
|---|---|---|---|
| relative_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry full burden. It mentions it returns a message and screenshot, but does not disclose side effects (e.g., whether the document is modified) or permissions needed. Limited 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with structured Args and Returns sections. It is front-loaded with the primary action. However, the Returns section is vague ('message indicating success or failure').
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?
The tool has one required parameter and an output schema. The description explains the action and return type, but lacks context on how the part is inserted (e.g., into current document) and any preconditions. Adequate but incomplete for a mutation 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 description coverage is 0%, and the description adds minimal meaning: it restates 'relative_path' with 'The relative path of the part to insert.' This is only slightly more informative than the schema's type field, leaving the user unclear about path format or location.
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 'Insert a part from the parts library addon', specifying a concrete verb and resource. It distinguishes from sibling tools like get_parts_list (list) and create_object (generic creation) by focusing on library insertion.
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 (when you want to insert a part from the library) but does not explicitly state when to use it versus alternatives or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of open documents in FreeCAD.
Returns:
A list of document names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly states that the tool retrieves a list of document names (a read operation with no side effects). However, it does not disclose error conditions, permission requirements, or what 'open documents' means (e.g., session-scoped vs. workspace). The description 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains no extraneous information. Every sentence adds value.
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 (zero parameters, no output schema provided), the description sufficiently explains what the tool returns and the context ('open documents'). However, it could improve by specifying whether the list includes all open documents or only those in the current project.
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?
There are zero parameters, so the baseline is 4. The description does not need to add parameter information since none exist. It correctly implies that no input is required.
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 uses a specific verb ('Get') and identifies the resource ('list of open documents in FreeCAD'). It clearly distinguishes from siblings (e.g., create_document, get_objects, get_parts_list) by focusing on listing documents rather than creating them or listing objects/parts.
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 such as get_objects or get_parts_list. The context signals include many sibling tools but the description offers no usage context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close and re-open a document to pick up external file changes.
Use this AFTER the document's .FCStd file has been modified by
something outside of FreeCAD's GUI process — for example, a
headless `freecadcmd` script that edited and saved the file. The
open GUI document is otherwise unaware of on-disk changes; this
tool closes the stale in-memory copy and reopens the file from
disk so the GUI shows current geometry.
Args:
doc_name: The name of the open document to reload. Must match
the name shown by ``list_documents``.
Returns:
A message confirming the document was reloaded, or describing
the failure (document not loaded, no associated file, etc).
Examples:
```json
{
"doc_name": "chassis"
}
```
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that the tool closes the stale in-memory copy and reopens from disk, and that the GUI is otherwise unaware of changes. It also describes the return value (confirmation or failure message).
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 well-structured with a main sentence, explanation, Args, Returns, and Example. It is front-loaded with purpose. While slightly lengthy, every sentence adds value.
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 simplicity (one parameter, clear behavior), the description covers purpose, usage, parameter details, and return information. The output is described even though no output schema is provided, making it complete.
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?
The schema has one parameter with no description (0% coverage), but the description's Args section fully explains doc_name: it must match the name from list_documents. This adds crucial meaning beyond the schema.
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 explicitly states the tool's purpose: close and re-open a document to pick up external file changes. It uses a specific verb ('reload') and resource ('document'), and distinguishes itself from siblings like 'list_documents' by explaining the specific use case.
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 clearly indicates when to use this tool: after the document's .FCStd file has been modified by something outside the GUI. It provides context (e.g., headless freecadcmd script) and references list_documents for obtaining the correct doc_name. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the CalculiX solver on an existing Fem::FemAnalysis container and return summary results.
Prerequisites in the document:
- A Part-derived solid (e.g. Part::Box, PartDesign::Body) acting as the geometry.
- A Fem::AnalysisPython container created via `create_object`.
- A Fem::MaterialCommon assigned to the geometry, added to the analysis.
- A Fem::FemMeshGmsh referencing the geometry, added to the analysis (the
mesh is generated automatically when created via `create_object`).
- At least one Fem::ConstraintFixed and one Fem::ConstraintForce (or
ConstraintPressure) bound to faces of the geometry, added to the analysis.
A SolverCcxTools is auto-created if the analysis has none.
The solver runs synchronously on the FreeCAD GUI thread and blocks all
other RPC calls for its duration; do not fan out parallel requests.
Returns max von Mises stress (MPa), max/min displacement (mm), node count,
and the working directory CalculiX wrote to. On failure, returns the
prerequisite-check or solver error along with the working directory for
triage.
Args:
doc_name: Name of the FreeCAD document.
analysis_name: Name of the Fem::AnalysisPython object.
timeout: Seconds to wait for the solver (default 600).
| Name | Required | Description | Default |
|---|---|---|---|
| doc_name | Yes | ||
| analysis_name | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the solver blocks the GUI and all RPC calls, and on failure returns the working directory for triage. However, it does not clarify whether the operation is read-only or modifies the document.
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 structured with prerequisites, behavior notes, return values, and args. It is front-loaded with the purpose. Although lengthy, each section serves a clear purpose.
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 the tool (FEM analysis, no annotations, 0% schema coverage), the description provides comprehensive prerequisites, behavior constraints, return field details, and error handling, making it complete.
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?
The description lists the three parameters with minimal explanation: doc_name, analysis_name (referencing Fem::AnalysisPython), and timeout (default 600). It adds some context over the bare schema, but does not fully compensate for 0% schema coverage.
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 states it runs the CalculiX solver on an existing FemAnalysis container and returns summary results, distinguishing it from all sibling tools which are document management or object manipulation tools.
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 lists explicit prerequisites (geometry, material, mesh, constraints) and warns against fanning out parallel requests due to synchronous blocking behavior.
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 clearly distinct purpose. create_document vs create_object operate at different levels; execute_code and execute_code_async are explicitly separated by thread safety; all object-related tools (get, create, edit, delete) target different actions. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_document, get_view, run_fem_analysis). No mixing of camelCase or other conventions; every name clearly indicates its action and target.
14 tools is well-scoped for a 3D CAD automation server. It covers document management, object CRUD, code execution, FEM analysis, parts library, and visualization without being overwhelming. Each tool earns its place.
The tool set covers core workflows: document creation, object modeling of various types, FEM analysis (material, mesh, solver), parts library, and visualization. Minor gaps like explicit save or recompute exist, but these can be handled via execute_code, making the surface reasonably complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read, edit, publish, and preview your pepita websites from Claude.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yaeshio/FreeCAD-MCP-For-YDGA'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
