NXOpen MCP: The Short Version
NXOpen MCP means connecting an AI agent to Siemens NX knowledge through the Model Context Protocol: the real NXOpen API docs, your design guidelines, your works standards, your own code libraries. We build these grounding layers at inteliScience for NX teams in DACH — so the agent cites your standard instead of inventing an answer.
The Problem: The Agent Knows NX. It Doesn’t Know Your NX.
Ask a frontier model an NXOpen question and you get code that looks right and often is right — we measured this in detail in our piece on AI code generation for NX Open. Ask it about your NX and it has nothing: it has never seen your minimum wall thickness for die-cast housings, your layer standard, your drawing frame, the wrapper library your team built over ten years, or the reason expression names start with p_ in your shop.
So it does what language models do. It guesses, fluently.
The guesses come in two flavors, and both cost real hours. The first is the hallucinated API call — a method that does not exist on the class the model claims it does, discovered at compile time. The second is worse because nothing fails: an answer that is plausible general engineering practice but contradicts your works standard, discovered at design review — or not at all.
Both have the same root cause. The model is not stupid; it is ungrounded. And since Anthropic introduced the Model Context Protocol in November 2024, there is a standard, vendor-neutral way to fix that.
Two Kinds of MCP Servers for NX — This Article Is About the Quiet Kind
MCP servers for Siemens NX split into two categories that get conflated constantly. Action servers let an agent do things — create features, set expressions, export STEP — and everything about trust, preview and audit that entails; that side is the act tier of our NX AI assistants family. Knowledge servers never touch the model. They answer the agent’s own questions: what does this API return, what does the standard say, how did we solve this last time.
| Knowledge server (read-only) | Action server (writes to NX) | |
|---|---|---|
| Does | retrieves and cites: API docs, guidelines, part history | executes: features, expressions, drawings, exports |
| Risk | near zero — cannot touch the model | needs preview, confirm, undo marks, audit log |
| Governance | one security review | permissions, logging, works-council alignment |
| Start here? | yes — first win in weeks | after the knowledge layer stands |
The knowledge kind gets a fraction of the attention and, for most NXOpen teams, delivers value sooner. A read-only server cannot corrupt an assembly, needs no confirmation gate, and passes an IT security review in one meeting instead of five. Our clear recommendation: if you are starting with MCP in an NX environment, start here.
Grounding Level 1: The Real NXOpen API, Not a Remembered One
The first grounding layer is public knowledge served precisely. The open-source nxopen-mcp project indexes the NXOpen .NET documentation of a locally installed, licensed NX and serves exact classes, members and signatures to a coding agent — hybrid retrieval, combining BGE-M3 semantic embeddings with exact-name lookup. The agent stops inventing methods because it can look them up, offline, against the very NX version you run.
That last part matters more than it sounds. NX ships twice a year — NX 2606 arrived in June 2026, and Siemens now brackets it under the Designcenter umbrella — and a model’s memory of the API is always a blend of versions. An MCP lookup against your install is version-true by construction.
For comparison, the action-side community server NX_MCP (84 GitHub stars on 14 September 2026, validated against NX 2506) exposes 16 default tools plus 34 experimental ones for driving NX. Useful for experiments — but notice how much smaller the risk surface of the retrieval server is: it has nothing to undo.
Grounding Level 2: Your Design Guidelines and Works Standards
This is the layer your organisation actually owns and nobody else can replicate. Design guidelines, works standards, checklists, deviation approvals — most NX shops have them as PDFs and wiki pages that new hires read once and everyone else half-remembers.
Served through a knowledge MCP server, they change character: any MCP-capable agent — Claude in the IDE, an assistant like Vision4NX inside NX — can query them mid-task and must cite what it found.
The rule is simple: no source, no answer. When a designer asks “minimum wall for AlSi9Cu3?”, the agent’s reply carries the document, section and revision it came from, and a wrong or outdated answer is now a traceable document problem, not an AI mystery. We hold this rule even when it makes the assistant say “I found nothing” more often. An engineering answer without a citation is a rumor.
Ready to go deeper? What it takes to let agents act on that knowledge — preview, confirm, undo, audit — is on our Siemens NX MCP server page.
Using Claude Code as the agent? How we connect Claude Code to a live NX session is on our service page.
Grounding Level 3: Your Own Code, Templates and Part History
The deepest layer extends the Level-1 idea from Siemens’ API to yours. The wrapper functions, journals and template parts your team built are the real vocabulary of your NX environment — and they can be indexed and served exactly like the official docs, so the agent proposes the standard boss function from your library instead of reinventing the geometry from primitives.
Part history closes the loop. “Have we solved a bracket like this before?” is a retrieval question over released parts, drawings and change orders — read-only against Teamcenter, answered with item IDs the designer can open. In practice we scope this layer carefully with each client: access control on the index matters as much as the index itself, because a knowledge server happily serves whatever it was fed. An export-controlled assembly must be as invisible to the agent as it is to an unauthorized colleague.
What to Look For in a Knowledge MCP Setup
Five criteria separate a useful grounding layer from a demo, whether you build it yourself or with a partner like inteliScience:
- Citations are mandatory, not decorative. Every answer names document, revision and section. Tools that return prose without provenance get rejected in review.
- The index knows revisions. A guideline superseded in March must stop being served in April — stale grounding is worse than none, because it arrives with false confidence.
- Access control lives in the server. The agent sees only what the asking user may see: role-scoped indexes, not one big bucket.
- Embedding and retrieval run where the documents live. For most DACH manufacturers that means on-premises — your works standards are competitive knowledge, and nothing about MCP requires them to leave the building. A hosted model like
claude-sonnet-5-5can still be the reasoning layer; the documents themselves stay home. - There is an evaluation set. Twenty real questions from your designers, with known correct sources, re-run after every index update. Retrieval quality is measured, not vibed.
Number 4 is where we see most internal projects stall — the retrieval demo works in a notebook, and then GDPR, SSO and the works council enter the room. That gap between “runs on my machine” and “runs in the enterprise” is precisely the part worth doing properly.
Frequently Asked Questions
What is NXOpen MCP?
NXOpen MCP is the use of the Model Context Protocol to connect AI agents to Siemens NX knowledge: the NXOpen API documentation of a licensed NX install, company design guidelines, and internal code libraries. The agent queries these sources through typed tools and cites what it retrieves, instead of answering from its training memory.
What is the difference between a knowledge MCP server and an action MCP server?
A knowledge server is read-only: it retrieves and cites — API signatures, guideline passages, part history. An action server executes operations in NX through NXOpen and therefore needs preview, confirmation, undo marks and audit logging. Most teams should deploy the knowledge side first; it carries almost no operational risk.
Can an MCP server ground an AI agent in our company design guidelines?
Yes — that is arguably its best use in an NX environment. Guidelines and works standards are indexed (typically with local embeddings), served as retrieval tools, and every answer returns the document ID, revision and section it came from. Wrong answers become traceable document issues rather than silent model failures.
How much effort is it to connect our design guidelines to an AI agent?
Less than most teams expect for a first slice: a focused set of documents, a local embedding index, one retrieval tool with mandatory citations, and an evaluation set of real designer questions — weeks, not quarters. The effort grows with governance, not with technology: revision handling, access control and on-premises deployment are where the real work sits.
Is NXOpen MCP better than fine-tuning a model on our engineering data?
For this problem, yes. Fine-tuning bakes knowledge into weights — expensive to update, impossible to cite, and stale the day a guideline changes. Retrieval through MCP keeps knowledge in versioned documents the agent quotes verbatim, updates the moment the index does, and works with any MCP-capable model, including fully local ones.
Next Step
If your designers are already pasting guideline passages into chat windows by hand, the grounding layer is overdue.
Talk to our engineers about grounding an agent in your NX knowledge