Che cos'è un server ERP MCP?

Un server che trasforma un sistema in strumenti

Il Model Context Protocol ha tre ruoli. Un host è un'applicazione AI come Claude o ChatGPT. All'interno dell'host, viene creato un client per server e parla solo con quel server. Un server è un servizio che offre contesto e capacità all'host attraverso un numero ridotto di primitive. I principi di design della specifica affermano che i server dovrebbero essere facili da costruire, componibili e incapaci di vedere l'intera conversazione o altri server; l'host mantiene la conversazione e applica il consenso, il server vede solo le chiamate a esso indirizzate.

Un server ERP MCP non è quindi l'ERP. È la superficie di azione dell'ERP, espressa come strumenti con input tipizzati, serviti a un URL. La decisione di design interessante è cosa sia uno strumento. Un server meteorologico ne ha uno; un sistema aziendale ne ha centinaia, e quelli utili sono azioni che una persona potrebbe intraprendere (creare una fattura, registrare un pagamento, spostare un affare, riservare stock) piuttosto che righe in tabelle. Il server workspace di Sois, ad esempio, pubblica strumenti con nomi come crea fattura, registraPagamento, searchContacts e esaminareContatto, raggruppati per modulo, e l'elenco esatto che un chiamante riceve dipende da chi è.

Strumenti, risorse e suggerimenti

La specifica definisce tre primitive del server, e differiscono in chi controlla il loro utilizzo. Gli strumenti sono controllati dal modello: il modello decide quando chiamarne uno. Le risorse sono guidate dall'applicazione: l'host decide quale contesto allegare, spesso con l'utente che sceglie da un elenco. I prompt sono modelli controllati dall'utente. Un ERP ha bisogno della prima, può beneficiare della seconda e raramente ha bisogno della terza.

Due caratteristiche dei risultati degli strumenti sono importanti per un sistema aziendale. Uno strumento può dichiarare un outputSchema e restituire contenuto strutturato che vi si conforma, insieme al testo che un modello legge, in modo che un'integrazione possa utilizzare il risultato senza analizzare la prosa. E uno strumento che fallisce per un motivo aziendale (una fattura nello stato sbagliato, una data nel passato, un permesso mancante) restituisce un risultato normale con isError: true e una spiegazione, piuttosto che un errore di protocollo, in modo che il modello possa correggere il proprio input e riprovare. Gli errori di protocollo sono riservati a richieste malformate e strumenti sconosciuti.

Il trasporto e la specifica attuale

Due trasporti sono standard. Stdio è per un server che il client avvia come processo locale, che è come funzionano gli strumenti desktop come l'accesso ai file. HTTP streamabile è per server remoti ed è ciò che utilizza un ERP: il server espone un endpoint che accetta un POST HTTP per messaggio JSON-RPC e risponde con un oggetto JSON o un flusso di eventi inviati dal server limitato a quella richiesta, in modo che una chiamata lunga possa inviare progressi prima del suo risultato finale. Il precedente HTTP con trasporto SSE è deprecato.

La revisione attuale, 2026-07-28, ha modificato il trasporto in un modo che è importante per chiunque distribuisca un server dietro un bilanciatore di carico. Ha rimosso le sessioni a livello di protocollo: non c'è più un handshake di inizializzazione o un'intestazione di identificazione della sessione, ogni richiesta porta la propria versione del protocollo e le capacità del client nei propri metadati, e un server che ha bisogno di stato tra le chiamate restituisce un handle esplicito che il modello passa indietro come argomento. I server scritti contro la revisione 2025-11-25, che utilizzavano sessioni, continuano a funzionare perché i client sono tenuti a rilevare l'era precedente e tornare indietro; un nuovo server non dovrebbe adottare sessioni.

Autorizzazione: per chi è la chiamata

Per i trasporti HTTP, la specifica definisce un flusso OAuth 2.1. Il server è un server di risorse e deve pubblicare i metadati delle risorse protette (RFC 9728) nominando il suo server di autorizzazione; quando una richiesta arriva senza un token, risponde 401 con un'intestazione WWW-Authenticate che punta a quei metadati e, idealmente, al minor ambito necessario. Il client scopre gli endpoint del server di autorizzazione, si identifica (i documenti dei metadati dell'ID client sono il percorso raccomandato; la registrazione dinamica è mantenuta per compatibilità), esegue un flusso di codice di autorizzazione con PKCE e deve includere l'URI canonico del server come parametro della risorsa affinché il token sia legato solo a questo server. Il server deve convalidare quel pubblico, deve rifiutare i token emessi per qualsiasi altra cosa e non deve mai passare un token a un altro servizio.

