NX MCP: The Short Version
NX MCP is the practice of exposing Siemens NX operations and NX knowledge to an AI agent through the Model Context Protocol, so that a model such as Claude can inspect a live part, apply your standards and, after confirmation, build geometry or author PMI. This whitepaper explains what engineering teams are asking for in 2026, where the open-source and vendor landscape stands, and the NX MCP architecture inteliScience uses for the layer between the agent and NX: a bridge that executes typed, gated commands inside NX, a knowledge layer that hands the agent your guidelines before it acts, and a PMI authoring workflow that never invents a tolerance.
| Question | Answer in one line |
|---|---|
| What do teams want? | An assistant that sees the open part and does routine work in it, not a manual that knows NX. |
| What exists in 2026? | Community servers that drive NX without a safety net, retrieval servers that stop hallucinated NXOpen calls, Siemens’ documentation-grounded Copilot, official Fusion MCP servers from Autodesk. No official Siemens MCP server for NX modelling. |
| What is missing? | The gate (preview, confirm, undo, audit), role-scoped permissions, template awareness, and knowledge of your standards in the loop. |
| What we built | The Vision4NX Connector: a bridge between an MCP-capable agent and a running NX session, with read tools free, build tools gated, and a knowledge layer of over two million curated NX records. |
| First use cases | Part inspection and onboarding questions on day one; PMI authoring, template features and variant builds after the read tier is trusted. |
1. Why This Whitepaper, Why Now
Three developments landed within twelve months and changed the question engineering managers ask us. It used to be “can an AI write NXOpen for us?”. It is now “can an AI work inside NX for us, and how do we keep control?”.
The protocol matured. Anthropic published the Model Context Protocol in November 2024. In December 2025 it moved under the Linux Foundation’s Agentic AI Foundation, and the specification released on 28 July 2026 made the core stateless, added a native way for a server to pause a tool call and ask the user a question, and promoted Enterprise-Managed Authorization to stable. MCP is no longer a vendor experiment; it is the plug every major assistant supports.
The CAD vendors moved, unevenly. On 28 April 2026 Autodesk and Anthropic announced two public Fusion MCP servers, one for modelling commands in a running session and one for design data, usable directly from Claude. Siemens renamed NX to Designcenter with the 23 June 2026 release and shipped Designcenter Copilot, an assistant grounded in documentation and the current task, and reports its AI features are used more than 500,000 times a month. But no official Siemens MCP server for NX modelling operations exists that we are aware of. Siemens’ own developer portal describes MCP as the “USB-C port for AI applications” and shows how to make an agent aware of product documentation; it does not offer a server that acts in NX.
The engineers stopped waiting. Designers already keep Claude, Copilot or an in-house assistant open next to NX. They paste feature names, expression values and error messages into a chat window by hand, and they paste the answer back into NX by hand. That is the gap an NX MCP layer closes, and it is why a niche query like “Siemens NX MCP” started appearing in our Search Console this summer with no service provider ranking for it. Industrial software analysts see the same pattern: a Verdantix market insight from May 2026 profiles industrial software vendors, Siemens among them, building MCP capabilities, and names data contextualization, governance controls and strict safety considerations as the obstacles that separate industrial deployments from ordinary IT ones.
This document is our answer to those three developments. It is written for CAD managers, NX administrators and engineering IT: people who will have to sign off an agent that touches part files.
2. What Engineering Teams Actually Ask For
In discovery sessions with NX teams in machinery, automotive supply, aerospace and energy, the requests cluster into four groups, and their order matters because it is also the order in which trust is built.
Group 1, see the part. “Which features reference the wall-thickness expression?” “What is the mass of body 3 in the current revision?” “Why does this drawing view not update?” Every one of these questions has an exact answer in the live session and none of them can be answered by a chatbot that only knows the documentation. This is the read tier, and it is where every successful pilot starts.
Group 2, know our rules. “Which datum strategy does our house norm prescribe for this part class?” “Is this expression name allowed by our naming convention?” “Show me the NXOpen call for this, from our own library, not a generic example.” Teams do not want a smarter general model. They want a model that answers from their standards, their templates and their code.
Group 3, do the routine work. Create the hole pattern from the spec. Instantiate the boss-and-rib construct our standard prescribes. Author the datum scheme and feature control frames for these bearing seats. Derive the drawing set for all members of this part family. These are build operations, and they are where the safety conversation begins.
Group 4, prove it. Who approved this change? Can we undo it precisely? Where is the log the auditor will ask for? Can we scope which roles may call which tools? This group is rarely raised by the designer and always raised by the CAD manager and IT security. A pilot that cannot answer it does not become a rollout.
A useful observation from those sessions: teams that tried a general chatbot first hit the same wall within a week. The assistant explains the Extrude dialog beautifully and has no idea what is on screen: how many features the part has, which bodies are suppressed, which expression drives the wall thickness. That is not a language-model problem. It is a connectivity problem, and MCP is the standard way to solve it.
3. State of the Art in September 2026
Search for “NX MCP” and you will find four kinds of things. They are conflated constantly, so it is worth being precise.
| Category | Examples | What it does | What it lacks for production |
|---|---|---|---|
| Community servers that drive NX | NX_MCP (MIT, 84 stars, 15 forks, version 0.2.0.dev0), a text-to-CAD demo on NX 2206 | Wrap the NXOpen Python API as MCP tools: 16 default tools plus 34 legacy tools behind a flag, workspace-confined file paths, undo on failed mutations, journal execution off by default. Validated on NX 2506 in batch mode on 21 August 2026; a draft pull request from 6 September 2026 targets NX 2606 session hosting with checkpoint rollback and roughly 189 capability-labelled tools. | Every tool executes on whatever part is active, with whatever parameters the model chose; no preview, no role permissions, no template awareness, Windows batch mode only, interactive GUI scheduling unvalidated. |
| Servers that make agents know NX | nxopen-mcp and similar retrieval servers | Index the NXOpen .NET API documentation of a licensed install and serve exact classes and signatures to a coding agent, so it stops inventing methods. | Do not act in NX; know Siemens’ API but not your libraries, templates or norms. |
| Vendor copilots | Designcenter Copilot (Siemens, June 2026), NX CAM Copilot (beta since late 2025), Autodesk Fusion MCP servers (April 2026) | Siemens: documentation-grounded answers with task context, PMI annotation predictions, command prediction. Autodesk: official local and remote MCP servers for Fusion, so an agent can model and query design data. | Siemens: answers, not actions, and no MCP surface for NX modelling. Autodesk: not NX. |
| Generic assistants | Claude, Copilot-style tools, in-house chat | Reasoning, code generation, document understanding. | Cannot see the part; NXOpen boilerplate is exactly where they hallucinate, as our code-generation tests showed. |
Two conclusions follow. First, the plumbing is proven and public. Second, everything a CAD manager will ask about lives outside the plumbing: the gate, the permissions, the knowledge and the audit trail. That is the box most servers leave out, and it is the box this whitepaper is about.
4. The NX MCP Architecture: A Bridge Between Claude and NX
The Vision4NX Connector started as a knowledge connector: a universal plug that gives any AI assistant curated NX, NXOpen, Teamcenter and data-quality expertise, over two million curated records for a single NX version, GDPR-compliant and without data retention. In 2026 it grew a second half. It now also carries typed commands from an MCP-capable agent into a running NX session and carries structured results back. Claude is the reasoning layer we use most; the protocol makes the bridge model-agnostic.
We deliberately do not publish the internals of the bridge. What follows is the contract, which is the part worth understanding when you evaluate any NX MCP setup.
4.1 Four boxes, and the one that matters
| Box | Role | What lives there |
|---|---|---|
| Host and agent | Where the engineer types | A chat panel next to NX, an IDE, or the in-NX assistant. The model plans which tools to call. It never touches NX directly and never writes NXOpen at runtime. |
| MCP server | The tool catalogue | Typed tools with names, parameters in engineering units and docstrings. Curated, versioned, tested against your NX version. |
| Gate | Preview, confirm, undo, log | Every mutating call is dry-run, shown to the engineer, applied only on approval, wrapped in an undo mark, and written to an audit log with user, timestamp, tool, parameters and result. |
| Connector inside NX | Where it actually happens | Your existing NXOpen libraries, templates and checkers execute the operation in the live session, or headless in batch. |
A weekend server has boxes one, two and four. The third box is the product.
4.2 Read tools before build tools
The single most important design decision is splitting the catalogue into tiers with different trust levels.
| Tier | Example tools | Touches the model? | Gate |
|---|---|---|---|
| Read | list features, expressions and PMI, measure bodies, find interferences, list drawing views | never | none, free to call |
| Knowledge | look up norms, templates, the NXOpen reference and company guidelines | never | none, free to call |
| Build | sketches, extrudes, hole patterns, expression updates, template features, PMI sets | yes | preview, confirm, undo mark, log |
| Export | STEP export, drawing PDF export, drawing set derivation | writes files | workspace-confined paths, log |
Our recommendation is unchanged after every project: ship the read and knowledge tiers first, on their own, and let designers live with them for two or three weeks before a single build tool goes live. Read tools are where the “the assistant finally sees my part” moment happens, and they carry no risk of corrupting a model.
4.3 The contract of a build tool
Three rules from practice, all of them cheap to state and expensive to skip.
Every build tool takes parameters in engineering units, never in screen coordinates. A tool that takes a screen pick is a tool that cannot be reviewed.
Every build tool performs exactly one operation as one undo step. Rollback must be precise, not “undo the last thing”.
No free-form journal execution. The community server ships this behind a flag and disabled by default, and so do we. An agent that can run arbitrary journals is an agent that can do anything NXOpen can do, which is precisely the property no CAD manager will sign.
4.4 Confirmation lives in the protocol now
Until mid-2026 the confirmation step had to be built into the host application. The 28 July 2026 MCP specification changed that. A server may now answer a tool call with an input_required result, hand the client a question, and complete the call once the answer comes back, without keeping a stream open. For an NX build tool this is the native way to say “this will add 24 holes to body 2, proceed?”. Enterprise-Managed Authorization, promoted to stable in the same release, means access to an NX MCP server can be governed through the identity provider you already run, and the new extensions framework moved long-running tasks out of the core, which is where a full-assembly interference check belongs.
An NX MCP server designed in 2026 should expose its gate through the protocol rather than through a custom pop-up. That is what we do, and it is what makes the same server usable from Claude, from a coding assistant and from our own in-NX panel without three different confirmation dialogs.
5. Knowledge in the Loop: Giving the Agent Your Guidelines
Action tools decide what an agent can do. Knowledge determines whether it does the right thing. Most published MCP servers for CAD stop at actions; the second half of the Vision4NX Connector exists because the first half is not enough.
5.1 Why a general model fails on your standards
A frontier model knows GD&T, knows NXOpen, knows Teamcenter concepts. It does not know that your datum strategy for bearing housings starts from the mounting face, that expression names must follow p_<feature>_<quantity>, that the boss construct in your works standard is a template feature and not a cylinder plus a boolean, or that revision C of a drawing may not change the sheet size. Every one of these is a place where a technically correct answer is wrong for you.
5.2 Four kinds of knowledge, one protocol
MCP has three primitives: tools, resources and prompts. We use all three.
| Knowledge | How the agent gets it | Example |
|---|---|---|
| Curated NX expertise | Retrieval tools over the Connector’s knowledge base: NX, NXOpen, Teamcenter, MBD, ISO GPS, data quality | “How do I make a PMI feature control frame semantic, not decorative?” answered from validated records, not from memory. |
| Your house norms and templates | Resources ingested from your standards documents and MBD templates, exposed as knowledge tools | “Datum scheme for this bracket, house standard” returns your preferred strategy for the part class, with the source document cited. |
| Your NXOpen libraries | A reference tool over your own code and its docstrings | The agent proposes the call from your library, in your naming, rather than a generic snippet. |
| The live model | Read tools | Everything the agent “knows” about the part on screen is retrieved, not remembered. |
The ordering matters. Before an agent proposes a build operation, it has already read the part, looked up the norm and found the template. The build call then carries parameters that trace to a source, which is what makes the preview reviewable: the engineer sees not only what will change but why those values were chosen.
5.3 Prompts as guardrails
MCP prompts let the server hand the agent a task template with the rules baked in. Our PMI authoring prompt, for instance, states that every tolerance value must trace to a chat request, a specification line, a legacy drawing or the house norm’s default for the feature class, and that where the source is silent the agent asks. A guessed tolerance on a released model is the one failure mode the architecture refuses, and the refusal is written into the protocol layer rather than hoped for in the model.
5.4 Sovereignty of knowledge
Your standards are intellectual property. The knowledge layer runs where you decide: on your infrastructure, in an EU cloud, or fully air-gapped with local models for defence and IP-sensitive environments. The reasoning model can be hosted while the MCP server, the knowledge base, the audit log and all part data stay on the client’s side. That separation got a recent project through IT security review in one round instead of three.
6. Worked Example: Authoring PMI Through the Agent
Model-based definition moved the annotations from the drawing into the model, and someone still types every one of them. PMI authoring is the clearest case where reading, knowledge and gated building come together, and it is where several of our clients want the agent first.
6.1 The deterministic backbone
Long before MCP we built a tool that automates the placement and numbering of PMI elements from the X, Y and Z coordinates of a coordinate system. When the design changes, an algorithm re-orders and re-numbers the annotations on its own and keeps the documentation consistent. The problem it solved is familiar to every MBD team: manual PMI maintenance breaks with every design change. The lesson it taught is the one this whitepaper keeps repeating: the rules do the placement, deterministically, and the human keeps the design.
That tool now sits behind an MCP build tool. The agent does not place annotations by guessing coordinates. It calls the rule-based placement with the parameters it has gathered, and the placement does what it always did.
6.2 From a specification line to reviewed, semantic PMI
Input, a line from the customer specification, pasted into the chat or extracted from the document: “Bearing seats ø40: locate to datum A-B, runout ≤ 0.02. Surfaces Ra 1.6.”
What the agent does, tool by tool:
- Read tools on the open part: finds the two ø40 seat faces and the existing datum situation.
- A guideline lookup for the part class: your house norm says bearing seats define datums A and B and prescribes surface template TN-12.
- The PMI authoring tool with the gathered parameters: datum features A and B on both seats, a circular runout frame 0.02 to A-B attached to the ø40 faces, surface finish Ra 1.6 on the seat faces, the note set and model views organized per your MBD template.
- The gate shows the annotation set as a preview on the model, with every value traced to its source. The engineer accepts, edits or discards. Nothing enters the model unreviewed, and the engineer who releases the set signs it, exactly as with hand-authored PMI.
Everything is authored as semantic PMI, attached to faces and carrying its meaning, so CMM programming, CAM and the compliance check downstream can read it. Decorative text annotations are the failure mode we design against; a rules-based compliance gate at release, the sibling of the authoring assistant, verifies the result against your rules and customer requirements.
6.3 What the agent may not do
It never invents a tolerance. It never places by screen coordinate. It never releases. Migration quality from legacy drawings depends on drawing quality; clean drawings migrate nearly automatically, scanned faxes route more annotations through the review queue, and a pilot measures that split on your real drawings before anyone commits to the archive.
7. Two Deployments, One Pattern
The hybrid co-engineer. For a confidential engineering client we delivered an assistant that interprets a request in natural language, decides which NX tools to use, fills their parameters from the model state and the conversation, executes inside NX, verifies that the intended result was actually achieved, and either continues, corrects or asks. The loop is understand, plan, execute, verify, assist. In engineering, “command sent” is not the same as “task completed”, which is why the verification step is not optional.
The chat assistant with MCP access to geometry. This year we shipped a chat assistant for an industrial manufacturer in Asia whose engineers wanted to talk to the part they had open. The read side went live first; the build side followed four weeks later and is deliberately narrow: sketch-based features, holes and patterns, and the client’s own template features with parameters filled from the conversation. Every build call previews, waits for confirmation, sets an undo mark and writes an audit entry. The reasoning layer is a hosted frontier model; the server, the log and the part data never leave the client.
Both projects converge on the NX MCP architecture in section 4, and both confirm the sequencing in section 2: see the part, know the rules, do the routine work, prove it.
8. Security and Governance Checklist for an NX MCP Setup
Whether you build in-house or with a partner, these are the criteria that separate a tool a CAD manager can sign from a demo.
- Read tier ships alone first. Inspection and knowledge tools with zero write access, in production, before any build tool exists.
- Engineering units in every signature. Millimetres, degrees, expression names. No screen coordinates, no “the selected face”.
- One undo step per write. Rollback must be precise.
- No free-form journal execution. Not behind a flag your users can find.
- Template awareness. The agent instantiates your standard features rather than assembling geometry from primitives.
- Knowledge with provenance. Every value in a preview traces to a norm, a template, a specification or the live model.
- Role-scoped permissions through your identity provider. Enterprise-Managed Authorization is stable in the protocol since July 2026; use it.
- Audit log the CAD manager owns. User, timestamp, tool, parameters, result, undo mark. Exportable.
- Model where you want it, data where it must stay. Hosted reasoning is fine; the bridge, the parts, the knowledge base and the log stay on your infrastructure or in an EU cloud, air-gapped where required.
- Measured pilot. Accuracy and review effort per tool and per annotation type, on your parts, before rollout.
Number 5 is the one most demos skip and the one designers notice first. Number 6 is the one that makes number 5 possible.
9. Measuring a Pilot
An NX MCP pilot should be judged the way any engineering tool is judged: by numbers on your own parts. The metrics we report at the end of a proof of concept:
| Metric | What it tells you |
|---|---|
| Tool-call precision | Share of build previews accepted without edit, per tool |
| Review effort | Minutes per accepted annotation set or feature, compared with hand authoring |
| Rollback rate | Share of confirmed operations later undone, per tool |
| Coverage | Share of routine tasks in the pilot scope the agent could complete without escalation |
| Grounding rate | Share of proposed values with a traceable source (target: 100 percent) |
| Time to first value | Days until the read tier answers questions designers previously answered by hand |
A pilot that reports usage instead of these numbers has not been evaluated. Our buyer’s framework for evaluating engineering AI assistants covers the wider method.
10. Adoption Path
The sequence we recommend, and the one our fixed-price proofs of concept follow:
- Weeks 1 to 2: read and knowledge tiers. The Connector answers from the live part and from your standards. No writes.
- Weeks 3 to 5: one narrow build tier. The operation your designers repeat most, gated, with undo and audit. Typical first candidates: template features, hole patterns, expression updates.
- Weeks 5 to 7: a knowledge-heavy authoring workflow. PMI authoring for one part class with your MBD template and house norms encoded, twenty real parts annotated and reviewed by your engineers, accuracy and review effort reported per annotation type.
- Rollout: role scopes, SSO, on-premise or EU-cloud operation, wiring into the compliance gate and, where relevant, Teamcenter actions through the same protocol.
Our NX MCP proof of concept starts at €12,000 fixed price; the PMI authoring proof of concept starts at €14,500, five to seven weeks, price creditable against rollout. Templates and rules are yours either way.
If your engineers are already describing parts to a chatbot by hand, the read tier is overdue and the build tier is a scoping conversation. Talk to our engineers about an NX MCP pilot, or read what a production-grade Siemens NX MCP server needs, how the Vision4NX Connector delivers the knowledge half, and how the MBD and PMI Authoring Assistant applies it.
How we split this work across several agents in practice is described in how we split research, build, check and code.
Frequently Asked Questions
What is NX MCP?
NX MCP means exposing Siemens NX operations and NX knowledge to an AI agent through the Model Context Protocol, implemented on NXOpen. The agent discovers typed tools, for example to list features or apply a template feature, decides when to call them, and the server executes them in a real NX session. The protocol is model-agnostic, so the same server works with Claude, Copilot-style assistants or an in-house engineering assistant.
Is there an official Siemens MCP server for NX?
Not that we are aware of as of September 2026. Siemens ships Designcenter Copilot, a documentation-grounded assistant, and describes MCP on its developer portal, but no official MCP server for NX modelling operations exists. Community servers such as NX_MCP prove the plumbing; production gating, permissions and template awareness have to be built or bought.
How does the Vision4NX Connector bridge Claude and NX?
An MCP-capable agent such as Claude calls typed tools; the Connector executes them inside the running session and returns structured results. Read tools are free to call, build tools pass through a preview-and-confirm gate with undo marks and an audit log, and a knowledge layer of over two million curated records plus your own standards is available to the agent before it acts.
Can an AI agent create PMI in Siemens NX safely?
Yes, when every value traces to a source and the engineer releases the set. The agent reads the part, looks up your house norm and MBD template, and calls a rule-based authoring tool that produces semantic PMI attached to faces. The annotation set appears as a preview; nothing enters the model unreviewed. The agent never invents a tolerance and never places by screen coordinate.
How do we give the agent our design guidelines?
Through the same protocol. Your standards documents, MBD templates and NXOpen libraries are ingested and exposed as knowledge tools and resources with provenance, and task prompts carry the rules, for instance that a missing tolerance must be asked for, not guessed. The agent consults these before it proposes a build operation, so every preview shows why a value was chosen.
What does an NX MCP pilot cost and how long does it take?
An NX MCP proof of concept starts at €12,000 fixed price. A PMI authoring proof of concept starts at €14,500 and runs five to seven weeks, with twenty real parts annotated and reviewed and an accuracy report per annotation type. Both are creditable against a rollout.
Sources
- Model Context Protocol specification, revision 2026-07-28, and the Agentic AI Foundation announcement (December 2025), modelcontextprotocol.io
- Autodesk, “Autodesk announces Fusion MCP servers”, 28 April 2026, engineering.com and autodesk.com
- Siemens, “Designcenter is for everyone, June 2026 release”, blogs.sw.siemens.com, 23 June 2026
- Siemens Developer Portal, “Setup Agentic AI & MCP”, developer.siemens.com, retrieved 14 September 2026
- DreamEnding/NX_MCP, GitHub, retrieved 14 September 2026 (84 stars, 15 forks, MIT, validated on NX 2506 on 21 August 2026)
- Verdantix, “Market Insight: 10 Industrial Software Vendors Innovating With Model Context Protocol (MCP) In 2026”, 7 May 2026
- inteliScience, “Hybrid Agentic AI for Siemens NX” (case study), “NX CAD MCP: How AI Agents Read and Build Geometry”, “Siemens NX MCP Server” (service page), “MBD & PMI Authoring Assistant” (service page), 2025 to 2026