Un server MCP per il proprio sistema interno: quando serve e come progettarlo

Costruire un server MCP per il proprio sistema interno ha senso quando i dati che servono al Suo team non stanno in un prodotto che offre già un collegamento pronto, ma in un'applicazione sviluppata in casa, in un database o in un sistema che vive dietro il firewall aziendale. Il server MCP è il componente che permette a Claude di leggere quei dati e, se lo si decide, di compiere alcune azioni su di essi, secondo regole stabilite dall'azienda.

La documentazione di Anthropic definisce il Model Context Protocol come uno standard open source per collegare le applicazioni di intelligenza artificiale a sistemi esterni, e lo paragona a una porta USB-C: un attacco unico al posto di tanti cavi diversi. Secondo Google Cloud, lo standard è stato introdotto da Anthropic nel novembre 2024; IBM riporta che è stato adottato anche da OpenAI e Google DeepMind.

La decisione pratica è questa. Se il sistema è Zoho CRM o Zoho Desk e Le basta un accesso standard, conviene partire da un connettore esistente e configurarne i permessi. Se invece deve esporre regole di business proprie, dati che combinano più sistemi o un'applicazione interna, un server dedicato Le dà il controllo esatto su che cosa Claude vede e che cosa può fare. Questa guida spiega come progettarlo e quali errori evitare prima di metterlo in produzione.

Prima di progettare conviene fissare il vocabolario, perché ogni scelta successiva dipende da questi ruoli. Google Cloud descrive l'architettura in tre parti, che conviene tenere distinte anche quando si parla con i fornitori.

• Host MCP: l'applicazione in cui l'utente lavora e che contiene il modello linguistico, per esempio Claude Desktop.
• Client MCP: il componente dentro l'host che traduce le richieste del modello nel protocollo e riporta le risposte al modello.
• Server MCP: il servizio esterno che fornisce dati e funzioni al modello, collegandolo a database e servizi web. È la parte che costruisce Lei.

Il server espone strumenti, cioè azioni con un nome, una descrizione e parametri definiti, come «cerca un ticket» o «aggiorna lo stato di un ordine». Client e server si scambiano messaggi nel formato JSON-RPC 2.0. Secondo il tutorial di IBM, i meccanismi di trasporto supportati sono due: stdio, cioè input e output standard, adatto quando server e host girano sulla stessa macchina, e HTTP in streaming per i server raggiungibili in rete; le versioni precedenti del protocollo supportavano anche HTTP con eventi inviati dal server (SSE).

Un'ultima distinzione utile. Google Cloud spiega che la tecnica RAG recupera informazioni per generare testo, mentre MCP serve anche a interagire e agire nei sistemi esterni, per esempio aggiornando il CRM. È proprio la possibilità di agire che rende la progettazione dei permessi il punto centrale di tutto il lavoro.

La prima scelta architetturale riguarda il luogo in cui il server gira. Anthropic documenta due strade, con conseguenze diverse per sicurezza, distribuzione e manutenzione.

Le estensioni desktop sono pacchetti installabili che eseguono il server MCP in locale, sul computer dell'utente. Secondo il Claude Help Center, sfruttano il contesto già autenticato dell'utente, incluse le sessioni SSO, senza regole firewall aggiuntive né VPN, e le credenziali restano sul dispositivo. Possono raggiungere sistemi on premise come SAP, Oracle e applicazioni personalizzate.

I server remoti sono raggiungibili in rete e, come indica la documentazione Anthropic sui server remoti, richiedono credenziali di autenticazione e istruzioni di collegamento specifiche per ciascun server.

Per un primo progetto su un sistema interno, l'estensione desktop è spesso la via più breve. Il Claude Help Center riporta anche che molte aziende la usano come proxy sicuro verso server MCP interni, mantenendo il controllo su accessi, autenticazione e log di audit.

Google Cloud avverte che, poiché MCP può accedere ai dati ed eseguire codice tramite gli strumenti collegati, una sicurezza solida è essenziale. In pratica questo significa che ogni strumento è una porta aperta sul Suo sistema: si decide porta per porta, non per l'intero edificio.

La regola di progettazione più utile è esporre operazioni di business, non accesso tecnico. Uno strumento «trova i ticket aperti di questo cliente» è limitato e verificabile; uno strumento «esegui una query sul database» consegna al modello l'intero schema dati e ogni tabella.

Vale anche il principio inverso: Google Cloud raccomanda di non fidarsi delle descrizioni degli strumenti se non provengono da un server affidabile. Se costruisce il server in casa, la descrizione di ogni strumento è parte del controllo, perché è ciò che il modello legge per decidere quando usarlo. Deve dire con precisione che cosa fa lo strumento e che cosa non fa.

