FreeCAD MCP Connector

by mario-2015

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool targets a distinct resource or action: document management (create/list/reload), object CRUD (create/get/edit/delete), code execution (sync vs async), viewing, parts library (list/insert), and FEM analysis. Even execute_code vs execute_code_async are clearly separated by threading model and intended use.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (create_object, get_objects, delete_object, list_documents, run_fem_analysis). No mixed conventions or vague verbs; the naming is predictable and readable.
Tool Count5/5
14 tools is well within the ideal 3-15 range and appropriate for the broad scope of FreeCAD automation. Each tool earns its place without excessive fragmentation or unnecessary convergence.
Completeness4/5
Core CRUD for documents and objects is fully covered, along with parts library and FEM analysis execution. Minor gaps exist, such as no explicit save_document or close_document tools, but these are easily worked around via execute_code, so the surface is largely complete.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions the return value (message and screenshot) and the optional screenshot behavior (include_screenshot, view_name), but it does not disclose that the operation modifies the existing object in-place, potential side effects, reversibility, or required permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear Args section and Returns section. It is reasonably concise, though the 'Args:' list repeats parameter names without adding deep detail. Overall, it is organized and front-loaded with the purpose and a usage tip, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic inputs and return type, but lacks critical context: the format of `obj_properties` is undefined, there is no mention of error handling or partial updates, and the screenshot output format is not described. Given the tool's complexity (5 params, no output schema, no annotations), this is a moderate gap, not a complete failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It does provide basic explanations for each (e.g., `doc_name`, `obj_name`, `include_screenshot` with token-saving advice, `view_name` with guidance). However, `obj_properties` is only described as 'the properties of the object to edit', which is vague and does not clarify expected structure or allowed keys. This partial compensation lands at a neutral 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit an object in FreeCAD', which is a specific verb+resource pair. It also distinguishes from siblings by mentioning `create_object` as an alternative. However, the sentence about 'cannot handle the object creation' is confusing because the tool is for editing, not creating, slightly muddying the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a single usage context ('used when the `create_object` tool cannot handle the object creation') but does not explicitly state when not to use it, nor does it mention alternatives like `delete_object` or `get_object`. This provides some guidance but lacks comprehensive exclusions or contrasting scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It indicates a read operation but does not disclose return format, pagination, sorting, or any side effects. This is a modest but clear gap for a getter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, containing no unnecessary words. It is appropriately sized for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of behavioral information. It defines the tool's purpose but does not specify the structure or fields of the returned parts list, leaving a notable gap for an agent using the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% vacuously. The baseline for 0 parameters is 4, and the description does not need to add parameter semantics since there are none.
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 with a specific verb ('Get') and resource ('list of parts in the parts library addon'), which distinguishes it from sibling tools like insert_part_from_library and get_objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the return message, output, and screenshot, and even advises on screenshot behavior for non-visual changes. However, it does not explicitly warn about potential side effects of arbitrary code execution, such as destructive operations or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with an opening purpose statement, an Args section, and a Returns section. Each parameter explanation earns its place, especially the detailed note about include_screenshot. No redundant or verbose language is present.
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 (arbitrary code execution), the description covers the core aspects: purpose, all parameters, and return values. It lacks any mention of prerequisites (e.g., requiring an open document) or a comparison to execute_code_async, which would make it more complete for an agent evaluating alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly describes the 'code' parameter, explains 'include_screenshot' with a cost-saving rationale, and provides guidance on picking the right 'view_name' for the screenshot. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Execute arbitrary Python code in FreeCAD', providing a specific verb and resource. It clearly states what the tool does, but it does not differentiate from the sibling tool execute_code_async, which is a closely related alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus execute_code_async or other siblings. It does provide advice on setting include_screenshot to false for analytical scripts, but that is parameter-level guidance, not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return value ('a message indicating the success or failure'), which is helpful. However, it does not mention potential side effects, error conditions (e.g., duplicate name), or whether the document is persisted, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with sections for Args, Returns, and an Example. It front-loads the core purpose and avoids unnecessary detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential aspects: purpose, parameter meaning, return value, and an example. It is complete enough for most use cases, though it could mention error handling (e.g., if the document already exists) to fully round out context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly defines 'name' as 'The name of the document to create', adding meaning beyond the raw schema. The example further clarifies usage. This is adequate for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new document in FreeCAD' with a specific verb and resource, distinguishing it from sibling tools like create_object. The example reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_object. The description does not mention any prerequisites or contextual clues for when creating a document is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It states the return value and implies a read-only operation ('Get'), but does not explicitly mention that it is non-destructive, has no side effects, or depends on an open FreeCAD session. The information is adequate for a trivial getter but lacks depth.
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, using only two sentences. It front-loads the primary purpose and includes the return type without any superfluous text. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema or parameters, the description covers the essential information: what it lists and what it returns. It does not mention ordering, format, or potential exceptions, but these are likely unnecessary given the tool's simplicity. It is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The input schema is empty and the description aligns perfectly. Per the guidelines, a baseline of 4 is appropriate for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the list of open documents in FreeCAD.' It uses a specific verb ('Get') and resource ('open documents'), and specifies the return type ('a list of document names'). This distinguishes it from siblings like get_objects or create_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where other tools would be more appropriate. For a simple list operation, the use case is somewhat self-evident, but explicit guidance is missing.
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 must disclose behavior. It explains parameter defaults (e.g., width/height fall back to viewport) and return type ('screenshot'), but it does not describe the output format, prerequisites (e.g., open document), or potential errors. The phrase 'active view' is ambiguous relative to the view_name parameter, creating slight confusion.
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 Args and Returns sections, and every sentence adds value. However, it repeats the view list from the schema, which is somewhat redundant, and the opening 'active view' is slightly inconsistent with the view_name parameter. Still, it remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description covers all parameters and their defaults, but it leaves gaps: it does not specify the screenshot format (e.g., base64, file path) or any error conditions. The return description 'A screenshot of the active view' is under-specified for practical use, so the context is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter in detail: view_name lists all valid options, width/height specify pixel dimensions and default behavior, and focus_object describes the focusing rule. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a screenshot of the active view' with a specific verb and resource. It distinguishes from siblings like get_object and get_objects by focusing on screenshots rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage through the imperative 'Get a screenshot' and parameter details, but it does not explicitly state when to choose this tool over alternatives or mention exclusions. Sibling tool names suggest alternatives, but the description itself offers no guidance.
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 must fully disclose behavior. It explains that the tool 'closes the stale in-memory copy and reopens the file from disk,' which is useful. However, it does not warn about potential loss of unsaved local changes during the close/reopen cycle, which is a significant side effect. The return value descriptions are helpful, but the gap in side-effect disclosure prevents a higher score.
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 clear sections: purpose, usage context, args, returns, and an example. It is somewhat longer than necessary but each paragraph serves a purpose, and the example makes it easy to understand how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description provides a full picture: what it does, when to use it, how to specify the argument, and what to expect in return. It considers failure cases like 'document not loaded, no associated file.' The only notable omission is the unsaved-changes warning, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows doc_name as a required string with 0% coverage from the description. The description adds substantial meaning by specifying that doc_name 'must match the name shown by list_documents' and by providing an example JSON call. This clarifies the expected format and source of the value, going beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '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 sibling tools like list_documents or create_document by its focus on resyncing with disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'AFTER the document's .FCStd file has been modified by something outside of FreeCAD's GUI process.' It also gives a concrete example (headless freecadcmd script) and references list_documents for correct doc_name usage. However, it doesn't explicitly mention when not to use it, though that is reasonably implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention the return format ('a message indicating the success or failure... and a screenshot'), the purpose of view_name, and version-specific behavior for FEM mesh size limits. However, it does not disclose potential side effects such as whether an existing object with the same name is overwritten, whether the document must exist, or error handling behavior. This leaves gaps in transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections for Args, Returns, and Examples. Each example serves a distinct purpose (cylinder, circle, FEM analysis, constraint, material, mesh). The length is justified by the tool's complexity, and the structure makes it easy to scan. It could be trimmed slightly, but it remains efficient and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, multiple object types, no output schema, no annotations), the description is remarkably complete. It covers all parameter semantics, return values, special notes for FEM mesh (including FreeCAD 1.x key differences), and provides extensive examples. The only minor issue is the omission of analysis_name from the Args list, which is still evident from examples. This is a comprehensive description for a complex 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?
Schema description coverage is 0%, so the description must compensate. It explains doc_name, obj_type, obj_name, obj_properties, include_screenshot, and view_name in the Args section, and provides detailed examples for each parameter, including nested obj_properties. However, analysis_name, which appears in the schema and examples, is missing from the Args list, leaving a minor gap. Overall, the description adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states its purpose: 'Create a new object in FreeCAD.' It specifies the verb 'create', the resource 'new object', and narrows the scope by enumerating valid type prefixes like 'Part::', 'Draft::', 'PartDesign::', and 'Fem::'. This distinguishes it from sibling tools like create_document (which creates documents) and edit_object (which edits existing objects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (creating objects of various types) and includes practical advice, such as setting include_screenshot to False for intermediate steps to save tokens. However, it does not explicitly contrast this tool with alternatives like edit_object or delete_object, nor does it state situations where this tool should NOT be used. It provides clear context but no explicit 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 present, so the description must carry the full burden. It discloses the return format (message and screenshot) and parameter effects, but omits whether deletion is permanent, whether permissions are required, or what happens to dependent objects. This is an adequate disclosure for a simple deletion but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns, and every sentence provides useful information. It is slightly longer than strictly necessary but remains focused and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no output schema, the description covers inputs, defaults, and the success/failure message plus screenshot. It does not explain potential error conditions or side effects beyond the deletion itself, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates fully by explaining every parameter: doc_name, obj_name, include_screenshot, and view_name. It adds practical context, such as when to set include_screenshot to False and choosing the view that best shows the change. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete an object in FreeCAD', which names a specific action and resource. This clearly distinguishes it from sibling tools like create_object, edit_object, and get_object. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to set include_screenshot to False (e.g., intermediate steps to save tokens), but does not explicitly compare to alternative tools. The context of deleting versus editing/creating is implicit, so it falls short of a 5 but is better than no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return behavior (object plus screenshot), explains that include_screenshot can be disabled to save tokens, and describes view_name affecting the screenshot. It does not explicitly state read-only behavior, but 'get' and the inspection purpose imply it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an opening summary, a usage justification, a clear Args list, and a Returns section. Every sentence serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description covers tool purpose, parameter semantics, and return values. However, it does not specify the format of 'the object' or error conditions, leaving some ambiguity that could affect agent reliability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain all parameters and does so: doc_name and obj_name are self-explanatory, include_screenshot includes token-saving guidance, and view_name is described as affecting the screenshot orientation. This fully compensates for the missing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get an object from a document' with a specific verb and resource, and clarifies the tool's purpose: 'to get the properties of an object to see what you can check or edit.' This differentiates it from sibling tools like get_objects (plural) and get_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a use case ('to see what you can check or edit') but does not explicitly state when to prefer this over alternatives or mention any exclusions. It implies usage but lacks direct guidance on choosing between get_object, get_objects, or get_view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return format (list and screenshot), a token-saving option (include_screenshot=False), and screenshot view orientation. It doesn't explicitly state read-only, but 'get' implies no side effects, which 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a clear intro followed by Args and Returns sections. It is not overly verbose, each sentence adds value, though the second sentence ('You can use...') is slightly redundant with the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description covers all parameters, return value, and behavioral nuances. It is complete for typical usage, but does not mention error cases or performance implications, so not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains doc_name as target document, include_screenshot with a cost-saving rationale, and view_name as screenshot orientation. This adds meaning beyond the schema's enum/default fields.
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?
Description states 'Get all objects in a document' with a specific verb and resource, and clearly differentiates from singular get_object by emphasizing 'all objects'. It also provides a purpose hint ('see what you can check or edit').
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?
Explicitly says 'You can use this tool to get the objects in a document to see what you can check or edit', giving a clear usage context. However, it does not explicitly mention alternatives like get_object or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of behavioral disclosure. It explains that the tool returns a screenshot by default, and provides advice to set include_screenshot=False to save tokens for intermediate steps, which is useful behavioral context. It also clarifies the view_name parameter for selecting the best view. However, it does not explicitly mention that inserting a part modifies the current document, though this is strongly implied by 'insert'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured using an Args/Returns format. It front-loads the main purpose in the first sentence and each parameter description earns its place by adding useful guidance. There is no wasted text or repetition.
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 having no annotations or output schema, the description provides enough context for an agent to use the tool effectively: the action, all parameter details, return format, and practical tips on token usage and view selection. It is complete for a relatively simple insertion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully explain the parameters. It does exactly that: relative_path is 'the relative path of the part to insert,' include_screenshot is explained with a concrete cost-saving rationale, and view_name is described with orientation defaults and guidance on choosing the best view. This adds significant meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Insert a part from the parts library addon.' This uses a specific verb ('Insert') and resource ('part from the parts library addon'), which distinguishes it from sibling tools like create_object (which creates new objects from scratch) and get_parts_list (which lists parts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (for inserting parts from the library) but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or alternative tools. It relies on the tool name and the mention of the 'parts library addon' to hint at its niche, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it reveals auto-creation of SolverCcxTools, synchronous blocking on the GUI thread, failure return behavior, and runtime side effects like writing to a working directory. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and information-dense, with a clear main action, organized prerequisites, behavioral notes, and parameter descriptions. No unnecessary words—each sentence contributes meaning.
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 complexity of a FEM solver tool with no output schema, the description is highly complete: it specifies prerequisites, return values (max von Mises stress, displacements, node count, working directory), failure modes, and blocking behavior. It provides enough context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter in the Args section. It provides semantic details for timeout, include_screenshot, and view_name, and contextualizes doc_name/analysis_name through the prerequisites list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run the CalculiX solver on an existing Fem::FemAnalysis container and return summary results.' This specifies a verb (run), resource (CalculiX solver on Fem::FemAnalysis container), and distinguishes it from sibling tools like create_object or execute_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed prerequisites and usage context, including document requirements and synchronous blocking behavior with guidance to not fan out parallel requests. It lacks explicit alternatives or exclusions, but clear context is given for when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the code runs in a background thread, returns immediately, and must NOT call FreeCADGui APIs, manipulate the view/selection, create/edit objects, change properties, recompute, or save documents. It also outlines a typical usage pattern to safely manage state, providing deep behavioral insight beyond minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: definition, usage restriction, alternative, typical usage pattern, and args/returns. Every sentence adds necessary context—there is no fluff or redundancy. The length is justified by the number of constraints that must be communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is remarkably complete. It covers purpose, constraints, usage alternatives, a safe state-management pattern, and the return value ('A message confirming that background execution has started'). An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description explicitly adds meaning for the `code` parameter: 'Background-safe Python code to execute.' This clarifies that the code must be non-GUI and non-document-mutating, a critical qualifier not present in the schema. Given the single simple parameter, this amount of semantic addition is strong, though it stops short of providing code examples or further parameter detail.
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 first sentence states the specific action: 'Execute Python code in FreeCAD without waiting for completion.' It clearly identifies the resource (Python code in FreeCAD) and the async behavior. It also distinguishes itself from `execute_code` by noting the thread difference, fulfilling the sibling differentiation requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this ONLY for long-running background computations that do NOT touch the FreeCAD GUI or mutate the FreeCAD document tree directly.' It also provides a clear alternative: 'For code that touches FreeCAD documents... use execute_code instead.' This defines the exact boundary and names the sibling alternative.
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

freecad-mcp-connector-for-claude-desktop MCP server

Copy to your README.md:

[![freecad-mcp-connector-for-claude-desktop MCP server](https://glama.ai/mcp/servers/mario-2015/freecad-mcp-connector-for-claude-desktop/badges/card.svg)](https://glama.ai/mcp/servers/mario-2015/freecad-mcp-connector-for-claude-desktop)

Score Badge

Copy to your README.md:

[![freecad-mcp-connector-for-claude-desktop MCP server](https://glama.ai/mcp/servers/mario-2015/freecad-mcp-connector-for-claude-desktop/badges/score.svg)](https://glama.ai/mcp/servers/mario-2015/freecad-mcp-connector-for-claude-desktop)

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/mario-2015/freecad-mcp-connector-for-claude-desktop'

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