FreeCAD MCP Next

by Lumitorus

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clear distinct purposes (create, edit, delete, get, list, execute, run FEM). The main ambiguity is edit_object, whose description says it is used 'when create_object cannot handle object creation,' blurring the line between creating and editing. execute_code and execute_code_async are clearly differentiated by threading and GUI-safety rules.
Naming Consistency4/5
Tool names generally follow a consistent verb_noun snake_case pattern (create_object, get_object, delete_object, reload_document, run_fem_analysis). Minor inconsistencies exist: get_parts_list uses 'get' while list_documents uses 'list' for essentially the same operation, and execute_code_async uses a suffix rather than a verb-prefix pattern.
Tool Count5/5
14 tools is within the well-scoped 3-15 range and each tool addresses a distinct aspect of FreeCAD automation: document management, object CRUD, inspection, code execution, view capture, parts library access, and FEM analysis. No tools feel redundant or extraneous.
Completeness4/5
The surface covers the core lifecycle well: create_document, create/edit/delete_object, get_object(s), list_documents, and run_fem_analysis provide solid end-to-end workflows. Minor gaps exist, such as no explicit save_document or close_document tool, though reload_document implies an external-editing workflow and most gaps can be worked around via execute_code.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states that a screenshot is returned and does not disclose whether the operation is read-only, whether a document must be loaded, what format the screenshot takes, or any side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with Args and Returns sections and is appropriately concise. The view list is redundant with the schema enum and the final 'Returns' line largely restates the first sentence, but the overall structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no annotations, and no output schema, so the description must carry more weight. It explains parameter defaults well and gives a basic return statement, but it omits the exact output format, prerequisites, and any caveats about view state or object focus behavior.
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?
Although schema description coverage is 0%, the description adds meaningful semantics for all four parameters: view_name lists the valid values, width/height explain default viewport fallback, and focus_object explains the fit-all-objects default. This goes well beyond the raw schema defaults.
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 'Get a screenshot of the active view' and enumerates the available standard views, making it distinguishable from sibling get_* tools that return object data. Some ambiguity remains because 'active view' could imply the current viewport while view_name explicitly selects one of the listed views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use get_view versus alternatives such as get_object or execute_code. The purpose is implied by the verb and parameter descriptions, but no prerequisites, exclusions, or sibling comparisons are provided.
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?
The description states a return message indicating success or failure, which is a behavioral trait. However, it does not disclose potential side effects like whether the document becomes active, what happens if the name already exists, or any permissions required. No annotations are present, so the description carries full burden and only partially meets it.
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 Args, Returns, and Examples sections. It front-loads the purpose and provides an example without excessive verbosity. The example section is somewhat redundant but adds practical value for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter creation tool, the description is adequate but lacks detail on error handling, naming rules, or interaction with other FreeCAD elements. It does not mention uniqueness or whether the document becomes active, which are important for an agent. The absence of output schema makes it sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a brief explanation of the 'name' parameter and provides a concrete JSON example, which compensates for the lack of schema descriptions. However, it does not specify constraints like uniqueness, allowed characters, or length limits. The example is helpful but limited.
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,' which uses a specific verb and resource. This distinguishes it from sibling tools like 'create_object' which creates objects within a document. The purpose is unambiguous and immediately understandable.
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. The description gives no context about document hierarchy or when one might prefer creating an object instead. The example is illustrative but does not clarify usage conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that include_screenshot defaults to True and can be set to False to save tokens, and that view_name controls the screenshot orientation. However, it doesn't mention any side effects, permissions, or performance implications beyond token usage. It's a read operation implied by 'get', but not explicitly stated as non-destructive.
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 concise and well-structured with an Args/Returns section. It front-loads the purpose and provides practical usage tips. No wasted words, though the Returns section is minimal.
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 tool's moderate complexity (3 params, 1 required, no output schema), the description covers the basics but lacks detail on return structure, error cases, or how the screenshot relates to the object list. It's adequate for a simple read tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains doc_name, include_screenshot (with token-saving tip), and view_name (orientation). However, it doesn't detail the enum values for view_name beyond the schema, and the return format is only briefly mentioned. The description adds some value but not comprehensive parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all objects in a document' and explains its use case ('to see what you can check or edit'). It distinguishes from sibling tools like get_object (singular) and get_view, though it doesn't explicitly name alternatives. The verb 'get' and resource 'objects in a document' are specific.
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: use this to get objects for checking or editing. It doesn't explicitly state when not to use it or mention alternatives like get_object for a single object. The context is clear but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that it returns a message and screenshot, and that include_screenshot can be set to False for cost savings. It does not disclose whether the deletion is permanent, irreversible, or if there are any side effects (e.g., cascading deletions) beyond the declared return. With no annotations provided, the description carries the full burden, and while it adds some transparency (screenshot behavior), it lacks details on deletion semantics.
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 compact and well-structured: a one-line purpose, clear parameter explanations, and a return statement. Every sentence adds value: explaining the screenshot flag and view orientation selection. No redundancy or fluff.
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 (4 params, no output schema, no annotations), the description provides adequate coverage: it explains all parameters, gives guidance on usage (screenshot for intermediate steps), and states the return. It lacks explicit mention of error conditions or effects of deletion, but for a simple mutation tool, this is reasonably complete. No output schema means description must convey return, which it does.
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 compensate. It explains doc_name and obj_name (identifying the target), and explains include_screenshot and view_name with their defaults and purpose. However, it doesn't provide additional syntax constraints or examples beyond what the schema already shows (defaults, enums). It does add meaningful context (screenshot token saving logic), which is helpful, but not exhaustive.
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 'Delete an object in FreeCAD' with specific verb (delete) and resource (object in a document). It distinguishes from siblings like edit_object or create_object. However, it could be more explicit that it deletes from a specific document and that deletion is permanent, but the core purpose is clear.
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 context on when to use include_screenshot (e.g., for intermediate steps) and when to set it to False to save tokens. It doesn't explicitly exclude alternatives or mention when not to use, but it implies usage context. No direct comparison to sibling tools like edit_object or get_object, but it does give practical guidance on one parameter.
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 behavior (message plus screenshot) and the token-saving rationale for include_screenshot=False. However, it does not explicitly state side effects on the current document, failure conditions beyond a generic message, or path-resolution context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence purpose, an Args section, and a Returns section. Every sentence adds useful information, and the guidance about saving tokens is valuable without being verbose.
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 low complexity, no annotations, and no output schema, the description covers the essential invocation details: path, screenshot toggle, view selection, and return value. It could be more complete by clarifying what 'insert' modifies and where relative_path resolves, but it is otherwise adequate for an agent to invoke the 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 all three parameters, including defaults and usage guidance for include_screenshot and view_name. The main gap is relative_path: it says 'relative path' but does not specify relative to what directory or library root.
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 a specific verb and resource: 'Insert a part from the parts library addon.' This clearly distinguishes it from siblings like create_object or edit_object, and the tool name reinforces the library-source scope.
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 clear context for the tool's main use and provides practical guidance for include_screenshot and view_name. However, it does not explicitly state when to prefer this tool over alternatives such as create_object, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns a message and screenshot, and gives parameter-specific behavior (including token-saving advice for include_screenshot). However, it does not mention any side effects, reversibility, or required permissions for editing an object, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement, usage note, Args list, and Returns section. It is concise yet detailed, with no filler. The token-saving tip adds operational value without unnecessary length.
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 (5 params, nested obj_properties, enum for view_name, no output schema), the description provides adequate context: all parameters are explained, return type is specified, and usage notes are included. It lacks detailed structure for obj_properties, but that is domain-specific.
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 description explains all five parameters in plain language, including defaults and usage guidance (e.g., 'Pick the view that best shows the change being made'). This fully compensates for the 0% schema description coverage.
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' with a specific verb and resource. It also contrasts with create_object, but the phrase 'cannot handle the object creation' makes the relationship between editing and creating somewhat ambiguous, slightly diminishing sibling differentiation.
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?
It explicitly states 'This tool is used when the create_object tool cannot handle the object creation' and provides guidance for include_screenshot (set False for intermediate steps to save tokens). No other alternatives are mentioned, but this is sufficient.
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 burden. It clearly states the tool executes arbitrary Python code recognition of side effects and describes the return structure (message, output, screenshot). It also gives practical guidance on include_screenshot to save tokens when appearance doesn't change. However, it does not mention potential side effects like persistent changes to the model or security implications, but it's reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections. Every sentence adds value. No fluff.
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 code execution tool, it covers purpose, parameters, and return values, and even gives usage guidance for include_screenshot. However, it doesn't differentiate from execute_code_async or mention potential restrictions. Given the complexity, it's fairly complete but could add a note about async or side effects.
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% (no parameter descriptions in schema), so description must compensate. It does: explains code, include_screenshot with guidance, and view_name with suggestion to pick best view. This adds meaning beyond the schema, which only has types and enums.
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 purpose with a specific verb (execute) and resource (arbitrary Python code in FreeCAD). This distinguishes it from siblings like create_object and delete_object, and implicitly from execute_code_async via the 'arbitrary' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives like execute_code_async, nor does it mention when not to use it. It only provides guidance for the include_screenshot parameter (e.g., set False for non-visual changes). No exclusions or alternatives are mentioned, so usage context is lacking.
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 provided, the description carries the burden and does disclose helpful behavioral details: it returns both the object and a screenshot, and explains that include_screenshot=False saves tokens. It does not explicitly say the operation is read-only, but the retrieval semantics and return wording make that a safe inference.
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 compact and well-organized: a clear one-sentence purpose, a practical use statement, an Args section, and a Returns line. There is no unnecessary fluff or repeated schema enums.
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 retrieval tool with no output schema and no annotations, the description covers required parameters, optional parameters/defaults, and return shape. It is mostly complete, though it could mention behavior when include_screenshot is false and how the returned object data is structured.
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 gives 0% parameter descriptions, so the Args section compensates by explaining all four parameters: doc_name, obj_name, include_screenshot, and view_name. It adds useful meaning such as token-saving behavior for include_screenshot and return-screenshot orientation for view_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an object from a document and clarifies that this is for inspecting its properties before checking or editing them. This aligns with the sibling set but does not explicitly distinguish it from get_objects or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear intended use case: get the properties of an object to see what can be checked or edited. It does not mention exclusions or compare with alternatives, but the context is specific enough to guide basic selection.
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 that the tool returns a success/failure message and a screenshot, and explains the include_screenshot parameter for saving tokens. It also notes that the Shape property is required for FEM meshes and mentions version-specific key names (CharacteristicLengthMax/Min vs ElementSizeMax/Min). This is good behavioral context beyond the schema, though it doesn't detail side effects like whether existing objects are overwritten or if permissions are needed.
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 intro, Args list, Returns note, and multiple examples. It is longer than ideal but each example serves a distinct purpose (Part, Draft, FEM analysis, constraint, material, mesh). The front-loading is good: the first sentence states the purpose. The length is justified by the complexity of the tool, but it could be slightly trimmed by consolidating examples.
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 (7 parameters, nested objects, multiple object types), the description is quite complete. It covers return values (message + screenshot), parameter semantics, and provides examples for various use cases. The output schema is absent, so the description's mention of the return format is helpful. However, it doesn't cover all possible object types or edge cases, and some parameters like analysis_name are only implicitly explained. Still, for a tool of this complexity, it is above average.
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 each parameter in the Args section: doc_name, obj_type, obj_name, obj_properties, include_screenshot, view_name, and analysis_name (implied in examples). The examples provide concrete usage patterns for obj_properties, including nested structures like Placement and ViewObject. This adds significant meaning beyond the bare schema, though some parameters like analysis_name are only explained through examples rather than explicit text.
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: 'Create a new object in FreeCAD' and specifies the object type prefixes (Part::, Draft::, PartDesign::, Fem::). It distinguishes from siblings like create_document (which creates documents) and edit_object (which modifies existing objects). The verb 'create' plus the resource 'object' is specific and 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?
The description provides clear context on when to use this tool (creating objects in FreeCAD) and includes multiple examples covering different object types (Part, Draft, FEM). It does not explicitly state when NOT to use it or name alternative tools, but the examples and the distinction from create_document are implicit. The guidance is strong but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly states a read-only 'Get' operation, implying no unintended side effects. For a zero-parameter list tool, this is adequate, though it could have mentioned any sorting, filtering, or return format specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the action, and contains no filler words or unnecessary details.
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 minimal complexity (0 parameters, no annotations, no output schema), the description sufficiently explains what the tool does and what it returns. Nothing critical is missing 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so there are no parameter semantics to explain. The baseline of 4 applies, and the description does not need to compensate for any undocumented 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?
The description clearly states the verb ('Get'), the resource ('list of parts'), and the specific scope ('parts library addon'), making its purpose unambiguous. It also implicitly distinguishes itself from sibling tools like get_objects and insert_part_from_library, which address different resources or actions.
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 usage context is implied: call this tool to retrieve the list of parts from the parts library. However, there is no explicit guidance about when to choose this over get_objects or insert_part_from_library, nor any exclusion criteria, so it only partially addresses alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states that the tool returns a list of document names, implying a non-destructive read operation. The phrasing 'Get the list' communicates safety, and no hidden side effects are suggested. It does lack an explicit statement that it does not modify state, but for a list-only tool this is adequate.
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 compact, consisting of two clear sentences with no redundant text. It front-loads the core purpose and directly states the return value, making it easy for an agent to parse quickly.
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 simplicity of the tool—zero parameters, no output schema, and a straightforward list of names—the description is fully complete. It provides all necessary information without requiring additional behavioral or contextual notes.
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, which sets a baseline of 4. The description naturally adds no parameter details, and the schema is empty, so there is nothing missing. The description's mention of the return type compensates for the lack of parameter context.
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 action (Get) and resource (open documents in FreeCAD), and explicitly notes the return type (list of document names). This distinguishes it from sibling tools like get_objects and get_parts_list, which operate on different entities within the application.
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 implied usage is when you need the names of currently open documents, and it is a read operation. However, there is no explicit guidance on when not to use it or alternatives (e.g., get_objects for detailed object information), leaving the agent to infer from sibling names.
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 responsibility and handles it well. It discloses that a SolverCcxTools is auto-created if absent, that execution blocks the GUI thread synchronously, what happens on failure, and what return values are produced. This is substantial behavioral transparency beyond the input schema.
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 labeled sections: prerequisites, behavior note, return values, and arguments. It is long because the tool is complex, but every sentence provides necessary operational detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is remarkably complete. It covers prerequisites, side effects, synchronous blocking, failure behavior, output data, and parameter semantics, giving the agent all needed context to invoke the tool 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?
The schema has 0% description coverage, but the Args section fully compensates by explaining every parameter beyond raw schema definitions. It adds practical guidance such as 'Set to False to save tokens when only the numeric results are needed' for include_screenshot and clarifies the meaning of timeout and view_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run the CalculiX solver on an existing Fem::FemAnalysis container and return summary results.' This clearly distinguishes it from sibling tools like create_object, get_object, and edit_object, which manage objects rather than execute an analysis.
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 prerequisites section thoroughly explains the conditions required before using the tool, and the blocking-behavior warning explicitly tells the agent when not to use it in parallel: 'do not fan out parallel requests.' It does not explicitly name alternative tools, but no sibling tool provides equivalent functionality, so 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly explains background-thread execution, immediate return, restrictions on FreeCADGui/document operations, and what the return message will be. This is far more transparent than a typical tool description.
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 long but well-structured with an opening one-line definition, followed by a focused restriction block and a numbered workflow. Some repetition between the restriction examples and the alternative-tool guidance is useful for safety-critical boundaries, though slightly more than strictly necessary.
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 output schema and no annotations, this description is unusually complete for a single-parameter background execution tool. It defines the async behavior, unsafe but also safe use cases, how to coordinate with execute_code, and what the return confirmation is. The agent has enough context to safely invoke and choose this 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, listing only 'code' as a string, while the description compensates fully by defining it as 'Background-safe Python code to execute' and explaining what kinds of code are allowed versus forbidden. Despite there being only one parameter, the description gives strong semantic guidance about what the code parameter may contain.
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 a specific verb and resource: 'Execute Python code in FreeCAD without waiting for completion.' It clearly distinguishes this tool from the sibling execute_code by contrasting background versus GUI-thread execution, so an agent can tell them apart.
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 gives explicit when-to-use and when-not-to-use guidance: 'Use this ONLY for long-running background computations' and 'use execute_code instead' for anything touching the GUI/document. It also provides a numbered typical usage pattern, making the selection and invocation workflow highly actionable.
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?
Even with no annotations, the description fully discloses behavior: it closes the stale in-memory copy and reopens from disk, including potential failure modes ('document not loaded, no associated file'). It also implies side effects by noting it reopens from disk, which covers the possibility of discarding unsaved changes without explicit warning, but that is inherent to the described action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary, usage guidance, Args section, Returns section, and a JSON example. Every sentence adds value, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return values ('A message confirming the document was reloaded, or describing the failure'). With one parameter and clear behavior, the description is fully complete for an agent to invoke 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?
The schema provides only a generic string parameter, but the description adds clear meaning: 'doc_name: The name of the open document to reload. Must match the name shown by list_documents.' This fully compensates for the 0% 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 clearly states the tool's purpose: 'Close and re-open a document to pick up external file changes.' This is a specific verb-resource combination that distinguishes it from siblings like list_documents or edit_object, which do not perform reload actions.
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?
Provides explicit usage context: 'Use this AFTER the document's .FCStd file has been modified by something outside of FreeCAD's GUI process' and explains why (the GUI is unaware of on-disk changes). It also clarifies when not needed implicitly by describing the specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![freecad-mcp-next MCP server](https://glama.ai/mcp/servers/Lumitorus/freecad-mcp-next/badges/card.svg)](https://glama.ai/mcp/servers/Lumitorus/freecad-mcp-next)

Score Badge

Copy to your README.md:

[![freecad-mcp-next MCP server](https://glama.ai/mcp/servers/Lumitorus/freecad-mcp-next/badges/score.svg)](https://glama.ai/mcp/servers/Lumitorus/freecad-mcp-next)

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/Lumitorus/freecad-mcp-next'

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