freecad-mcp

by mars720816

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.1.12
Disambiguation5/5
Each tool targets a distinct purpose: document creation, object CRUD, viewing, code execution, and parts library operations. The only potential overlap is between create_object and edit_object, but they clearly separate creation from modification.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (create_document, get_objects, insert_part_from_library). The style is uniform and readable throughout.
Tool Count5/5
With 10 tools, the server covers the core FreeCAD workflows (document, object, view, parts library, code execution) without unnecessary bloat. The count feels right for the scope.
Completeness4/5
The toolset provides solid coverage for creating, reading, updating, and deleting objects, plus viewing and parts library access. Missing features like save/export are likely handled via execute_code, but there are a few minor gaps in document-level lifecycle management.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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, the description must disclose behavioral traits. It mentions the return of a success/failure message and a screenshot, but it does not explain side effects, whether edits are saved, or permission requirements. It gives minimal insight into how the editing affects the object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the main purpose. It includes a structured Args section and a Returns section, which aids readability. The 'This tool is used when' sentence is slightly redundant but does not significantly bloat the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for correct invocation. It does not explain how obj_properties should be formatted, what constitutes success or failure messages, or how this tool differs from create_object and delete_object. The screenshot mention is helpful but not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The descriptions for all three parameters are essentially tautological: doc_name is 'the name of the document', obj_name is 'the name of the object', and obj_properties is 'the properties of the object'. Schema coverage is 0%, so the description should compensate, but it provides no additional meaning about the structure of obj_properties or any 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 'Edit an object in FreeCAD' with a specific verb and resource. It also references create_object as a sibling, though the wording of 'object creation' is confusing. The core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a conditional usage statement ('used when the `create_object` tool cannot handle the object creation'), but this is misleading since it implies a fallback for creation rather than editing. It does not offer clear guidance on when to choose edit_object over alternatives.
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, the description must reveal behavioral traits. It mentions the return value (a message and screenshot) but does not disclose prerequisites, side effects, failure conditions, or whether the operation is reversible. Since this is an insert operation, more context is 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 concise and well-structured with an initial summary sentence and Args/Returns sections. It contains no fluff, though the minimal detail in the Args section could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, the absence of annotations, and the need for usage guidance, the description is incomplete. It covers the basic action and return format but omits when-to-use context, behavioral caveats, and parameter context.
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 has no parameter descriptions, so the description must compensate. It provides a basic definition for relative_path ('The relative path of the part to insert'), which adds some meaning, but it lacks details such as base path, accepted formats, or how it is resolved.
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 a specific verb and resource: 'Insert a part from the parts library addon.' This distinguishes it from sibling tools like create_object, edit_object, or get_parts_list, which have different purposes.
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 only states what it does, not in what context it should be chosen over other tools like create_object or get_parts_list.
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 only says 'get the list' but doesn't clarify whether this is a read-only operation, what the response format is, or any other behavioral nuances. For a simple list tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary filler, making it easy for an agent to quickly 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 zero-parameter nature and simple purpose, the description is minimally viable. However, with no output schema and no annotations, it lacks additional context such as the structure of the returned list or how it relates to sibling tools like insert_part_from_library.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot be expected to explain parameter semantics. The baseline for 0-parameter tools is 4, and the description sufficiently identifies what the list pertains to.
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 the list') and the resource ('parts in the parts library addon'), making the tool's basic purpose obvious. It does not explicitly distinguish it from siblings like insert_part_from_library, but the distinction is fairly apparent from the descriptions themselves.
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 that it might be a prerequisite for insert_part_from_library or any other 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?
With no annotations, the description must disclose behavioral traits, but it only states that arbitrary code is executed and a message/output/screenshot are returned. It does not mention potential side effects, document modifications, error handling, or any security concerns inherent to executing arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with arguments and returns sections, each sentence serving a purpose. It avoids unnecessary elaboration while communicating the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for an arbitrary code execution tool: it fails to explain the execution environment, whether code can mutate the document, what 'the object' in the screenshot refers to, or any constraints. The absence of annotations and output schema makes these omissions more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a property named 'code' with title 'Code' and zero description coverage. The tool description compensates by specifying 'code: The Python code to execute,' clarifying the parameter's purpose, which is sufficient for a single code parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute arbitrary Python code in FreeCAD' with a specific verb and resource, clearly distinguishing it from sibling tools that handle object/document management. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It does not mention prerequisites, limitations, or when to choose a more specific tool like edit_object or get_objects, leaving usage context entirely implicit.
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 transparency burden. It discloses that the tool creates a document and returns success/failure, but does not explain side effects, permissions, or behavior if the document already exists. This is adequate for a simple create operation but lacks deeper behavioral detail.
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 Args, Returns, and Examples sections. It is concise, front-loaded with the main action, and every line adds value without waste, including a helpful JSON example.
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 one-parameter tool with no output schema, the description covers the action, parameter, return value, and includes an example. It is complete enough for straightforward use, though it could mention behavior around duplicate names or prerequisites to be fully comprehensive.
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 explains the sole parameter 'name' with a clear purpose ('The name of the document to create') and includes a full example JSON. Schema coverage is minimal, but the description compensates by providing a concrete usage example, adding meaning beyond the schema's field title.
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 uses a specific verb+resource ('Create a new document in FreeCAD') clearly stating the function. It doesn't explicitly differentiate from sibling create_object, but the resource (document vs object) is distinct, making the purpose clear without explicit sibling comparison.
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 explicit guidance on when to use this tool instead of sibling tools like create_object. The example illustrates usage but does not discuss context, alternatives, or exclusions, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that the tool returns a success/failure message and a screenshot, which is useful. It also notes a required property for FEM mesh (Part). However, it does not disclose potential side effects (e.g., what happens if doc_name doesn't exist), whether objects with the same name are overwritten, or any error behavior beyond generic success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with Args, Returns, and Examples sections. The examples are extensive but serve a clear purpose in illustrating usage for different object families (Part, Draft, PartDesign, FEM). There is some redundancy (multiple FEM examples) but the structure keeps it navigable and information-dense.
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 parameters, nested obj_properties, no annotations or output schema), the description provides strong context through multiple examples covering various object types and optional parameters. However, it omits analysis_name from the formal Args explanation and does not clarify which parameters are optional beyond schema defaults, leaving small 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?
Schema description coverage is 0%, so the description must explain parameters. It does explain doc_name, obj_type, obj_name, and obj_properties in the Args section, and provides detailed examples of obj_properties for various object types. However, the analysis_name parameter is missing from the Args list and only appears in examples, leaving a gap for schema users.
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 'Create a new object in FreeCAD' with a specific verb and resource. It differentiates from sibling tools like create_document by focusing on objects rather than documents, and lists object type prefixes. However, it does not explicitly name alternatives or contrast with other create/edit tools.
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 extensive examples imply when to use different object types (e.g., Part::Cylinder, Draft::Circle, Fem::ConstraintFixed) and provide context for FEM-specific parameters. However, it does not explicitly state when to use this tool instead of create_document or edit_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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It mentions returning a success/failure message and a screenshot, but does not warn about irreversibility, side effects (e.g., cascading deletions), permissions, or what happens if the object does not exist. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with separate Args and Returns sections. Every sentence adds value, and there is no excessive detail or repetition.
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 simplicity, the description covers the core behavior but misses important context for a destructive action (e.g., permanence, error handling, prerequisites). The return value is described, and having no output schema reduces the burden, but a warning about deletion consequences would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% description coverage, the description's Args section explicitly explains doc_name and obj_name, adding meaning beyond the parameter names. This compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an object in FreeCAD' with specific parameters, distinguishing it from sibling tools like create_object and edit_object. The verb 'delete' and resource 'object' make the purpose unambiguous.
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 when you need to delete an object), but does not explicitly state when to use it over alternatives or any exclusions. No alternatives are named, but the context of siblings makes the intended use clear.
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 burden. The term 'screenshot' implies a read-only, non-destructive operation, but the description does not explicitly state this nor disclose edge-case behavior (e.g., invalid view names, permission requirements, or return format details). Minimal behavioral context beyond the obvious.
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 succinct and well-structured with Args and Returns sections. It includes necessary details without excess, and listing the view names is helpful even if redundant with the schema. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single enum parameter and no output schema, the description provides enough information: what it does, the accepted inputs, and the return type. It lacks only an explicit statement that this is a read-only operation, which could be inferred. Overall, it is sufficiently complete for an agent to select and invoke correctly.
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% since the schema lacks descriptive text for the parameter. The description defines view_name as 'the name of the view to get the screenshot of' and enumerates all valid values, adding clarity. However, this largely duplicates the enum in the schema rather than providing new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a screenshot of the active view' with a specific verb and resource. It distinguishes from sibling tools like get_object and get_objects by targeting views specifically.
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 lists valid view names and explains the input format, giving clear context for parameter usage. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, leaving usage guidance implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (list of objects and a screenshot), which is useful behavioral context. However, without annotations, it does not explicitly state that the operation is read-only or has no side effects, leaving a gap for a tool with no annotation support.
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 short and front-loaded, with a clear Args/Returns structure. Minor redundancy between the first two sentences ('Get all objects in a document' vs 'You can use this tool to get the objects in a document') prevents a perfect score.
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 one parameter and no output schema, the description covers the input, output, and general purpose. It lacks detail on potential errors or ordering, but that is not critical for this level of complexity.
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 schema description coverage at 0%, the description compensates by defining doc_name as 'The name of the document to get the objects from.' This adds clear meaning beyond the schema's type and title. While not exhaustive, it provides sufficient context for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all objects in a document' with a specific verb and resource. It distinguishes from sibling tool 'get_object' by explicitly saying 'all objects', and from 'get_parts_list' by referring to objects generally. The phrase 'see what you can check or edit' clarifies its purpose for inspection.
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?
Gives a clear use case: 'to see what you can check or edit' before interacting with objects. However, it does not explicitly compare with alternatives like get_object or mention when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It reveals that the tool returns both the object and a screenshot, and the verb 'get' implies a non-destructive read operation. However, it does not disclose error handling or auth requirements, which for a getter is acceptable.
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 brief, well-structured with Args/Returns sections, and front-loaded with the core purpose. Every sentence contributes, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior — retrieving an object and its properties — and mentions the return value (object + screenshot). It lacks explicit disambiguation from get_objects and does not explain the screenshot format, but for a simple getter with two string parameters, this is sufficient.
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 Args section adds minimal context beyond the schema: doc_name is 'the name of the document to get the object from' and obj_name is 'the name of the object to get.' While this clarifies the roles, it does not specify formats, possible values, or the relationship to other object retrieval tools, so it only partially compensates for 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 it retrieves a single object from a document and explains its purpose: inspecting properties to decide what can be edited. The singular 'get an object' distinguishes it from sibling get_objects (plural) and get_parts_list, making the tool's role 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 an explicit use case: 'use this tool to get the properties of an object to see what you can check or edit.' This gives clear context for when to invoke it, but it does not mention alternatives or exclusions, such as when get_objects might be more appropriate.
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:

[![OPENCLAW-FREECAD-MCP-Skills MCP server](https://glama.ai/mcp/servers/mars720816/OPENCLAW-FREECAD-MCP-Skills/badges/card.svg)](https://glama.ai/mcp/servers/mars720816/OPENCLAW-FREECAD-MCP-Skills)

Score Badge

Copy to your README.md:

[![OPENCLAW-FREECAD-MCP-Skills MCP server](https://glama.ai/mcp/servers/mars720816/OPENCLAW-FREECAD-MCP-Skills/badges/score.svg)](https://glama.ai/mcp/servers/mars720816/OPENCLAW-FREECAD-MCP-Skills)

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/mars720816/OPENCLAW-FREECAD-MCP-Skills'

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