freecad mcp

by neka-nat

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.0.0
Disambiguation4/5
Most tools have distinct purposes, such as create_document, create_object, delete_object, and get_view, which are clearly separated. However, there is some potential overlap between create_object and edit_object, as edit_object is described as a fallback for when create_object cannot handle object creation, which might cause confusion about when to use each.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as create_document, delete_object, get_view, and execute_code. This uniformity makes the tool set predictable and easy to understand.
Tool Count5/5
With 10 tools, the server is well-scoped for a CAD modeling environment like FreeCAD. It covers essential operations like document and object management, code execution, and view handling, which aligns with the expected functionality for such a domain.
Completeness4/5
The tool set provides good coverage for core CAD operations, including creating, editing, deleting, and retrieving objects and documents, along with view management and part library access. A minor gap is the lack of a tool for saving or exporting documents, which could be a useful addition for full workflow support.
Average 3.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 18 of 26 community issues answered or closed in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a document but doesn't mention permissions needed, whether it overwrites existing documents, what happens on failure, or any side effects. The return message is mentioned but not detailed, leaving behavioral context incomplete 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 clear sections (Args, Returns, Examples) and uses only essential sentences. However, the example could be more concise by omitting the explanatory sentence, as the JSON snippet alone suffices.
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 (1 parameter, mutation operation) and the presence of an output schema, the description covers the basics but lacks depth. It doesn't explain interactions with sibling tools, error conditions, or FreeCAD-specific context, making it adequate but with clear gaps for effective agent use.
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 minimal semantics for the single parameter 'name', stating it's 'The name of the document to create'. With 0% schema description coverage, this provides basic context but doesn't elaborate on constraints like length, allowed characters, or uniqueness. The example helps but doesn't fully compensate for the lack of detailed parameter documentation.
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 action ('Create a new document') and resource ('in FreeCAD'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_object' or 'edit_object', which might also create or modify documents in FreeCAD.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_object' or 'edit_object'. It mentions no prerequisites, constraints, or scenarios where this specific document creation tool is preferred over other creation-related tools in the server.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes an object, implying a destructive mutation, but doesn't mention permissions required, whether deletion is reversible, side effects (e.g., on dependent objects), or error handling. The return message and screenshot are noted, but behavioral traits like rate limits or confirmation prompts are absent.
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 appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured for clarity, though the return statement could be more concise. Every sentence adds value, but minor verbosity in the return description prevents a perfect score.
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 complexity (destructive operation with 2 parameters) and no annotations, the description is moderately complete. It covers purpose, parameters, and returns, and an output schema exists, so return values needn't be detailed. However, it lacks critical context like safety warnings, prerequisites, or error scenarios, making it adequate but with clear gaps.
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 schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'doc_name' is 'The name of the document to delete the object from' and 'obj_name' is 'The name of the object to delete', clarifying their roles beyond schema titles. However, it doesn't provide format details, constraints, or examples, leaving gaps in parameter understanding.
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 action ('Delete') and resource ('an object in FreeCAD'), making the purpose unambiguous. It distinguishes from siblings like 'create_object' and 'edit_object' by specifying deletion. However, it doesn't explicitly differentiate from other destructive operations or mention what type of object is being deleted, keeping it from a perfect score.
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 doesn't mention prerequisites (e.g., the object must exist), when not to use it (e.g., for read-only operations), or refer to sibling tools like 'get_object' for verification. Usage is implied only through the tool name and description.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns a success/failure message and a screenshot, which adds some context beyond the input schema. However, it doesn't cover critical aspects like whether this is a read-only or destructive operation, what permissions are required, or how errors are handled. For a tool that likely modifies a document (implied by 'insert'), this is a significant gap.
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 a clear purpose statement followed by Args and Returns sections. Each sentence serves a purpose: the first explains the tool's function, and the next two detail inputs and outputs. There's no unnecessary information, making it easy to parse.
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 has one parameter with 0% schema coverage and an output schema exists (implied by the Returns section), the description is moderately complete. It covers the basic purpose and return values, but lacks usage guidelines and detailed behavioral context. For a tool that inserts parts, more information on dependencies or error conditions would improve completeness.
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 minimal semantics for the single parameter 'relative_path', explaining it as 'The relative path of the part to insert.' This provides basic meaning beyond the schema, which has 0% description coverage and only lists the parameter as a string. However, it doesn't elaborate on format, examples, or constraints, leaving the agent with incomplete 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: 'Insert a part from the parts library addon.' It specifies the verb ('insert') and resource ('part from the parts library addon'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'create_object' or 'get_parts_list', which could have overlapping functionality.
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 doesn't mention prerequisites, such as needing the parts library addon to be available, or compare it to siblings like 'create_object' for creating objects from scratch or 'get_parts_list' for listing parts. This lack of context makes it harder for an agent to choose the right tool.
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?
No annotations are provided, so the description carries full burden. It mentions retrieving an object and its properties, but doesn't disclose behavioral traits like permissions needed, whether this is a read-only operation, potential rate limits, or what happens if the object doesn't exist. The description adds some context about seeing what can be 'checked or edited' but lacks comprehensive behavioral disclosure.
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 appropriately sized and well-structured with clear sections for Args and Returns. Each sentence earns its place, though the second sentence could be more concise. The information is front-loaded with the core purpose stated first.
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 2 parameters with no schema descriptions and an output schema exists, the description adequately covers the basics but has gaps. It explains what the tool does and the parameters, but lacks behavioral context (especially important with no annotations) and doesn't fully address sibling tool differentiation. The output schema reduces the need to explain return values in detail.
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?
With 0% schema description coverage, the description compensates by explaining both parameters: 'doc_name: The name of the document to get the object from' and 'obj_name: The name of the object to get'. This adds meaningful semantics beyond the bare schema, though it doesn't provide format examples or constraints.
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 an object from a document' and 'get the properties of an object', which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'get_objects', which appears to be a plural version for retrieving multiple 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?
The description provides minimal guidance with 'You can use this tool to get the properties of an object to see what you can check or edit', but it doesn't specify when to use this versus alternatives like 'get_objects' or 'get_view'. No explicit when/when-not instructions or prerequisites are mentioned.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'a message indicating success or failure and a screenshot,' which adds some context about outputs. However, it lacks critical details for an edit operation: it doesn't specify if changes are destructive, what permissions are required, how errors are handled, or if there are rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
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 appropriately sized and well-structured: it starts with the core purpose, followed by usage guidelines, and then details parameters and returns in separate sections. Each sentence adds value, such as the alternative tool reference and output details. However, it could be more front-loaded by emphasizing key behavioral traits earlier.
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 complexity (3 parameters, nested objects, no annotations) and the presence of an output schema (which likely covers return values), the description is moderately complete. It explains the tool's purpose and usage but lacks depth in behavioral transparency and parameter semantics. For an edit tool with mutation implications, it should provide more context on safety and error handling to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description lists the parameters ('doc_name', 'obj_name', 'obj_properties') and provides brief explanations, but these are minimal and don't add meaningful semantics beyond the schema's structure. For example, it doesn't clarify what 'obj_properties' entails or provide examples. With low schema coverage, the description fails to compensate adequately.
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: 'Edit an object in FreeCAD.' It specifies the verb ('Edit') and resource ('an object'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'create_object' or 'delete_object' beyond mentioning 'create_object' in a usage context, which is helpful but not a full distinction.
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 usage guidance: 'This tool is used when the `create_object` tool cannot handle the object creation.' This indicates when to use this tool (as an alternative to 'create_object' for editing) and references a sibling tool. However, it doesn't specify when not to use it or compare to other siblings like 'delete_object' or 'get_object', leaving some gaps in full alternative coverage.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list but doesn't describe return format, pagination, error handling, or any constraints like rate limits or authentication needs, which are critical for a tool with no annotation coverage.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and sibling tools present, it lacks context on usage and behavior, making it incomplete for optimal agent selection.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but with no params, a baseline of 4 is appropriate as it doesn't need to compensate for gaps.
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 action ('Get') and resource ('list of parts in the parts library addon'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'insert_part_from_library' or 'get_objects', which would require a 5.
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 doesn't mention when to choose this over 'get_objects' or 'get_view', or any prerequisites or exclusions, leaving the agent without usage context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions returning 'a list of objects' and 'a screenshot,' which adds some context beyond basic functionality. However, it doesn't address critical behavioral aspects such as whether this is a read-only operation (implied but not stated), potential rate limits, error conditions, or how the screenshot is formatted. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement, usage hint, and sections for Args and Returns, which is organized. However, it includes redundant phrasing ('You can use this tool...') and could be more front-loaded by stating the return value earlier. The sentences are clear but not maximally efficient, with some room for trimming without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which likely details the return structure), the description is reasonably complete. It covers the purpose, parameter meaning, and return types (list and screenshot). However, without annotations, it could benefit from more behavioral details, but the output schema reduces the need to fully explain return values, making it adequate for the 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?
The description adds meaningful context for the single parameter 'doc_name': 'The name of the document to get the objects from.' This clarifies the parameter's role beyond what the schema provides (which has 0% description coverage and only states 'Doc Name' as a title). Since there's only one parameter and the description explains it adequately, this compensates well for the low schema 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 the tool's purpose: 'Get all objects in a document.' It specifies the verb ('Get') and resource ('objects in a document'), making it understandable. However, it doesn't explicitly distinguish this from sibling tools like 'get_object' (singular) or 'get_parts_list', which could cause confusion about when to use each.
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 provides some implied usage guidance: 'to see what you can check or edit.' This suggests a use case for inventorying objects before editing. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_object' (for a single object) or 'get_parts_list' (which might overlap in functionality). No clear exclusions or prerequisites are stated.
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 the tool executes arbitrary Python code, which implies mutation and potential side effects, but doesn't specify permissions needed, safety warnings (e.g., code could crash FreeCAD), or rate limits. The description adds some context by mentioning a screenshot output, but behavioral details are limited.
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 appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured but slightly verbose; every sentence adds value, such as specifying the return includes a screenshot. Minor improvements could make it more concise, but it's efficient overall.
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 (executing arbitrary code) and no annotations, the description is reasonably complete. It explains the parameter, return values (success/failure message, output, screenshot), and has an output schema. However, it lacks details on error handling or execution environment, which could enhance completeness for such a powerful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that the 'code' parameter is 'The Python code to execute,' clarifying its purpose and format. With only one parameter and no schema descriptions, this compensates well, though it could detail constraints like code length or allowed modules.
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: 'Execute arbitrary Python code in FreeCAD.' It specifies the verb ('execute') and resource ('Python code'), though it doesn't explicitly differentiate from sibling tools like 'edit_object' or 'create_object' that might also involve code execution in FreeCAD. The purpose is specific but lacks sibling distinction.
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 doesn't mention prerequisites, such as needing an active FreeCAD document, or compare it to siblings like 'edit_object' for modifying objects. Usage is implied only by the purpose statement, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Get') and specifies the return type ('screenshot'). However, it doesn't mention important behavioral aspects like whether this requires specific permissions, if there are rate limits, what format the screenshot returns (image data, file path, etc.), or if any side effects occur.
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 (Args, Returns) and uses bullet points effectively for the view list. It's appropriately sized for a single-parameter tool, though the 'Returns' section could be more informative about the screenshot format rather than just restating the purpose.
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 has an output schema (though not shown here), the description doesn't need to fully explain return values. However, for a tool with no annotations and a single parameter, the description adequately covers the core functionality but lacks context about when to use it versus sibling tools and behavioral details like permissions 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?
The description adds significant value beyond the input schema. While the schema only shows an enum of view names, the description explicitly lists all available views in a readable format and explains that these are 'the following views are available.' This provides crucial semantic context that the bare enum doesn't convey.
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 ('screenshot of the active view'). It distinguishes itself from siblings like get_object or get_objects by focusing specifically on view screenshots rather than general object retrieval.
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. While it lists available views, it doesn't explain when to choose one view over another or mention any prerequisites like needing an active view to capture. No sibling tool comparisons are provided.
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 of behavioral disclosure. It does well by specifying the return format ('A message indicating success or failure and a screenshot'), which is crucial information not in the input schema. However, it doesn't mention potential side effects (e.g., whether creation modifies existing documents), error conditions, or performance characteristics that would be helpful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and parameter explanations, but the examples section is extremely long (6 detailed examples spanning multiple object types). While valuable for parameter semantics, this makes the description verbose. Some examples could be consolidated or referenced rather than fully expanded to improve conciseness while maintaining utility.
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 (5 parameters, nested objects, 0% schema coverage, no annotations), the description provides exceptional completeness. It explains all parameters thoroughly, includes return value information, and provides extensive examples covering multiple use cases. The presence of an output schema reduces the need to document return values, but the description still adds valuable context about the screenshot inclusion.
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 0% schema description coverage, the description must fully compensate - and it does excellently. It explains all 5 parameters in detail: 'doc_name' (document to create object in), 'obj_type' (type with specific prefixes and examples), 'obj_name' (name of object), 'obj_properties' (properties of object), and even documents the optional 'analysis_name' parameter through multiple examples. The extensive examples provide concrete syntax and format guidance beyond what the bare schema offers.
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' with specific object type prefixes ('Part::', 'Draft::', etc.). It distinguishes this from sibling tools like 'create_document' (which creates documents) and 'delete_object'/'edit_object' (which modify existing objects). The verb 'create' is specific and the resource 'object in FreeCAD' is well-defined.
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 through examples showing different object types (Part::Box, Draft::Circle, Fem::AnalysisPython), but doesn't explicitly state when to use this tool versus alternatives like 'create_document' or 'edit_object'. The examples provide contextual guidance but lack explicit 'when-to-use' or 'when-not-to-use' statements that would help an agent choose between sibling tools.
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 MCP server](https://glama.ai/mcp/servers/neka-nat/freecad-mcp/badges/card.svg)](https://glama.ai/mcp/servers/neka-nat/freecad-mcp)

Score Badge

Copy to your README.md:

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

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/neka-nat/freecad-mcp'

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