Siemens NX MCP Server

Chatbots antworten. Agenten handeln. Ein MCP-Server ist der Stecker, der einen KI-Agenten in Siemens NX handeln lässt — und der Unterschied zwischen einer Wochenend-Demo und einem Tool, das ein CAD-Manager freigibt, ist alles, was darum herum gebaut ist.

Ein Siemens NX MCP Server ist ein Programm, das NX-Operationen als typisierte Tools bereitstellt, die ein KI-Agent aufrufen kann, und zwar über das Modellkontextprotokoll — implementiert auf NXOpen, der offiziellen Automatisierungs-API von NX. Einmal angebunden, kann ein Modell in einer echten NX-Session, an einem echten Bauteil Features erzeugen, Expressions setzen, Zeichnungen ableiten und STEP-Dateien exportieren. Wir bauen diese Schicht für Engineering-Organisationen: kuratierte Tools auf Ihren eigenen NXOpen-Bibliotheken, mit Vorschau-und-Bestätigungs-Gate, Undo-Marken, Audit-Logging und On-Premises-Deployment — geliefert über den Vision4NX Connector.

Es ist die Technologie-Schicht unter unserer KI-Assistenten & Chatbots für NX Familie: Jeder Aktions-Assistent auf jener Seite spricht MCP, um in NX und Teamcenter hineinzugreifen. Diese Seite erklärt, was ein NX-MCP-Server tatsächlich ist, was es 2026 gibt, warum die naive Variante in der Produktion scheitert — und wie wir einen bauen, dem Ihre Konstruktionsabteilung vertrauen kann.

Siemens NX MCP: die Kurzfassung

• MCP (Model Context Protocol) ist ein offener Standard, Ende 2024 von Anthropic eingeführt, mit dem KI-Anwendungen externe Tools entdecken und aufrufen können — Siemens’ eigenes Developer-Portal beschreibt ihn als den “USB-C-Port für KI-Anwendungen”.
• Ein NX MCP Server kapselt NX-Operationen als MCP-Tools auf Basis von NXOpen. Jeder MCP-fähige Agent — Claude, Copilot-artige Assistenten oder ein speziell gebauter Engineering-Assistent — kann NX dann darüber steuern.
• Was es heute gibt: Open-Source-Community-Server (einer stellt 47 Low-Level-Modellierungs-Tools bereit), Retrieval-Server, die Agenten davon abhalten, NXOpen-Aufrufe zu halluzinieren, und Siemens’ dokumentationsgestützter Design Copilot. Ein offizieller Siemens-MCP-Server für NX-Modellierungsoperationen ist uns nicht bekannt.
• Die Lücke: Rohe Server geben einem Agenten uneingeschränkte Low-Level-Kontrolle — keine Vorschau, keine Bestätigung, kein Audit-Trail, keine Berechtigungen, kein Wissen um Ihre Templates und Standards. Das ist eine Demo, kein Tool.
• Was wir bauen: eine kuratierte NX-MCP-Tool-Schicht auf Ihren eigenen NXOpen-Bibliotheken, abgesichert durch Vorschau und Bestätigung, undo-sicher, geloggt, rollenbeschränkt, On-Premises-fähig — die Architektur hinter dem NX Action Assistant.

Was ein MCP-Server für Siemens NX wirklich ist

Früher war jede Integration zwischen einem Sprachmodell und einer Software eine Maßanfertigung: hier ein Plugin, dort ein Function-Calling-Schema, jedes für ein Modell und eine Anwendung geschrieben. MCP standardisiert diese Nahtstelle. Drei Rollen: Der Host ist die Anwendung, mit der der Ingenieur spricht — ein Chat-Panel, eine IDE, ein Assistent in NX. Der Client im Host spricht das Protokoll. Der Server ist der Ort, an dem die Fähigkeiten leben: Er kündigt eine Liste von Tools mit typisierten Parametern an, das Modell entscheidet, wann es eines aufruft, der Server führt es aus und liefert ein strukturiertes Ergebnis zurück.

Wenn Sie schon NXOpen-Code geschrieben haben, ist das Denkmodell vertraut. Ein MCP-Tool ist eine Funktion mit Signatur und Docstring, zum Beispiel ein Extrude-Tool mit einer Skizze, einem Abstand und einer Richtung als Parameter, nur dass der Aufrufer ein Modell ist, das den Docstring liest, und kein Entwickler, der die API-Referenz liest. Am Protokoll ist nichts herstellerspezifisch, und genau deshalb verbreitet es sich: Derselbe Server funktioniert mit verschiedenen Agenten, und derselbe Agent kann in einer Unterhaltung einen NX-Server mit einem Teamcenter-Server und einem Dokumentationsserver kombinieren.

