‹Addon› freecad-mcp-bridge

[zewpo]

🔌 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆

https://github.com/CREATeNG/freecad-mcp-bridge

📑 𝗡𝗼𝘁𝗲𝘀

Hi maintainers,

This addon is an autoloading global module that allows AI assistants (like Antigravity, Claude, Cursor, etc.) to script and control FreeCAD sessions with Python code, via the Model Context Protocol (MCP) using a self-contained local named-pipe/socket bridge.

Thank you!

[zewpo]

Update: Index PR opened for initial listing.

Index PR: #73

This adds the freecad-mcp-bridge entry to Data/Index.json with install ref v0.1.14 (tag-pinned release workflow; main remains development).

• Repository: https://github.com/CREATeNG/freecad-mcp-bridge
• Tag / git_ref: v0.1.14
• Zip URL: https://github.com/CREATeNG/freecad-mcp-bridge/archive/refs/tags/v0.1.14.zip

The PR diff is Data/Index.json only (minimal hunk). "curated": false on this first listing — happy for maintainers to set curated as appropriate on review/merge.

v0.1.14 is the first Index-ready ship with verified install-from-tag on Linux/macOS/Windows before release.

Thanks again for review.

[zewpo]

Security / connections (for review)

The in-FreeCAD bridge listens on a local socket only (named pipe / UNIX domain socket) when the user turns it on via the toolbar; it is off by default each session. The addon does not use any network connections or collect telemetry.

While enabled, any local process that can reach the socket could send Python to the open session — same trust model as running macros. Users should only enable the bridge when they trust other software on that machine.

The optional bundled MCP server is a local process (stdio to a local MCP client, local socket to the bridge). The MCP client also runs locally; if it talks to an external AI service, that is configured in the client — not by FreeCAD or this addon.

More detail: README § Privacy & connections and SECURITY.md.

[zewpo]

UI / global toolbar (for review — feedback welcome)

Index Qualities recommend confining UI side effects to an addon’s own workbench. This addon is packaged as <other> (not a workbench): it adds a small MCP Bridge toolbar with a single On/Off toggle so users can enable the local socket from whichever workbench they are modeling in.

Implementation notes:

• The toolbar is injected at startup and re-shown after workbench changes via WorkbenchManipulator — so the toggle stays available without nesting the bridge inside every workbench.
• It does not hide, remove, or modify FreeCAD core toolbars/menus or other addons; it only adds this one toolbar and command.
• The bridge still starts only when the user toggles it on; import does not open the socket.

We chose a global toggle because AI/script access is session-wide (the open FreeCAD document/window), not tied to one workbench. If maintainers prefer a narrower pattern (e.g. scoped to a dedicated workbench or a different injection approach), we are happy to adjust — please share what you would recommend.

[zewpo]

Design context (for reviewers)

MCP Bridge gives AI tools access to the user's open FreeCAD session. A flexible, light, and direct bridge by design. AI tools work with the session itself, using the full FreeCAD Python API — in whatever part of FreeCAD the user is working — rather than through a catalog of predefined AI commands that only covers what has been wrapped and must be kept updated as FreeCAD changes.

In practice we have not seen a need for a maintained catalog of AI-specific tools. We have found that AI agents work well using the FreeCAD Python API.

Robust MCP Bridge and freecad-mcp take a different approach: common tasks are exposed as named AI commands instead. By contrast, this listing is intentionally minimal: a flexible, lightweight bridge to the session, not a maintained tool catalog.

[chennes]

We generally don't add Addons to the Index when they ship with pre-built binaries -- those will need to be removed in order to have this addon considered. The addon also appears to use exec() on untrusted code (in bridge.py) -- you should strongly consider using QLocalServer.setSocketOptions(QLocalServer.UserAccessOption), and possibly also adding a per-session shared secret (though that's covering a bit of a marginal attack vector).