Server MCP pentru Siemens NX

Chatboții răspund. Agenții acționează. Un server MCP este mufa care îi permite unui agent AI să acționeze în interiorul Siemens NX — iar diferența dintre un demo de weekend și un tool pe care un manager CAD îl aprobă este tot ceea ce e construit în jurul lui.

Un server MCP pentru Siemens NX este un program care expune operațiile NX ca tool-uri tipizate pe care un agent AI le poate apela prin Model Context Protocol — implementat pe NXOpen, API-ul oficial de automatizare NX. Conectați unul, iar un model poate crea feature-uri, seta expresii, deriva desene și exporta fișiere STEP într-o sesiune NX reală, pe o piesă reală. Noi construim acel strat pentru organizații de inginerie: tool-uri curatoriate pe propriile dumneavoastră biblioteci NXOpen, cu poartă de previzualizare și confirmare, marcaje de undo, jurnal de audit și implementare on-premises — livrat prin Vision4NX Connector.

Este stratul tehnologic aflat sub familia noastră Asistenți AI & chatboți pentru NX : fiecare asistent de acțiuni de pe acea pagină vorbește MCP pentru a ajunge în NX și în Teamcenter. Această pagină explică ce este de fapt un server MCP pentru NX, ce există în 2026, de ce varianta naivă cedează în producție — și cum construim unul în care departamentul dumneavoastră de inginerie poate avea încredere.

Siemens NX MCP: versiunea scurtă

• MCP (Model Context Protocol) este un standard deschis, introdus de Anthropic la finalul lui 2024, care le permite aplicațiilor AI să descopere și să apeleze tool-uri externe — portalul pentru dezvoltatori al Siemens îl descrie drept “portul USB-C pentru aplicațiile AI”.
• Un server MCP pentru NX împachetează operațiile NX ca tool-uri MCP peste NXOpen. Orice agent capabil de MCP — Claude, asistenți de tip Copilot sau un asistent de inginerie construit special — poate apoi controla NX prin el.
• Ce există astăzi: servere open-source ale comunității (unul expune 47 de tool-uri de modelare de nivel jos), servere de retrieval care împiedică agenții să halucineze apeluri NXOpen și Design Copilot de la Siemens, ancorat în documentație. Din câte știm, nu există niciun server MCP oficial Siemens pentru operații de modelare NX.
• Lacuna: serverele brute îi dau unui agent control de nivel jos nerestricționat — fără previzualizare, fără confirmare, fără jurnal de audit, fără permisiuni, fără cunoașterea template-urilor și a standardelor dumneavoastră. Acesta este un demo, nu un tool.
• Ce construim noi: un strat de tool-uri MCP pentru NX curatoriat, pe propriile dumneavoastră biblioteci NXOpen, protejat de poarta de previzualizare și confirmare, sigur la undo, jurnalizat, restricționat pe roluri, capabil on-premises — arhitectura din spatele NX Action Assistant.

Ce este de fapt un server MCP pentru Siemens NX

Fiecare integrare între un model lingvistic și un software era până acum realizată ad-hoc: un plugin aici, o schemă de function-calling dincolo, fiecare scrisă pentru un model și o aplicație. MCP standardizează această cusătură. Trei roluri: host-ul este aplicația cu care vorbește inginerul — un panou de chat, un IDE, un asistent în NX. Rolul de client din interiorul host-ului vorbește protocolul. Iar serverul este locul unde trăiesc capabilitățile: anunță o listă de tool-uri cu parametri tipizați, modelul decide când să apeleze unul, serverul îl execută și returnează un rezultat structurat.

Dacă ați scris cod NXOpen, modelul mental vă este familiar. Un instrument MCP este o funcție cu semnătură și docstring, de exemplu un instrument de extrudare care primește ca parametri o schiță, o distanță și o direcție, doar că apelantul este un model care citește docstring-ul, nu un dezvoltator care citește referința API. Nimic din protocol nu este specific unui furnizor, și tocmai de aceea se răspândește: același server funcționează cu agenți diferiți, iar același agent poate combina într-o conversație un server NX cu un server Teamcenter și un server de documentație.

