Siemens NX MCP Server

Chatbots answer. Agents act. An MCP server is the plug that lets an AI agent act inside Siemens NX — and the difference between a weekend demo and a tool a CAD manager signs off is everything wrapped around it.

A Siemens NX MCP server is a program that exposes NX operations as typed tools an AI agent can call through the Model Context Protocol — implemented on NXOpen, the official NX automation API. Connect one, and a model can create features, set expressions, derive drawings and export STEP files in a real NX session, on a real part. We build that layer for engineering organisations: curated tools on your own NXOpen libraries, with a preview-and-confirm gate, undo marks, audit logging and on-premise deployment — delivered through the Vision4NX Connector.

It is the technology layer under our NX AI Assistants & Chatbots family: every action assistant on that page speaks MCP to reach into NX and Teamcenter. This page explains what an NX MCP server actually is, what exists in 2026, why the naive version breaks in production — and how we build one your engineering department can trust.

Siemens NX MCP: the short version

• MCP (Model Context Protocol) is an open standard, introduced by Anthropic in late 2024, that lets AI applications discover and call external tools — Siemens’ own developer portal describes it as the “USB-C port for AI applications”.
• An NX MCP server wraps NX operations as MCP tools on top of NXOpen. Any MCP-capable agent — Claude, Copilot-style assistants, or a purpose-built engineering assistant — can then drive NX through it.
• What exists today: open-source community servers (one exposes 47 low-level modelling tools), retrieval servers that stop agents from hallucinating NXOpen calls, and Siemens’ documentation-grounded Design Copilot. No official Siemens MCP server for NX modelling operations exists that we are aware of.
• The gap: raw servers give an agent unrestricted low-level control — no preview, no confirmation, no audit trail, no permissions, no awareness of your templates and standards. That is a demo, not a tool.
• What we build: a curated NX MCP tool layer on your own NXOpen libraries, gated by preview-and-confirm, undo-safe, logged, role-scoped, on-premise capable — the architecture behind the NX Action Assistant.

What an MCP server for Siemens NX actually is

Every integration between a language model and a piece of software used to be bespoke: a plugin here, a function-calling schema there, each written for one model and one application. MCP standardises that seam. Three roles: the host is the application the engineer talks to — a chat panel, an IDE, an in-NX assistant. The client inside the host speaks the protocol. The server is where the capabilities live: it announces a list of tools with typed parameters, the model decides when to call one, the server executes it and returns a structured result.

If you have written NXOpen code, the mental model is familiar. An MCP tool is a function with a signature and a docstring, for example an extrude tool with a sketch, a distance and a direction as parameters, except the caller is a model reading the docstring, not a developer reading the API reference. Nothing about the protocol is vendor-specific, which is exactly why it spreads: the same server works with different agents, and the same agent can combine an NX server with a Teamcenter server and a documentation server in one conversation.

The practical consequence for a CAD organisation: the model no longer needs to write NXOpen code to do something in NX. It needs to pick the right tool and fill in the right parameters. That shifts the risk from “will the generated code compile” — the problem we cover in AI code generation for NX Open — to “did it pick the right tool, on the right part, with the right values, and did anybody check before it ran”. A different problem, and in some ways a more dangerous one, because a tool call that succeeds looks exactly like a tool call that was correct.

For teams that work in Claude Code, the client side of this setup, including per-tool approval, is covered by our Claude NX integration.

When one model with every tool is not enough, agentic CAD for Siemens NX splits the work across several specialised agents, all calling the same gated server.

The NX MCP landscape in 2026

Search for “Siemens NX MCP” and you will find three kinds of things. They get conflated constantly, so it is worth being precise about what each one is:

Why a raw NX MCP server breaks in production

None of this criticises the people writing open-source servers. It is the list of questions a CAD manager, an IT security officer and a works council will ask in the first meeting — and the reasons a production NX MCP layer looks nothing like a demo one.

Granularity. Forty-seven low-level tools — draw rectangle, extrude, add blend — are the wrong altitude for an engineering organisation. An agent assembling a housing from primitives ignores your start part, your layer standard, your expression naming and your drawing frame. The tools a design department needs are domain tools: create part from template X, derive drawing per standard Y, run check set Z. Those tools already exist in most NX shops — as NXOpen libraries, journals and wrappers built over a decade. An MCP server should expose them, not re-invent modelling from scratch.

