Negli ultimi mesi il Model Context Protocol (MCP) si è imposto come il primo serio tentativo di standardizzare il modo in cui i Large Language Model dialogano con sistemi esterni. Per chi lavora su PLM — e in particolare su Siemens Teamcenter — la cosa è più interessante di quanto sembri a prima vista.

Cosa è MCP, in due righe

MCP è un protocollo aperto che definisce come un LLM può scoprire ed eseguire tool esposti da un sistema esterno. È, di fatto, l’equivalente di USB per gli agenti AI: un’interfaccia comune che disaccoppia il modello dalle integrazioni specifiche. Una volta che un sistema “parla MCP”, qualunque modello compatibile può usarlo — oggi un certo LLM, domani uno migliore, senza riscrivere l’integrazione.

Perché ha senso su Teamcenter

Teamcenter è un sistema enterprise pesante: ricchissimo dal punto di vista funzionale, ma con una user experience che riflette la sua eredità da client desktop. Le query strutturate (saved queries, attributi, relazioni) sono potenti ma richiedono familiarità che la maggior parte degli utenti che non lo usano quotidianamente non ha.

Esporre le operazioni Teamcenter come tool MCP cambia il modello di interazione:

  • Un PLM Manager scrive “mostrami tutte le revisioni rilasciate questo mese sul progetto Alfa, raggruppate per famiglia” — e ottiene la risposta, eseguibile come query reale e non come allucinazione.
  • Un workflow di approvazione può essere avviato conversazionalmente: l’agente conferma cosa sta per fare, e con il Function Calling procede o si ferma sulla base della risposta dell’utente.
  • I report periodici si automatizzano senza scrivere reportlet Java: l’LLM compila la struttura, l’agente recupera i dati, il file PDF è pronto.

Quattro aspetti tecnici che fanno la differenza

  1. Tool discovery. Il modello non deve “sapere” cosa Teamcenter sa fare: lo scopre runtime dal server MCP. Questo permette di estendere la superficie esposta senza retraining.
  2. Schema-driven invocations. Ogni tool ha uno schema esplicito (input, output, errori). Le chiamate sono validate prima di colpire Teamcenter — addio chiamate malformate.
  3. Reversibilità e dry-run. Le operazioni delicate possono essere precedute da una preview eseguita dall’agente, da approvare prima dell’apply. È la differenza fra demo e produzione.
  4. Multi-tenant e auditing. Le chiamate passano dall’identity dell’utente, non da un service account onnipotente. Quello che fa l’agente lo fa a nome di chi sta chattando.

Implementazione FITEC: il prodotto PaLoMa

Tutto questo non è teoria: è la base su cui abbiamo costruito PaLoMa, il nostro assistente AI per Teamcenter. PaLoMa orchestra agenti specializzati (ricerca, BOM, workflow, reportistica) sopra un server MCP custom che parla con Teamcenter via API. Il valore non sta nell’LLM (intercambiabile) — sta nel server MCP, nei tool che espone, e nella disciplina con cui sono scritti.

Se stai valutando AI sopra il tuo PLM, MCP è il punto giusto da cui partire — e non è specifico di Teamcenter. Lo stesso pattern funziona su ERP, MES, sistemi di documentazione tecnica.