La conseguenza per un ERP è quella importante. Poiché il token identifica una persona, il server può variare il risultato di tools/list in base alle credenziali nella richiesta, e la specifica lo afferma esplicitamente. Questo è il meccanismo per il filtraggio basato sui ruoli: la lista di un utente finanziario e la lista di un utente di magazzino provengono dallo stesso server e sono diverse. Un ambito insufficiente a runtime è segnalato con un 403 e una sfida di ambito da cui il client può progredire, anche se per la maggior parte dei sistemi aziendali il vero confine è il ruolo nell'ERP piuttosto che il grosso ambito OAuth.

La parte difficile: permessi e transazioni

Tutto quanto sopra può essere implementato in un pomeriggio con un SDK. Ciò che separa un server ERP MCP da una demo è il trattamento delle due cose che il protocollo lascia al server: se una chiamata è consentita e cosa significa una chiamata.

Il permesso deve essere controllato due volte. Filtrare la lista degli strumenti impedisce al modello di scegliere qualcosa che non dovrebbe, risparmiando token e confusione. Controllare di nuovo quando lo strumento viene eseguito è il confine reale, perché un client può inviare qualsiasi chiamata desideri. Un rifiuto è meglio restituito come un errore di esecuzione dello strumento, in modo che il modello lo legga e lo riporti, piuttosto che come un errore di trasporto che termina il turno. Questo è come appare una chiamata rifiutata da uno spazio di lavoro Sois: un risultato normale, contrassegnato, con una ragione.

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tool not permitted for this account: approveInvoice requires the finance approver role."
      }
    ],
    "isError": true
  }
}

Un rifiuto di permesso restituito come un errore di esecuzione dello strumento. Il modello impara il perché e può chiedere alla persona di approvare invece; nulla è stato scritto. Sois riserva anche codici di errore JSON-RPC per sessioni non autorizzate, crediti insufficienti, strumenti non consentiti e limiti di budget raggiunti.

Le transazioni sono la seconda metà. Uno strumento dovrebbe mappare a una transazione aziendale con un chiaro prima e dopo: crea fattura produce una bozza con un identificatore, registraPagamento applica un pagamento a una fattura, e nessuno lascia uno stato parzialmente scritto se fallisce. I modelli riprovano, quindi le scritture dovrebbero essere sicure da ripetere o dovrebbero rifiutare una ripetizione con un messaggio chiaro; le annotazioni della specifica consentono a un server di dichiarare uno strumento come di sola lettura, idempotente o distruttivo, e i client come ChatGPT utilizzano quegli indizi quando decidono se chiedere conferma. Dove un passaggio richiede una decisione che è al di sopra dell'autorità dell'agente, il server può restituire un risultato che richiede input chiedendo alla persona una domanda attraverso il client, piuttosto che indovinare.

Come Sois implementa uno

Uno spazio di lavoro Sois è un server MCP a un'unica URL, l'indirizzo dello spazio di lavoro seguito da /api/mcpRisponde alla sfida 401 con metadati delle risorse protette, pubblica i metadati del server di autorizzazione, richiede PKCE e emette token limitati allo spazio di lavoro; un connettore in Claude o ChatGPT completa l'accesso senza nulla da incollare. Un token bearer con una chiave API è disponibile per script che non utilizzano OAuth, con identità e spesa mantenute in credenziali separate per scelta.

L'elenco degli strumenti è generato dalle definizioni degli strumenti in tempo reale e filtrato per ruolo e app installate, quindi ogni chiamata viene controllata per autorizzazione all'esecuzione e fallisce in modo sicuro. Le chiamate sono limitate per connessione, misurate dove l'agente dello spazio di lavoro esegue il ragionamento e prive di costi AI dove l'agente del chiamante lo fa, con un budget impostato dallo spazio di lavoro, e registrate con input e risultati contro la persona che le ha effettuate. Le app pubblicate nel marketplace aggiungono i loro strumenti allo stesso elenco secondo le stesse regole, quindi l'app di uno sviluppatore è operabile da un agente nel momento in cui viene installata.

Domande che le persone pongono

Questo articolo viene revisionato quando i prodotti che descrive cambiano. Prossima revisione programmata: 4 dicembre 2026.