Consecința practică pentru o organizație CAD: modelul nu mai trebuie să scrie cod NXOpen pentru a face ceva în NX. Trebuie să aleagă tool-ul potrivit și să completeze parametrii potriviți. Asta mută riscul de la “va compila codul generat” — problema pe care o tratăm în Generarea de cod cu AI pentru NX Open — la “a ales tool-ul potrivit, pe piesa potrivită, cu valorile potrivite, și a verificat cineva înainte să ruleze”. O problemă diferită și, în unele privințe, mai periculoasă, pentru că un apel de tool care reușește arată exact ca un apel de tool care a fost corect.

Pentru echipele care lucrează în Claude Code, partea de client a acestei configurații, inclusiv aprobarea per instrument, este descrisă pe pagina noastră despre integrarea Claude NX.

Când un singur model cu toate instrumentele nu este suficient, agentic CAD pentru Siemens NX împarte munca între mai mulți agenți specializați, care apelează toți același server cu poartă de confirmare.

Peisajul NX MCP în 2026

Căutați “Siemens NX MCP” și veți găsi trei categorii de lucruri. Sunt confundate constant, așa că merită să fim preciși în privința a ceea ce este fiecare:

De ce un server MCP NX brut cedează în producție

Nimic din toate acestea nu îi critică pe cei care scriu servere open-source. Este lista de întrebări pe care un manager CAD, un responsabil de securitate IT și consiliul de întreprindere le vor pune la prima întâlnire — și motivele pentru care un strat MCP NX de producție nu seamănă deloc cu unul demo.

Granularitatea. Patruzeci și șapte de tool-uri de nivel jos — desenează dreptunghi, extrudează, adaugă blend — sunt altitudinea greșită pentru o organizație de inginerie. Un agent care asamblează o carcasă din primitive ignoră piesa dumneavoastră de start, standardul de layere, convențiile de denumire a expresiilor și cadrul desenului. Tool-urile de care are nevoie un departament de proiectare sunt tool-uri de domeniu: creează piesă din template-ul X, derivează desenul conform standardului Y, rulează setul de verificări Z. Aceste tool-uri există deja în majoritatea organizațiilor NX — ca biblioteci NXOpen, journal-uri și wrappere construite de-a lungul unui deceniu. Un server MCP ar trebui să le expună pe ele, nu să reinventeze modelarea de la zero.

Imediatețea și reversibilitatea. Un instrument brut se execută în momentul în care modelul îl apelează. Dacă modelul citește greșit “5 mm” drept “5” într-o piesă ale cărei unități sunt inch, feature-ul este construit înainte să-l vadă cineva. Instrumentele de producție au nevoie de un dry run (ce se va schimba, pe care ocurențe, cu ce parametri) și de o confirmare umană pentru orice modifică geometria, expresiile, atributele sau starea PLM. Iar NX are marcaje de undo; majoritatea serverelor demo nu setează niciodată unul. Fiecare instrument care modifică din stratul nostru este un singur pas de undo: o acțiune greșită se află la un Undo distanță, iar jurnalul arată exact care acțiune a fost aceea.

Sesiunile și licențele. NX rulează o sesiune interactivă per utilizator, o licență per loc. Un server MCP trebuie să decidă dacă rulează în interiorul sesiunii live a inginerului (potrivit pentru asistență interactivă) sau headless într-o sesiune batch (potrivit pentru operații în masă și verificări) — iar cele două au nevoie de puncte de intrare NXOpen diferite, de tratare a erorilor diferită și de licențiere diferită.

Modul gestionat. Aproape fiecare instalare NX serioasă rulează sub Teamcenter. O piesă nu este un fișier; este o revizie de articol cu un status, o stare de checkout și un workflow de eliberare. Un server care “salvează” senin o piesă nu a întâlnit niciodată o revizie eliberată. Stratul de tool-uri trebuie să fie conștient de Teamcenter — să refuze datele eliberate, să respecte checkout-ul și să predea acțiunile PLM unui set de tool-uri restricționat prin permisiuni, precum Teamcenter Action Assistant.

Permisiunile, auditul — și locul unde rulează modelul. Cine are voie să apeleze care tool? Asistentul unui stagiar nu ar trebui să exporte STEP dintr-un ansamblu supus controlului exporturilor. Fiecare apel are nevoie de un utilizator, un timestamp, parametrii, confirmarea și rezultatul, scrise acolo unde un auditor le poate citi. Iar apelurile de tool-uri transportă nume de geometrii, valori de expresii, numere de piese — dacă agentul din spatele lor este un model din cloud public, acel context părăsește clădirea cu fiecare cerere. Pentru majoritatea producătorilor din DACH, modelul trebuie să poată rula on-premises. Protocolul o permite; majoritatea demo-urilor o ignoră.