Il principio da cui partire è semplice: il server MCP non deve mai avere più diritti della persona che lo usa. Se un addetto al supporto non può vedere le fatture, nemmeno Claude deve poterle vedere quando lavora per suo conto.

Con un'estensione desktop

L'estensione usa il contesto già autenticato dell'utente. Nel manifest si possono dichiarare campi di configurazione sensibili, come un token personale: secondo la guida di Anthropic ai server locali, Claude Desktop li cifra con l'archivio sicuro del sistema operativo, cioè Keychain su macOS, Credential Manager su Windows e il gestore di chiavi della distribuzione su Linux. Il token resta così fuori dai file di configurazione in chiaro.

Con un server remoto

Qui l'autenticazione va progettata. L'autore di un resoconto pubblicato su Reddit racconta di aver impiegato una settimana di studio delle specifiche e delle segnalazioni su GitHub prima di far funzionare un server remoto, e che la sua guida doveva coprire autenticazione, autorizzazione OAuth e gestione delle sessioni. È un'indicazione realistica dell'impegno richiesto.

A livello di organizzazione

Nei piani Team ed Enterprise, Owner e Primary Owner possono abilitare o disabilitare le estensioni pubbliche e caricare estensioni personalizzate, decidendo tramite allowlist chi vi accede. I criteri aziendali impostati sulle macchine degli utenti prevalgono sui controlli nell'applicazione.

Il primo strumento dovrebbe essere di sola lettura, su un'informazione che il team cerca spesso e che oggi richiede di aprire il sistema, filtrare e copiare. Il vantaggio è doppio: il valore si vede subito e il rischio è contenuto, perché nulla viene modificato.

Prendiamo un'applicazione interna di assistenza tecnica, o un sistema che affianca Zoho Desk. Un buon primo strumento si chiama, per esempio, cerca_ticket_cliente, accetta un solo parametro obbligatorio, il codice cliente, e restituisce al massimo gli ultimi ticket con numero, oggetto, stato e data. Non restituisce allegati, non restituisce note interne, non accetta filtri liberi.

Tre accorgimenti rendono lo strumento affidabile:

• Parametri stretti: formato del codice cliente validato dal server, rifiuto di qualsiasi valore diverso.
• Risultati limitati: un numero massimo di record fissato nel codice, non scelto dal modello.
• Tempi controllati: il tutorial IBM, nel suo script di esempio, imposta un timeout di 10 secondi sulla richiesta HTTP per sicurezza di rete; un limite analogo evita che una richiesta bloccata resti appesa.

Solo quando questo strumento è stato usato per qualche settimana e i log mostrano richieste sensate, ha senso aggiungere la prima azione di scrittura, per esempio l'aggiunta di una nota a un ticket, con conferma esplicita dell'utente prima dell'esecuzione.

Ecco il percorso completo per portare lo strumento descritto sopra dentro Claude Desktop come estensione privata. I nomi delle impostazioni sono quelli della documentazione Anthropic e del tutorial IBM.

1. Scrivere il server. Il tutorial IBM usa Python 3.11 o successivo e FastMCP, un framework open source che fornisce ciò che serve per eseguire un server MCP. Le estensioni desktop supportano server Node.js, Python e binari; Claude Desktop include già un ambiente Node.js.
2. Verificare il comportamento. Con MCP Inspector, lo strumento con interfaccia grafica indicato da IBM per il debug, si controlla che cerca_ticket_cliente rifiuti un codice malformato e rispetti il limite di risultati.
3. Creare il pacchetto. Si aggiunge un file manifest.json nella cartella del server, con i metadati richiesti e il token dichiarato come campo sensibile, e si esegue il comando mcpb pack. Il risultato è un file .mcpb.
4. Installare. In Claude Desktop: Settings > Extensions, poi Advanced settings, sezione Extension Developer, «Install Extension…», selezione del file .mcpb e conferma dei passaggi richiesti.
5. Controllare che cosa vede Claude. Con il pulsante «+» nella casella della chat e la voce «Connectors» si vedono i server collegati e i loro strumenti. Deve comparire solo ciò che ha progettato.
6. Distribuire. In un piano Team o Enterprise l'Owner carica l'estensione per l'organizzazione e la inserisce nell'allowlist. Le estensioni distribuite privatamente non si aggiornano da sole: ogni nuova versione va reinstallata.

Se usa un criterio aziendale sulle macchine, verifichi che isDesktopExtensionEnabled e isDesktopExtensionDirectoryEnabled non siano impostati su «false», altrimenti l'allowlist non si popola.

