Claude NX Integration
Claude NX Integration: Claude Code in Your Live NX Session
Claude in a browser tab can explain NX. Claude Code connected to your running NX session can read the part, build the feature, run the NXOpen code it just wrote, and then wait for you to say yes.
A Claude NX integration connects Claude Code, Anthropic’s agentic coding tool, to a running Siemens NX session through the Model Context Protocol (MCP) and NXOpen, the official NX automation API. Claude can then read the open work part, create sketches and features that stay editable in the Part Navigator, and execute, compile and debug NXOpen code in C#, Python or C++. inteliScience, a Siemens NX, NXOpen and Teamcenter specialist delivering nearshore from Romania, sets this up for engineering teams: with a preview-and-confirm gate, an undo mark and an audit entry in front of every change, and with models and data hosted in the EU, in Germany or on your own servers.
This page is the Claude side of the connection. The server side, what an MCP server for NX is and why the raw version breaks in production, is covered on our Siemens NX MCP server page. The product that carries the connection into NX is the Vision4NX Connector. Both belong to our family of NX AI assistants and chatbots.
If Claude should hand research, checking or new code to specialised agents, that is agentic CAD for Siemens NX: several roles, one gated tool layer, one undo step per change.
Claude NX integration: the short version
- What it is: Claude Code on the engineer’s workstation, connected over MCP to a tool layer that runs inside the live NX session through NXOpen. Claude never touches NX directly; it calls typed tools, and the tools do the work.
- What Claude can do: read the open work state, create sketches, build geometry step by step, create associative PMI, and write, run and debug NXOpen code. The results are ordinary NX objects, features in the Part Navigator, not dumb bodies.
- What keeps it safe: gates on both sides of the connection. Claude Code’s own permission rules, hooks and per-tool approval on one side; the Connector’s preview, confirmation, undo mark and audit log on the other; your NX licence and Teamcenter permissions underneath.
- Where it runs: Claude through Anthropic, Amazon Bedrock, Google Cloud or Microsoft Foundry, with EU regions available on Bedrock and Google Cloud. The tool layer, the log and your part data stay on your infrastructure.
- What it is not: text-to-CAD, and not a replacement for your designers. Claude executes known operations quickly; your engineers own the design intent and sign the result.
Why Claude in a chat window is not enough for NX
Claude in a chat window has never seen your part. Ask whether it can open an NX .prt file and the honest answer is no: native CAD formats are not something a chat window reads. The limit is not intelligence, it is access.
You notice it in the first week. The assistant describes the Extrude dialog perfectly, but it does not know that the shaft on your screen has a stepped profile, two suppressed features and an expression that drives every diameter. So the engineer copies feature names into the prompt, the model answers with a list of clicks, and the engineer still does all the clicking.
Connecting Claude to a live NX session removes the file-format question altogether. Claude does not parse .prt files at all. It asks NX, through NXOpen, the same API your own journals and tools already use, and NX already has the part loaded with its feature tree, expressions, PMI and Teamcenter context. Claude works with exactly what a tool call returns.
The plumbing for this is standard. Anthropic open-sourced MCP on 25 November 2024 as a protocol for connecting AI assistants to the systems where data lives, and Claude Code speaks it natively. That is why connecting Claude to NX is a configuration entry, not a custom plugin. What is not standard is the NX side: which tools exist, what they are allowed to change, and who confirms.
What Claude Code can do inside a running NX session
The first three are what we demonstrated in a live NX session to an NX customer’s design team, not on a slide; the other three are part of the same stack. The common thread: Claude works through tools that call NXOpen, and every result lands as an ordinary NX object that your designers can edit afterwards, exactly as if they had built it by hand.
Read the work state
Which part is open, which features, bodies and expressions it has, what the PMI says. Read tools change nothing, and they are where every pilot starts.
Sketches and features
Claude creates sketches and builds geometry from them one step at a time. Each step appears as a feature in the Part Navigator, parametric and editable, never as a dumb body.
Associative PMI
Dimensions and hole callouts created as real PMI objects that keep their references to the geometry, so they can be moved and edited afterwards. More in our piece on AI-generated PMI in NX.
NXOpen in C#, Python, C++
Claude writes NXOpen code; the tool layer executes, compiles and debugs it in the background and hands the error back to Claude instead of into a ticket. Your internal template projects can be the starting point.
Grounded answers
Questions run against a knowledge base of verified Siemens documentation, NXOpen API docs, error codes and your approved internal code examples, so Claude stops guessing method names.
Your other systems
Design guidelines in a wiki such as Confluence, ticket systems and similar sources are connected through their APIs with purpose-built tools, so Claude reads the current page, not a stale copy.
The same capabilities do not have to stay a conversation. Once a step works in Claude Code, it can become a function, a workflow, a batch job or a button inside NX. Claude Code is where an operation is found, tested and refined; the button is where the whole department uses it.
How Claude Code connects to Siemens NX
Four parts, one direction. Claude Code plans, the MCP connection carries a typed tool call, the gate in the Vision4NX Connector previews it and waits, and NXOpen executes it in the live session. At no point does Claude get a raw handle on NX: even the NXOpen code it writes runs through a tool, behind the same gate.
// Claude NX integration: the red box is the one weekend setups leave out
Where the engineer types
Terminal, VS Code or JetBrains on the NX workstation; native on Windows 10 1809 or later. Claude plans which tools to call.
The NX tool catalogue
Typed tools with names, parameters and descriptions, served by one MCP server and shared with the whole team.
Preview → confirm → log
Every changing call is shown first, applied only on confirmation, wrapped in one undo mark and written to the audit log.
Where it actually happens
Your NXOpen libraries and templates run in the engineer’s session, under the engineer’s licence and permissions, visible live.
The connection itself is ordinary Claude Code configuration. What turns it into an engineering tool is the third box: who saw the change, who approved it, and how to take it back.
Claude Code itself needs a paid Claude plan or an account with an API provider; the free claude.ai plan does not include it. For NX that usually means a Team or Enterprise plan, or company access through Amazon Bedrock, Google Cloud or Microsoft Foundry, which also settles the data residency question further down.
The gates that keep Claude from changing the wrong part
Instructions are not a safety mechanism. Anthropic’s own documentation says that CLAUDE.md files are context, not enforced configuration, and that anything which must be blocked regardless of what Claude decides belongs in a hook or a permission rule. So the gate has to be something Claude cannot talk its way past, and in our setups it exists on both sides of the connection.
| Layer | Enforced by | What it stops |
|---|---|---|
| Claude Code permissions | Permission rules evaluated deny first, then ask, then allow; managed settings that no user or project can override; PreToolUse hooks that can block a call | Claude calling a tool outside the role: exports, saves, anything not on the list |
| Per-tool approval | Build tools are flagged so that Claude Code prompts on every call, even in bypassPermissions mode, with no “don’t ask again” |
A geometry change running unattended because someone switched on an auto mode |
| Connector gate | Preview of what changes on which part, explicit confirmation, one named undo mark per action, audit entry, refusal on released or checked-in data | A wrong value reaching the model, or a change nobody can trace weeks later |
| NX and Teamcenter | The engineer’s own NX licence, session and Teamcenter permissions | Claude doing anything the engineer could not do by hand |
Read tools run freely, build tools ask, and exports and saves are denied at workstation level. None of this replaces the Connector’s own gate: the server side does not trust the client side. Even with every Claude Code prompt approved, the Connector shows what will change, applies it only after confirmation, sets one named undo mark and logs user, parameters and result. Ctrl+Z takes one action back cleanly.
Where Claude Code in NX pays off first
Where the engineer already knows what should happen and spends the time getting NX to do it. A DACH machine builder’s CAD team put the order plainly: design support inside NX first, because it gives practical value fastest; Teamcenter later, because a heavily customized data model with its own workflows and policies needs groundwork before any assistant touches it.
NXOpen development without the copy-paste loop
An NXOpen developer asks for a journal, Claude writes it against the verified API reference, the tool layer runs it in the session, and the exception text goes straight back to Claude. For C# and C++ projects, compiling and debugging happen in the background, starting from your internal template projects. The developer reviews a diff instead of shuttling code between a browser and the Journal Editor. A step-by-step example is in our worked prompt-to-journal walkthrough; why general models invent API members without grounding is covered in AI code generation for NX Open.
Modelling steps on existing parts
The requests designers actually make are small and concrete: a keyway on this shaft, a parametric feature group, a complex function on an existing body. Claude reads the selected geometry, proposes the steps with their parameters, and builds them as features after confirmation. For designers who would rather not open a terminal, the same operations run from a chat panel inside NX in our NX Action Assistant.
PMI and drawings
Dimensions and hole callouts as associative PMI, drawing views per company guidelines, holes placed and dimensioned by rule. On automatic 2D dimensioning, drawings, views and first dimensions already work in two current customer projects; by our own estimate the degree of automation there is roughly 40 percent and rising. Tolerances and surface finish symbols are the hard part, and we say so before a project starts.
Rebuilding parts that lost their history
Migrated STEP data without a feature tree is a classic NX headache. Simple parts such as flanges and screws have already been rebuilt with a sensible history; for very complex geometry success is not guaranteed. The design rules and the target history structure have to be specified up front, and an automated comparison of the rebuilt part against the source geometry is the acceptance test that decides, part by part. Data quality in migrations is its own topic, covered in CAD data quality when migrating to NX.
Replacing components in assemblies
Rule-based replacement of many dependent components at once, for example valves swapped for matching new parts after the housing sizes changed. Existing assembly constraints generally survive the swap; they break when the new component lacks the faces or other geometry the constraints referenced, and that is exactly what the preview has to show before anyone confirms.
Claude Code with and without a production tool layer
Search for Claude and NX and you find three different things that get mixed up constantly: Claude in a chat window, Claude Code with an open-source NX MCP server from GitHub, and Claude Code on a curated, gated tool layer. The open-source servers are a good way to see the idea work; our NX CAD MCP overview looks at what they do today. The difference shows in what a CAD manager asks about.
| Question | Claude in a chat window |
Claude Code + open-source NX MCP server |
Claude Code with the inteliScience integration |
|---|---|---|---|
| Sees the part open in NX | No | Yes, if it bridges into the session | Yes, through read tools on NXOpen |
| Builds editable features | No, it describes clicks | Low-level modelling tools | Yes, with your templates and NXOpen libraries |
| Preview and confirm before a change | Not applicable | Not built in, as a rule | Yes, in the Connector and in Claude Code |
| Undo mark and audit entry per action | Not applicable | Not built in, as a rule | Yes, one undo step and one log line per action |
| Respects Teamcenter status and checkout | No | No | Yes, released and checked-in data is refused |
| Runs NXOpen code and returns errors to Claude | No | Depends on the server | Yes, C#, Python and C++, compiled and debugged in the background |
| Claude Code permissions preconfigured | Not applicable | Your job | Yes: rules, hooks and per-tool approval, deployable as managed settings |
Claude Code is also not the only way to reach NX knowledge. For a read-only assistant that cites your guidelines, a server that grounds Claude in the NXOpen API and your own code is often the better first step; our piece on NXOpen MCP and company knowledge explains that layer, and the NX MCP architecture whitepaper covers how the pieces fit together at scale.
Data protection, hosting and model choice
Your part files do not have to leave the network for Claude to work on them. What reaches the model is what a tool returns: feature names, expression values, measurements, check results, not the geometry file. Where the model itself runs is a separate decision, and it is made per project, not per demo.
Claude Code can use Claude directly through Anthropic or through Amazon Bedrock, Google Cloud’s Agent Platform and Microsoft Foundry. For European data residency, Claude Code resolves its default models on Bedrock to eu. cross-region inference profiles when your AWS region is an EU region, and on Google Cloud it supports the multi-region endpoint CLOUD_ML_REGION=eu. The tool layer, the audit log and all part data stay on your infrastructure; models and data can run in the EU, in Germany or on premise, and the right choice depends on your data protection requirements, the model you want and the infrastructure you have.
One honest limit: if nothing may leave the building at all, Claude Code is not the right front end, because it needs a Claude model. The same NX tool layer and the same gate then serve a fully local model through another MCP-capable assistant. We say that in the first meeting, not after the pilot.
Model choice is per use case. At the time of writing, Claude Opus 5.5 (claude-opus-5-5) suits long agentic NXOpen work, and Claude Sonnet 5.5 (claude-sonnet-5-5) suits requests where speed matters more; both have a context window of one million tokens. Longer reasoning costs time, and for a quick feature request a faster model is simply the better tool.
How we set up Claude Code for your NX team
A short, fixed sequence, with read tools before write tools. Most of the effort is not in Claude Code. It is in data engineering and tools: where your standards live, how current they are, where they may be processed, and which NXOpen functions already exist. That is what drives the implementation effort, so it comes first.
- Workshop. Analysis of your data, questions about storage locations and requirements, assessment of the candidate use cases; the result is a project plan with a cost breakdown. Preparatory calls run over Teams, and on-site and online sessions can be mixed.
- Tool catalogue. Your existing NXOpen libraries, journals and checkers become typed MCP tools. Read tools go live first, so the team sees Claude understand their parts before it changes one.
- Claude Code configuration. MCP connection, permission rules and hooks as managed settings, house rules and recurring workflows.
- Gate and audit. Preview, confirmation, undo mark and log on every build tool, plus per-tool approval on the Claude Code side.
- Pilot. A small group of engineers on real parts, measured on operations executed, previews rejected and undos used.
- Rollout. More tools, more users, and the step from conversation to functions, buttons and batch jobs wherever a workflow has settled.
Write access is a design decision as well. To change tables or other company data, Claude needs write access to them. Without it, Claude reads the content and produces an edited copy, and moving that copy into the source system stays a manual step. For most pilots that is the right place to start.
Good time to connect Claude Code to NX
- Your team already owns NXOpen code, journals or checkers that people trigger by hand
- Developers or power users are at home in a terminal or VS Code
- You can name the five operations that eat the most clicks
- Design guidelines exist as pages or documents a tool can read
- Your IT allows Claude through Anthropic, Bedrock, Google Cloud or Foundry, for example in an EU region
Fix this first
- Nothing may leave the building: use the same tool layer with a local model instead
- Your designers will never open a terminal: start with the chat panel inside NX
- You expect Claude to design: it executes known operations, your engineers own the intent
- Nobody can say which part states must never be touched: define that before any build tool exists
Start small: one use case, running in your NX
We do not start from a blank MCP server and we do not start with forty primitives. We start from one operation your team repeats, the NXOpen code you already have for it, and a part that looks like your real ones. Within a short, fixed scope you see Claude Code do that operation in your NX, through the gate, and you decide on evidence.
Fixed scope · fully credited
NX Proof-of-Value Sprint
Two to three weeks, one use case on your data, and a running prototype at the end: the step between a demo and a pilot.
- One use case, chosen with your stakeholders, here a Claude Code workflow in NX
- A running prototype on your data, evaluated against agreed metrics
- Built the way this page describes: read tools first, a gate on every change
- Credited in full against the follow-up project
On-premises or EU cloud · your tools stay yours either way
For comparison
The do-it-yourself route
Claude Code plus an open-source NX MCP server on a scratch part: a good way to see the idea work in an afternoon.
- No preview, no confirmation, no undo mark unless you build them
- Blind to Teamcenter status, templates and company standards
- Fine for learning, not for released data or an audit
Still exploring what Claude Code can do for CAD work in general, from scripting to public CAD MCP servers? Start with our guide to Claude Code for CAD.
Frequently asked questions about Claude and Siemens NX
Can Claude Code control Siemens NX?
Can Claude open NX .prt files?
How do I connect Claude Code to NX?
Does Claude change my model without asking?
Is the Claude NX integration the same as the Vision4NX Connector?
Where does our data go when Claude works in NX?
Which NXOpen languages does it support?
How do we start, and what does it cost?
Name the NX operation you would hand to Claude first.
We will show it running in a live NX session, through the gate, on a part like yours, and tell you honestly which of your tasks are ready for Claude Code and which need groundwork first.
Talk to an EngineerSiemens NX, NXOpen and Teamcenter specialists · nearshore from Romania, one hour ahead of CET · on-premises option