Die praktische Konsequenz für eine CAD-Organisation: Das Modell muss keinen NXOpen-Code mehr schreiben, um etwas in NX zu tun. Es muss das richtige Tool wählen und die richtigen Parameter einsetzen. Das verschiebt das Risiko von “kompiliert der generierte Code” — dem Problem aus unserem Beitrag KI-Codegenerierung für NX Open — hin zu “hat es das richtige Tool gewählt, am richtigen Bauteil, mit den richtigen Werten, und hat jemand geprüft, bevor es lief”. Ein anderes Problem, und in mancher Hinsicht ein gefährlicheres, denn ein Tool-Aufruf, der gelingt, sieht genauso aus wie ein Tool-Aufruf, der korrekt war.

Für Teams, die mit Claude Code arbeiten: Die Clientseite dieses Setups, einschließlich der Freigabe pro Tool, behandelt unsere Claude-NX-Integration.

Wenn ein Modell mit allen Werkzeugen nicht reicht, verteilt Agentic CAD für Siemens NX die Arbeit auf mehrere spezialisierte Agenten, die alle denselben über ein Gate abgesicherten Server aufrufen.

Die NX-MCP-Landschaft 2026

Suchen Sie nach “Siemens NX MCP”, finden Sie drei Arten von Dingen. Sie werden ständig miteinander vermengt — es lohnt sich also, präzise zu sagen, was jede einzelne ist:

Warum ein roher NX-MCP-Server in der Produktion scheitert

Nichts davon ist Kritik an den Leuten, die Open-Source-Server schreiben. Es ist die Liste der Fragen, die ein CAD-Manager, ein IT-Sicherheitsverantwortlicher und ein Betriebsrat im ersten Meeting stellen werden — und die Gründe, warum eine produktive NX-MCP-Schicht mit einer Demo-Schicht nichts gemein hat.

Granularität. Siebenundvierzig Low-Level-Tools — Rechteck zeichnen, extrudieren, Verrundung hinzufügen — sind die falsche Flughöhe für eine Engineering-Organisation. Ein Agent, der ein Gehäuse aus Primitiven zusammensetzt, ignoriert Ihr Startteil, Ihren Layer-Standard, Ihre Expression-Benennung und Ihren Zeichnungsrahmen. Die Tools, die eine Konstruktionsabteilung braucht, sind Domain-Tools: Bauteil aus Template X erzeugen, Zeichnung nach Norm Y ableiten, Prüfset Z ausführen. Diese Tools existieren in den meisten NX-Umgebungen bereits — als NXOpen-Bibliotheken, Journale und Wrapper, über ein Jahrzehnt gewachsen. Ein MCP-Server sollte sie bereitstellen, nicht die Modellierung von Grund auf neu erfinden.

Unmittelbarkeit und Umkehrbarkeit. Ein rohes Tool wird in dem Moment ausgeführt, in dem das Modell es aufruft. Liest das Modell “5 mm” als “5” in einem Bauteil, dessen Einheiten Zoll sind, ist das Feature gebaut, bevor es jemand sieht. Produktions-Tooling braucht einen Dry-Run (was sich ändern wird, an welchen Vorkommen, mit welchen Parametern) und eine menschliche Bestätigung für alles, was Geometrie, Expressions, Attribute oder PLM-Status verändert. Und NX hat Undo-Marken; die meisten Demo-Server setzen nie eine. Jedes verändernde Tool in unserer Schicht ist ein einzelner Undo-Schritt: Eine falsche Aktion ist nur ein Undo entfernt, und das Log zeigt genau, welche Aktion das war.

Sessions und Lizenzen. NX läuft mit einer interaktiven Session pro Nutzer, einer Lizenz pro Arbeitsplatz. Ein MCP-Server muss entscheiden, ob er innerhalb der laufenden Session des Ingenieurs läuft (richtig für interaktive Assistenz) oder headless in einer Batch-Session (richtig für Bulk-Operationen und Prüfungen) — und die beiden brauchen unterschiedliche NXOpen-Einstiegspunkte, unterschiedliche Fehlerbehandlung und unterschiedliche Lizenzierung.

Managed Mode. Fast jede ernsthafte NX-Installation läuft unter Teamcenter. Ein Bauteil ist keine Datei; es ist eine Item-Revision mit Status, Checkout-Zustand und Freigabe-Workflow. Ein Server, der ein Bauteil munter “speichert”, ist noch nie einer freigegebenen Revision begegnet. Die Tool-Schicht muss Teamcenter-bewusst sein — freigegebene Daten ablehnen, Checkout respektieren und PLM-Aktionen an ein berechtigungsbeschränktes Set von Tools übergeben wie unseren Teamcenter Action Assistant.

Berechtigungen, Audit — und wo das Modell läuft. Wer darf welches Tool aufrufen? Der Assistent eines Auszubildenden sollte kein STEP aus einer exportkontrollierten Baugruppe exportieren. Jeder Aufruf braucht einen Nutzer, einen Zeitstempel, die Parameter, die Bestätigung und das Ergebnis — geschrieben dorthin, wo ein Auditor sie lesen kann. Und die Tool-Aufrufe tragen Geometrienamen, Expression-Werte, Teilenummern — ist der Agent dahinter ein öffentliches Cloud-Modell, verlässt dieser Kontext mit jeder Anfrage das Haus. Für die meisten DACH-Fertiger muss das Modell On-Premises laufen können. Das Protokoll erlaubt es; die meisten Demos ignorieren es.