La maggior parte dei problemi non nasce dal protocollo, ma da scelte fatte nelle prime ore di sviluppo e mai riviste. Questi sono gli errori che conviene cercare deliberatamente prima del rilascio.

• Account di servizio con diritti da amministratore. È comodo in sviluppo e pericoloso in produzione, perché annulla i permessi per ruolo che il sistema già applica.
• Uno strumento generico al posto di molti specifici. «Esegui query» o «chiama API» sembrano flessibili, ma rendono impossibile stabilire che cosa il modello possa fare davvero.
• Descrizioni vaghe. Il modello sceglie lo strumento leggendo la descrizione: se è ambigua, lo userà anche in casi non previsti.
• Scritture senza conferma. Ogni azione che modifica dati dovrebbe mostrare all'utente che cosa sta per accadere e attendere il suo assenso.
• Nessun registro. Senza log di chi ha chiesto che cosa, e con quale risultato, non si può né correggere né rispondere a una contestazione.
• Aggiornamenti dimenticati. Con le estensioni private ogni correzione va reinstallata su ogni postazione; serve un responsabile e una procedura.

In Svennis, prima di andare in produzione, facciamo provare ogni strumento da un utente reale con le sole credenziali del suo ruolo, perché l'errore che incontriamo più spesso è un server costruito con un account amministrativo che nessuno ha poi ridotto. Questa verifica richiede poco tempo e mette in luce in modo concreto che cosa il modello vede davvero.

Un ultimo punto: se lo stesso sistema dovrà servire più applicazioni, ricordi che, secondo IBM, un server MCP può essere definito e ospitato una volta sola e usato da molti sistemi di intelligenza artificiale. Progettarlo bene la prima volta evita di ripetere il lavoro.

Per un'impresa italiana l'idea di esporre un sistema a un soggetto esterno con regole precise non è nuova. La pubblica amministrazione la applica da tempo allo scambio di dati, e il caso del servizio SID dell'Agenzia delle Entrate offre un modello di disciplina utile anche per un server MCP.

Nello scambio via FTP descritto dall'Agenzia, i ruoli sono fissati: l'Agenzia opera sempre come client e l'ente esterno espone il server e ne comunica le credenziali. Il canale è protetto da una VPN IPsec site-to-site, le credenziali si scambiano in modalità sicura, con busta sigillata o di persona, e l'attivazione del nodo è subordinata a una verifica tecnico-funzionale e a una certificazione. Ogni modifica alla configurazione della VPN va comunicata per avviare nuovi test.

Trasposto al Suo progetto, significa quattro cose: stabilire per iscritto chi è client e chi espone i dati, consegnare le credenziali per canali sicuri e non via chat, collaudare formalmente prima dell'attivazione e ripetere il collaudo a ogni modifica rilevante del server.

Sul piano normativo, se il sistema tratta dati soggetti a obblighi specifici, il riferimento per verificare il testo vigente è Normattiva, il portale della legge vigente, aggiornato in multivigenza. Conviene che la verifica la faccia chi in azienda segue la conformità, prima di decidere quali campi il server potrà restituire.

Il lavoro si può impostare in modo ordinato, senza scrivere codice prima di avere chiare le risposte essenziali.

1. Verifichi se un connettore esiste già. Se il sistema è un CRM di mercato, parta dalla guida al collegamento di Claude con Zoho CRM o da quella su Claude con HubSpot o Salesforce tramite MCP. Un server proprio si giustifica quando il connettore standard non basta.
2. Scelga un solo processo. Una domanda che il team si pone ogni giorno, con una risposta che sta in un sistema interno. Se i dati sono dispersi in più applicazioni, valuti prima se consolidarli, come descritto nel post sull'automazione degli ordini B2B con un unico sistema Zoho.
3. Scriva la tabella degli strumenti. Per ciascuno: nome, descrizione, parametri, campi restituiti, lettura o scrittura, ruolo autorizzato.
4. Decida locale o remoto. Per un sistema dietro il firewall e pochi utenti, l'estensione desktop è di norma il punto di partenza.
5. Costruisca il primo strumento in sola lettura, lo verifichi con MCP Inspector e lo faccia provare a un utente con le credenziali del suo ruolo.
6. Fissi il collaudo prima del rilascio, con un responsabile degli aggiornamenti.

Se preferisce affrontare il progetto con chi lo ha già portato in esercizio, la pagina sulla consulenza AI dal progetto al sistema in produzione descrive come si passa dalla tabella degli strumenti a un sistema che lavora ogni giorno.