inventor-mcp-server

Overview Schema Source Related Servers Discussions Admin

execute_python

Run Python code against a live Autodesk Inventor session to build parametric 3D parts, sheet metal, and assemblies via the COM API, with persistent variables and undo-on-error rollback.

Instructions

Execute Python code against the live Inventor connection.

Pre-bound objects (re-resolved fresh on every call): inv — InventorConnection wrapper (all high-level methods, mm units) app — Inventor.Application COM object doc — active document comp — its ComponentDefinition body — comp.SurfaceBodies.Item(1) (or None) tg — TransientGeometry math — math module progress(msg) — status line call_status shows while a long job runs cancelled() — True once cancel_call asked to stop: poll it in long loops Variables you assign persist between calls until the server restarts or reload_api runs — status shows the namespace's age and names. Each connected Inventor has its own namespace. Helpers you need every time: put them in a file and load_library it (or in ~/.inventor-mcp/startup.py) — they come back by themselves in a new namespace. Internal COM units are CENTIMETERS — divide mm by 10. Objects are late-bound: a Document from Documents.Open exposes ComponentDefinition directly. Don't use CastTo / gencache.EnsureDispatch (they create a gen_py cache). Runs with SilentOperation on, so Inventor answers its own prompts instead of opening a dialog. A call longer than the wait limit keeps running; follow it with call_status(wait_seconds=30), which shows the prints so far; cancel_call stops it. Returns captured stdout + stderr (print your results!), or the traceback from your own code down on error (COM errors named: E_INVALIDARG, RPC_E_DISCONNECTED …).

Args: code: Python source. undo_on_error: Run inside one undo transaction on the active document and roll it back if the code raises — no half-built sketches or work planes left behind. timeout: Seconds; then cancelled() turns True, and the run is interrupted CANCEL_GRACE s later if it hasn't stopped — as cancel_call does (0 = none).

Input Schema

Name	Required	Description
`code`	Yes
`timeout`	No
`instance`	No	Which connected Inventor to use (list_instances). Leave empty when only one is connected.
`undo_on_error`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Oct 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full load and does so unusually well: it enumerates pre-bound objects, discloses that COM units are centimeters while the wrapper is mm, warns against CastTo/gencache.EnsureDispatch, notes SilentOperation suppresses dialogs, explains timeout/cancel semantics and the CANCEL_GRACE interrupt, and names the return (stdout+stderr or a named-COM-error traceback). This is the kind of behavior an agent could not infer from schema or annotations.

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?

Front-loads purpose in one line, then moves to pre-bound names, persistence, units, late binding, and failure modes. It is long and reads as a dense run-on block rather than cleanly sectioned prose, but nearly every line carries operational signal rather than filler.

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?

Complete for a high-complexity arbitrary-code tool: persistence model, unit trap, cancellation path, error surface, and multi-instance namespace isolation are all covered, and an output schema exists so return formatting need not be re-explained.

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 only 25% (only `instance` documented), so the description must compensate and does: `code` is Python source with documented pre-bound names, `undo_on_error` explains it wraps the run in one undo transaction and rolls back on raise, and `timeout` explains cancelled() flips True then an interrupt occurs (0 = none). Only `instance` is left to the schema, where it is already described.

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?

States a specific verb and resource — execute Python against the live Inventor connection — and implicitly frames itself as the raw escape hatch that the many single-purpose siblings (draw_line, extrude, fillet) do not cover. An agent can immediately tell this is the general scripting entry point rather than a modeled operation.

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 concrete operating guidance: follow long calls with call_status(wait_seconds=30), use cancel_call to stop, put reusable helpers in a file/startup.py, and note that variables persist until restart or reload_api. It lacks an explicit 'prefer the dedicated tool over scripting when one exists' exclusion against the ~70 modeling siblings, which is the main missing routing cue.

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

Deploy Server