NXOpen MCP: Die Kurzfassung
NXOpen MCP heißt, einen KI-Agenten über das Model Context Protocol mit Siemens-NX-Wissen zu verbinden: den echten NXOpen-API-Docs, Ihren Konstruktionsrichtlinien, Ihren Werksnormen, Ihren eigenen Code-Bibliotheken. Wir bauen diese Grounding-Schichten (Verankerung) bei inteliScience für NX-Teams in der DACH-Region — damit der Agent Ihre Norm zitiert, statt eine Antwort zu erfinden.
Das Problem: Der Agent kennt NX. Aber nicht Ihre NX.
Stellen Sie einem Frontier-Modell eine NXOpen-Frage, und Sie bekommen Code, der richtig aussieht und oft auch richtig ist — im Detail nachgemessen in unserem Beitrag zu KI-Codegenerierung für NX Open. Geht es aber um Ihr NX, steht es mit leeren Händen da: Es hat nie Ihre Mindestwandstärke für Druckgussgehäuse gesehen, nie Ihren Layer-Standard, nie Ihren Zeichnungsrahmen, nie die Wrapper-Bibliothek, die Ihr Team über zehn Jahre aufgebaut hat, und es kennt nicht den Grund, warum Expression-Namen bei Ihnen mit p_ beginnen.
Also tut es, was Sprachmodelle tun. Es rät — eloquent.
Die Rateversuche kommen in zwei Spielarten, und beide kosten echte Arbeitsstunden. Die erste ist der halluzinierte API-Aufruf — eine Methode, die auf der behaupteten Klasse gar nicht existiert, entdeckt beim Kompilieren. Die zweite ist schlimmer, weil nichts fehlschlägt: eine Antwort, die als allgemeine Ingenieurspraxis plausibel ist, aber Ihrer Werksnorm widerspricht — entdeckt im Design-Review. Oder gar nicht.
Beide haben dieselbe Ursache. Das Modell ist nicht dumm; es ist unverankert. Und seit Anthropic im November 2024 das Model Context Protocol vorgestellt hat, gibt es einen standardisierten, herstellerneutralen Weg, das zu beheben.
Zwei Arten von MCP-Servern für NX — dieser Artikel handelt von der leisen Sorte
MCP-Server für Siemens NX zerfallen in zwei Kategorien, die ständig durcheinandergeworfen werden. Aktions-Server lassen einen Agenten etwas tun — Features erstellen, Expressions setzen, STEP exportieren — mit allem, was das an Vertrauen, Vorschau und Audit nach sich zieht; diese Seite ist die Act-Stufe unserer NX-KI-Assistenten-Familie. Wissens-Server rühren das Modell nie an. Sie beantworten die eigenen Fragen des Agenten: Was gibt diese API zurück, was sagt die Norm, wie haben wir das beim letzten Mal gelöst.
| Wissens-Server (read-only) | Aktions-Server (schreibt in NX) | |
|---|---|---|
| Aufgabe | ruft ab und zitiert: API-Docs, Richtlinien, Teilehistorie | führt aus: Features, Expressions, Zeichnungen, Exporte |
| Risiko | nahe null — kann das Modell nicht anrühren | braucht Vorschau, Bestätigung, Undo-Marken, Audit-Log |
| Governance | ein einziges Security-Review | Berechtigungen, Logging, Abstimmung mit dem Betriebsrat |
| Hier starten? | ja — erster Erfolg in Wochen | nachdem die Wissensschicht steht |
Die Wissens-Variante bekommt einen Bruchteil der Aufmerksamkeit und liefert für die meisten NXOpen-Teams früher Wert. Ein rein lesender Server kann keine Baugruppe beschädigen, braucht kein Bestätigungs-Gate und besteht ein IT-Security-Review in einem Meeting statt in fünf. Unsere klare Empfehlung: Wenn Sie mit MCP in einer NX-Umgebung starten, starten Sie hier.
Grounding-Level 1: Die echte NXOpen-API, nicht die erinnerte
Die erste Grounding-Schicht ist öffentliches Wissen, präzise serviert. Das Open-Source-Projekt nxopen-mcp indexiert die NXOpen-.NET-Dokumentation einer lokal installierten, lizenzierten NX-Version und liefert einem Coding-Agenten exakte Klassen, Member und Signaturen — hybrides Retrieval, das semantische BGE-M3-Embeddings mit exakter Namenssuche kombiniert. Der Agent hört auf, Methoden zu erfinden, weil er sie nachschlagen kann — offline, gegen genau die NX-Version, die Sie einsetzen.
Gerade der letzte Punkt wiegt schwerer, als er klingt. NX erscheint zweimal im Jahr — NX 2606 kam im Juni 2026, und Siemens ordnet es inzwischen unter dem Designcenter-Dach ein — und die API-Erinnerung eines Modells ist immer eine Mischung aus Versionen. Ein MCP-Lookup gegen Ihr installiertes NX ist konstruktionsbedingt versionstreu.
Zum Vergleich: Der aktionsseitige Community-Server NX_MCP (84 GitHub-Stars am 14. September 2026, validiert gegen NX 2506) stellt 16 Standard-Tools plus 34 experimentelle Tools zum Steuern von NX bereit. Nützlich für Experimente — aber beachten Sie, wie viel kleiner die Risikofläche des Retrieval-Servers ist: Er hat nichts, was er rückgängig machen müsste.
Grounding-Level 2: Ihre Konstruktionsrichtlinien und Werksnormen
Das ist die Schicht, die Ihrer Organisation wirklich gehört und die niemand sonst nachbauen kann. Konstruktionsrichtlinien, Werksnormen, Checklisten, Abweichungsfreigaben — in den meisten NX-Betrieben liegen sie als PDFs und Wiki-Seiten vor, die Neueinsteiger einmal lesen und an die sich alle anderen nur halb erinnern.
Über einen Wissens-MCP-Server serviert, ändern sie ihren Charakter: Jeder MCP-fähige Agent — Claude in der IDE, ein Assistent wie Vision4NX direkt in NX, kann sie mitten in der Aufgabe abfragen und muss zitieren, was er gefunden hat.
Die Regel ist einfach: keine Quelle, keine Antwort. Fragt ein Konstrukteur “Mindestwand für AlSi9Cu3?”, nennt die Antwort des Agenten das Dokument, den Abschnitt und die Revision, aus denen sie stammt, und eine falsche oder veraltete Antwort ist dann ein nachverfolgbares Dokumentenproblem, kein KI-Rätsel. Wir halten an dieser Regel fest, auch wenn der Assistent dadurch häufiger “Ich habe nichts gefunden” sagt. Eine technische Antwort ohne Quellenangabe ist ein Gerücht.
Tiefer einsteigen? Was es braucht, damit Agenten act können — auf Grundlage dieses Wissens: Vorschau, Bestätigung, Undo-Marken, Audit-Log — steht auf unserer Siemens NX MCP Server Seite.
Sie nutzen Claude Code als Agenten? Wie wir Claude Code mit einer Live-NX-Sitzung verbinden können, steht auf unserer Serviceseite.
Grounding-Level 3: Ihr eigener Code, Ihre Templates, Ihre Teilehistorie
Die tiefste Schicht überträgt die Idee von Level 1 von Siemens’ API auf Ihre eigene. Die Wrapper-Funktionen, Journale und Template-Teile, die Ihr Team gebaut hat, sind das eigentliche Vokabular Ihrer NX-Umgebung, und sie lassen sich genau wie die offizielle Doku indexieren und bereitstellen, sodass der Agent die Standard-Aufsatzfunktion (Boss) aus Ihrer Bibliothek vorschlägt, statt die Geometrie aus Primitiven neu zu erfinden.
Die Teilehistorie schließt den Kreis. „Haben wir so einen Halter schon einmal gelöst?“ ist eine Retrieval-Frage über freigegebene Teile, Zeichnungen und Änderungsaufträge — rein lesend gegen Teamcenter, beantwortet mit Item-IDs, die der Konstrukteur öffnen kann. In der Praxis schneiden wir diese Schicht mit jedem Kunden sorgfältig zu: Die Zugriffskontrolle auf den Index zählt genauso viel wie der Index selbst, denn ein Wissens-Server serviert bereitwillig alles, womit man ihn gefüttert hat. Eine exportkontrollierte Baugruppe muss für den Agenten so unsichtbar sein wie für einen unbefugten Kollegen.
Worauf Sie bei einem Wissens-MCP-Setup achten sollten
Fünf Kriterien trennen eine nützliche Grounding-Schicht von einer Demo — egal, ob Sie selbst bauen oder mit einem Partner wie inteliScience:
- Zitate sind Pflicht, nicht Dekoration. Jede Antwort nennt Dokument, Revision und Abschnitt. Tools, die Prosa ohne Herkunftsnachweis liefern, fallen im Review durch.
- Der Index kennt Revisionen. Eine im März abgelöste Richtlinie darf im April nicht mehr serviert werden — veraltetes Grounding ist schlimmer als keines, weil es mit falscher Sicherheit daherkommt.
- Die Zugriffskontrolle sitzt im Server. Der Agent sieht nur, was der fragende Nutzer sehen darf: rollenbasiert zugeschnittene Indizes, kein großer Sammeltopf.
- Embedding und Retrieval laufen dort, wo die Dokumente liegen. Für die meisten Fertiger in der DACH-Region heißt das On-Premises — Ihre Werksnormen sind Wettbewerbswissen, und nichts an MCP verlangt, dass sie das Haus verlassen. Ein gehostetes Modell wie
claude-sonnet-5-5kann trotzdem die Reasoning-Schicht sein; die Dokumente selbst bleiben im Haus. - Es gibt ein Evaluations-Set. Zwanzig echte Fragen Ihrer Konstrukteure, mit bekannten korrekten Quellen, nach jedem Index-Update erneut ausgeführt. Retrieval-Qualität wird gemessen, nicht gefühlt.
Punkt 4 ist die Stelle, an der wir die meisten internen Projekte stocken sehen — die Retrieval-Demo läuft im Notebook, und dann betreten DSGVO, SSO und der Betriebsrat den Raum. Genau diese Lücke zwischen „läuft auf meinem Rechner“ und „läuft im Unternehmen“ ist der Teil, den man richtig machen sollte.
Häufig gestellte Fragen
Was ist NXOpen MCP?
NXOpen MCP bezeichnet den Einsatz des Model Context Protocol, um KI-Agenten mit Siemens-NX-Wissen zu verbinden: der NXOpen-API-Dokumentation einer lizenzierten NX-Installation, den Konstruktionsrichtlinien des Unternehmens und internen Code-Bibliotheken. Der Agent fragt diese Quellen über typisierte Tools ab und zitiert, was er abruft, statt aus seinem Trainingsgedächtnis zu antworten.
Was ist der Unterschied zwischen einem Wissens-MCP-Server und einem Aktions-MCP-Server?
Ein Wissens-Server ist rein lesend: Er ruft ab und zitiert — API-Signaturen, Richtlinien-Passagen, Teilehistorie. Ein Aktions-Server führt über NXOpen Operationen in NX aus und braucht deshalb Vorschau, Bestätigung, Undo-Marken und Audit-Logging. Die meisten Teams sollten zuerst die Wissensseite ausrollen; sie trägt fast kein operatives Risiko.
Kann ein MCP-Server einen KI-Agenten in unseren eigenen Konstruktionsrichtlinien verankern?
Ja — das ist in einer NX-Umgebung wohl sein bester Einsatz. Richtlinien und Werksnormen werden indexiert (typischerweise mit lokalen Embeddings), als Retrieval-Tools bereitgestellt, und jede Antwort liefert Dokument-ID, Revision und Abschnitt der Fundstelle mit. Falsche Antworten werden zu nachverfolgbaren Dokumentproblemen statt zu stillen Modellfehlern.
Wie aufwendig ist es, unsere Konstruktionsrichtlinien mit einem KI-Agenten zu verbinden?
Weniger, als die meisten Teams für einen ersten Schnitt erwarten: ein fokussiertes Dokumentenset, ein lokaler Embedding-Index, ein Retrieval-Tool mit Zitierpflicht und ein Evaluations-Set aus echten Konstrukteursfragen — Wochen, nicht Quartale. Der Aufwand wächst mit der Governance, nicht mit der Technik: Revisionshandling, Zugriffskontrolle und On-Premises-Betrieb sind die Stellen, an denen die eigentliche Arbeit sitzt.
Ist NXOpen MCP besser als das Fine-Tuning eines Modells auf unseren Engineering-Daten?
Für dieses Problem: ja. Fine-Tuning backt Wissen in Modellgewichte ein — teuer zu aktualisieren, unmöglich zu zitieren und veraltet an dem Tag, an dem sich eine Richtlinie ändert. Retrieval über MCP hält das Wissen in versionierten Dokumenten, die der Agent wörtlich zitiert, ist aktuell, sobald der Index es ist, und funktioniert mit jedem MCP-fähigen Modell — auch mit vollständig lokalen.
Nächster Schritt
Wenn Ihre Konstrukteure Richtlinien-Passagen heute schon von Hand in Chat-Fenster kopieren, ist die Grounding-Schicht überfällig.
Sprechen Sie mit unseren Ingenieuren darüber, wie Sie einen Agenten in Ihrem NX-Wissen verankern