Skip to main content
Glama
mario-2015

FreeCAD MCP Connector

by mario-2015

execute_code_async

Run heavy Python computations in FreeCAD in the background, preventing UI freezes while avoiding GUI and document modifications.

Instructions

Execute Python code in FreeCAD without waiting for completion.

Use this ONLY for long-running background computations that do NOT touch the FreeCAD GUI or mutate the FreeCAD document tree directly.

This tool runs the submitted code in a background thread and returns immediately. Because it does not run on FreeCAD's main GUI thread, the code must NOT call FreeCADGui APIs, manipulate the active view or selection, create or edit document objects, change object properties, call doc.recompute(), or save documents.

For code that touches FreeCAD documents, document objects, FreeCADGui, the active view, selection, recompute, or save operations, use execute_code instead. execute_code runs on the FreeCAD GUI thread and is the safe default for normal FreeCAD automation.

Use execute_code_async only for background-safe work such as long-running pure OCCT geometry calculations (e.g. fuse/cut/loft on already-fetched shapes) or other CPU-bound computations that do not interact with the document or GUI.

Typical usage pattern:

  1. Fetch shapes into local variables first (via execute_code on the GUI thread).

  2. Store intermediate results in a module-level Python variable (not in the FreeCAD document) so execute_code can read them later.

  3. Run the heavy computation via execute_code_async.

  4. After the expected computation time has elapsed, apply results to the document via execute_code (which runs on the GUI thread).

Args: code: Background-safe Python code to execute.

Returns: A message confirming that background execution has started.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the code runs in a background thread, returns immediately, and must NOT call FreeCADGui APIs, manipulate the view/selection, create/edit objects, change properties, recompute, or save documents. It also outlines a typical usage pattern to safely manage state, providing deep behavioral insight beyond minimal expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: definition, usage restriction, alternative, typical usage pattern, and args/returns. Every sentence adds necessary context—there is no fluff or redundancy. The length is justified by the number of constraints that must be communicated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is remarkably complete. It covers purpose, constraints, usage alternatives, a safe state-management pattern, and the return value ('A message confirming that background execution has started'). An agent has enough information to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, but the description explicitly adds meaning for the `code` parameter: 'Background-safe Python code to execute.' This clarifies that the code must be non-GUI and non-document-mutating, a critical qualifier not present in the schema. Given the single simple parameter, this amount of semantic addition is strong, though it stops short of providing code examples or further parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states the specific action: 'Execute Python code in FreeCAD without waiting for completion.' It clearly identifies the resource (Python code in FreeCAD) and the async behavior. It also distinguishes itself from `execute_code` by noting the thread difference, fulfilling the sibling differentiation requirement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Use this ONLY for long-running background computations that do NOT touch the FreeCAD GUI or mutate the FreeCAD document tree directly.' It also provides a clear alternative: 'For code that touches FreeCAD documents... use execute_code instead.' This defines the exact boundary and names the sibling alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mario-2015/freecad-mcp-connector-for-claude-desktop'

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