Immediacy and reversibility. A raw tool executes the moment the model calls it. If the model misreads “5 mm” as “5” in a part whose units are inches, the feature is built before anyone sees it. Production tooling needs a dry run — what will change, on which occurrences, with what parameters — and a human confirmation for anything that mutates geometry, expressions, attributes or PLM state. And NX has undo marks; most demo servers never set one. Every mutating tool in our layer is a single undo step: a wrong action is one Undo away, and the log shows exactly which action that was.

Sessions and licences. NX runs one interactive session per user, one licence per seat. An MCP server has to decide whether it runs inside the engineer’s live session (right for interactive assistance) or headless in a batch session (right for bulk operations and checks) — and the two need different NXOpen entry points, different error handling and different licensing.

Managed mode. Almost every serious NX installation runs under Teamcenter. A part is not a file; it is an item revision with a status, a checkout state and a release workflow. A server that happily “saves” a part has never met a released revision. The tool layer must be Teamcenter-aware — refuse released data, respect checkout, and hand PLM actions to a permission-scoped set of tools like our Teamcenter Action Assistant.

Permissions, audit — and where the model runs. Who may call which tool? A trainee’s assistant should not export STEP from an export-controlled assembly. Every call needs a user, a timestamp, the parameters, the confirmation and the result, written where an auditor can read them. And the tool calls carry geometry names, expression values, part numbers — if the agent behind them is a public cloud model, that context leaves the building with every request. For most DACH manufacturers, the model has to be able to run on-premises. The protocol allows it; most demos ignore it.

Version drift. NXOpen is stable, but not frozen — NX releases twice a year, and a tool built on a deprecated call fails on the next upgrade. The same discipline as for your existing automation applies: supported APIs, a version matrix, tests on the pre-release. That discipline is our day job in NXOpen custom tool development.

Where an NX MCP layer pays off first

Not everywhere. The economics are the same as for any automation: a repeated operation with a clear rule beats a creative one-off. These are the four shapes we see paying back fastest — each maps to an assistant we already build on this layer.

Repetitive modelling operations on demand

“Add the standard mounting pattern to this bracket, M8, 4×” — executed with the company’s own feature library instead of the model improvising geometry. Preview, confirm, undo. This is the NX Action Assistant, and it is where most customers start.

Drawings and documentation

“Derive the drawing for this part per our frame, three views plus section A–A.” The heavy lifting is your existing drawing automation; MCP gives it a conversational front door and a preview — the Drawing & Documentation Assistant. For deterministic batch derivation without a chat at all: NX workflow automation.

Checks while you model

Read-only tools are the safest MCP tools and often the most valuable: a release check returns a structured list of violations with the rule, the object and the fix, explained in plain language — the Live Model Check Assistant. Read-only is also where most pilots start.

Teamcenter actions in plain language

Where-used, revision deltas, starting a workflow, drafting an ECR — through tools that are permission-scoped and confirm-gated, never through a model with a Teamcenter password. The Teamcenter Action Assistant is the same architecture pointed at PLM.

Underneath all four sits the knowledge side: an agent that acts in NX should also be able to ask — about NXOpen, about your standards, about the last time a part changed. That answering tier is described in our guide to Siemens NX AI chatbots, and it is what Vision4NX brings from day one: Siemens knowledge already in the assistant, your knowledge added in the project.

Build now, or wait for Siemens?

How we build it — and how to start

We do not start from a blank MCP server, and we do not start from forty-seven primitives. We start from what your NX organisation already runs: the NXOpen libraries, the journals people trigger by hand, the checkers, the templates, the naming rules. Those become the first tool catalogue: typically ten to twenty domain-level tools, each with a preview, one undo step and a log entry. The gate that shows a preview and asks for confirmation sits between the agent and the session; in our stack that is the Vision4NX Connector, which also gives the assistant a home inside NX instead of a browser tab.

The model is whichever your security posture allows: a hosted frontier model where acceptable, an EU-hosted one where residency matters, an open-weight model on your own hardware where nothing may leave — fully air-gapped where required. The protocol does not care, which is the point. And the boundary we keep on every page applies here more than anywhere: the agent executes known operations, previews them, and waits. Your engineers decide and sign.

The same protocol question comes up for PLM: our article on the Teamcenter MCP server explains what exists for Teamcenter and how to govern agent access to PLM data.