Deriva de versiune. NXOpen este stabil, dar nu înghețat — NX apare de două ori pe an, iar un tool construit pe un apel deprecat eșuează la următorul upgrade. Se aplică aceeași disciplină ca pentru automatizarea dumneavoastră existentă: API-uri suportate, o matrice de versiuni, teste pe pre-release. Această disciplină este munca noastră de zi cu zi în dezvoltarea de tool-uri NXOpen personalizate.

Unde se amortizează mai întâi un strat MCP NX

Nu peste tot. Economia este aceeași ca la orice automatizare: o operație repetată cu o regulă clară bate o lucrare creativă unicat. Acestea sunt cele patru tipare pe care le vedem amortizându-se cel mai repede — fiecare corespunde unui asistent pe care îl construim deja pe acest strat.

Operații de modelare repetitive la cerere

“Adaugă modelul standard de montaj pe acest suport, M8, 4×” — executat cu biblioteca de feature-uri proprie a companiei, în loc ca modelul să improvizeze geometrie. Previzualizare, confirmare, undo. Acesta este NX Action Assistant, și de aici pornesc majoritatea clienților.

Desene și documentație

“Derivează desenul pentru această piesă conform cadrului nostru, trei vederi plus secțiunea A–A.” Munca grea o face automatizarea de desene existentă; MCP îi dă o ușă de intrare conversațională și o previzualizare — Drawing & Documentation Assistant. Pentru derivare batch deterministă, complet fără chat: automatizare a fluxurilor de lucru NX.

Verificări în timp ce modelați

Instrumentele read-only sunt cele mai sigure instrumente MCP și adesea cele mai valoroase: o verificare de aprobare returnează o listă structurată de încălcări, cu regula, obiectul și remedierea, explicate în limbaj simplu. Acesta este Live Model Check Assistant. Tot cu read-only încep și majoritatea proiectelor-pilot.

Acțiuni Teamcenter în limbaj simplu

Where-used, diferențe între revizii, pornirea unui workflow, redactarea unui ECR — prin tool-uri restricționate prin permisiuni și protejate de confirmare, niciodată printr-un model cu o parolă de Teamcenter. Teamcenter Action Assistant este aceeași arhitectură îndreptată spre PLM.

Sub toate cele patru stă latura de cunoștințe: un agent care acționează în NX ar trebui să poată, de asemenea, ask — despre NXOpen, despre standardele dumneavoastră, despre ultima dată când s-a schimbat o piesă. Acest nivel de răspunsuri este descris în ghidul nostru despre chatboții AI pentru Siemens NX, și este ceea ce Vision4NX aduce din prima zi: cunoștințe Siemens deja în asistent, cunoștințele dumneavoastră adăugate în proiect.

Construiți acum sau așteptați Siemens?

Cum îl construim — și cum să începeți

Nu pornim de la un server MCP gol și nu pornim de la patruzeci și șapte de primitive. Pornim de la ceea ce organizația dumneavoastră NX rulează deja: bibliotecile NXOpen, journal-urile pe care oamenii le declanșează manual, checkerele, șabloanele, regulile de denumire. Acestea devin primul catalog de instrumente: de regulă zece până la douăzeci de instrumente la nivel de domeniu, fiecare cu o previzualizare, un singur pas de undo și o înregistrare în jurnal. Poarta care arată o previzualizare și cere confirmarea stă între agent și sesiune; în stack-ul nostru, aceasta este Vision4NX Connector, care îi dă asistentului și o casă în interiorul NX, în locul unui tab de browser.

Modelul este oricare permite postura dumneavoastră de securitate: un model de frontieră găzduit acolo unde este acceptabil, unul găzduit în UE acolo unde contează rezidența datelor, un model open-weight pe propriul hardware acolo unde nimic nu are voie să iasă — complet air-gapped unde este necesar. Protocolului nu îi pasă, și exact acesta este rostul. Iar granița pe care o păstrăm pe fiecare pagină se aplică aici mai mult ca oriunde: agentul execută operații cunoscute, le previzualizează și așteaptă. Inginerii dumneavoastră decid și semnează.

Aceeași întrebare de protocol apare și pentru PLM: articolul nostru despre serverul MCP pentru Teamcenter explică ce există pentru Teamcenter și cum se guvernează accesul agenților la datele PLM.