Versionsdrift. NXOpen ist stabil, aber nicht eingefroren — NX erscheint zweimal im Jahr, und ein Tool, das auf einem als veraltet markierten Aufruf aufbaut, scheitert beim nächsten Upgrade. Es gilt dieselbe Disziplin wie für Ihre bestehende Automatisierung: unterstützte APIs, eine Versionsmatrix, Tests auf dem Pre-Release. Diese Disziplin ist unser Tagesgeschäft in der Entwicklung kundenspezifischer NXOpen-Tools.

Wo sich eine NX-MCP-Schicht zuerst auszahlt

Nicht überall. Die Ökonomie ist dieselbe wie bei jeder Automatisierung: Eine wiederkehrende Operation mit klarer Regel schlägt einen kreativen Einzelfall. Dies sind die vier Muster, die sich nach unserer Erfahrung am schnellsten rechnen — jedes entspricht einem Assistenten, den wir bereits auf dieser Schicht bauen.

Wiederkehrende Modellierungsoperationen auf Zuruf

“Füge dieser Halterung das Standard-Montagemuster hinzu, M8, 4×” — ausgeführt mit der firmeneigenen Feature-Bibliothek, statt dass das Modell Geometrie improvisiert. Vorschau, Bestätigung, Undo. Das ist der NX Action Assistant, und hier starten die meisten Kunden.

Zeichnungen und Dokumentation

“Leite die Zeichnung für dieses Bauteil nach unserem Rahmen ab, drei Ansichten plus Schnitt A–A.” Die schwere Arbeit leistet Ihre bestehende Zeichnungsautomatisierung; MCP gibt ihr eine konversationelle Eingangstür und eine Vorschau — der Drawing & Documentation Assistant. Für deterministische Batch-Ableitung ganz ohne Chat: NX-Workflow-Automatisierung.

Prüfungen, während Sie modellieren

Read-only-Tools sind die sichersten MCP-Tools und oft die wertvollsten: Ein Freigabe-Check liefert eine strukturierte Liste von Verstößen mit Regel, Objekt und Korrektur, in verständlicher Sprache erklärt. Das leistet der Live Model Check Assistant. Read-only ist auch dort, wo die meisten Pilotprojekte starten.

Teamcenter-Aktionen in Klartext

Where-used, Revisions-Deltas, einen Workflow starten, einen ECR entwerfen — über Tools, die berechtigungsbeschränkt und bestätigungspflichtig sind, nie über ein Modell mit Teamcenter-Passwort. Der Teamcenter Action Assistant ist dieselbe Architektur, auf PLM gerichtet.

Unter allen vier Mustern sitzt die Wissens-Seite: Ein Agent, der in NX handelt, sollte auch in der Lage sein zu fragen — nach NXOpen, nach Ihren Standards, nach der letzten Änderung eines Bauteils. Diese Antwort-Ebene beschreibt unser Guide zu Siemens NX KI-Chatbots, und es ist das, was Vision4NX vom ersten Tag an mitbringt: Siemens-Wissen bereits im Assistenten, Ihr Wissen kommt im Projekt dazu.

Jetzt bauen oder auf Siemens warten?

Wie wir es bauen — und wie Sie starten

Wir starten nicht mit einem leeren MCP-Server, und wir starten nicht mit siebenundvierzig Primitiven. Wir starten mit dem, was Ihre NX-Organisation bereits betreibt: den NXOpen-Bibliotheken, den Journalen, die von Hand ausgelöst werden, den Checkern, den Templates, den Namensregeln. Daraus entsteht der erste Tool-Katalog: typischerweise zehn bis zwanzig Domain-Tools, jedes mit einer Vorschau, einem Undo-Schritt und einem Log-Eintrag. Das Gate, das eine Vorschau zeigt und um Bestätigung bittet, sitzt zwischen Agent und Session; in unserem Stack ist das der Vision4NX Connector, der dem Assistenten zugleich ein Zuhause in NX gibt statt eines Browser-Tabs.

Das Modell ist, was Ihre Sicherheitslage erlaubt: ein gehostetes Frontier-Modell, wo das akzeptabel ist; ein EU-gehostetes, wo Datenresidenz zählt; ein Open-Weight-Modell auf eigener Hardware, wo nichts das Haus verlassen darf — vollständig air-gapped, wo gefordert. Dem Protokoll ist das egal, und genau das ist der Punkt. Und die Grenze, die wir auf jeder Seite ziehen, gilt hier mehr als irgendwo sonst: Der Agent führt bekannte Operationen aus, zeigt sie als Vorschau und wartet. Ihre Ingenieure entscheiden und unterschreiben.

Dieselbe Protokollfrage stellt sich für PLM: Unser Artikel zum Teamcenter-MCP-Server erklärt, was es für Teamcenter gibt und wie man den Zugriff von Agenten auf PLM-Daten steuert.