Cos’è un server MCP? Come funzionano MCP e MCP UI nel 2026

Il 1º aprile 2025 Invariant Labs ha pubblicato uno strumento chiamato add. Prendeva due numeri e ne restituiva la somma. La sua descrizione conteneva anche un blocco marcato IMPORTANT, invisibile nell’interfaccia del client, che diceva al modello di leggere ~/.cursor/mcp.json e ~/.ssh/id_rsa e di far uscire entrambi i file attraverso un parametro inutilizzato. Il modello ha obbedito. L’utente ha visto un’addizione.

Quella dimostrazione è la migliore introduzione ai server MCP che conosca, perché mostra entrambe le metà insieme. Il protocollo ha funzionato esattamente come previsto: un client di IA ha scoperto uno strumento, ne ha letto la descrizione e l’ha chiamato. Il modello di fiducia era la parte che nessuno aveva ancora costruito.

Cos’è un server MCP

Un server MCP è un programma che espone strumenti, dati e prompt alle applicazioni di IA tramite il Model Context Protocol (MCP). La documentazione ufficiale definisce MCP come «uno standard open source per collegare le applicazioni di IA ai sistemi esterni». Un client di IA come Claude, ChatGPT, Visual Studio Code o Cursor si collega al server, chiede cosa offre e usa quelle funzionalità per conto dell’utente.

Anthropic ha annunciato MCP il 25 novembre 2024 con sei server già pronti: Google Drive, Slack, GitHub, Git, Postgres e Puppeteer. OpenAI l’ha adottato a marzo 2025. Google DeepMind l’ha seguita ad aprile. A dicembre 2025 Anthropic ha donato il protocollo all’Agentic AI Foundation, un fondo dedicato sotto l’ombrello della Linux Foundation, cofondato da Anthropic, Block e OpenAI.

Il problema che risolve è la moltiplicazione. Prima di MCP, ogni applicazione di IA che voleva accedere a GitHub scriveva il proprio connettore, e ogni fornitore creava un collegamento per ciascuna applicazione di IA. Dieci modelli e dieci strumenti potevano richiedere cento integrazioni. MCP riduce il numero a venti: ogni client implementa il protocollo una volta e ogni sistema espone un server.

Pensalo come il container navale delle integrazioni di IA. Prima dei container, ogni porto caricava ogni merce a mano, con le proprie gru e la propria squadra. Il container ha standardizzato la scatola, così qualsiasi nave, gru o camion poteva spostare qualsiasi carico. Non ha standardizzato cosa c’era dentro la scatola, e non ne ha mai ispezionato il contenuto. MCP fa lo stesso patto. Tieni a mente la seconda metà: torna nella sezione sulla sicurezza.

Come funziona un server MCP

La specifica attuale, versione 2026-07-28, usa messaggi JSON-RPC 2.0 tra tre ruoli. La sua stessa descrizione sta in tre righe: gli host sono «applicazioni LLM che avviano le connessioni», i client sono «connettori all’interno dell’applicazione host» e i server sono «servizi che forniscono contesto e funzionalità».

Host, client, server

L’host è l’applicazione in cui scrivi: Claude Desktop, un IDE, il tuo agente. Al suo interno gira un client per ogni connessione a un server. Il server sta dall’altra parte e parla con il sistema reale, che sia un database Postgres, l’API di GitHub o una cartella sul tuo disco. L’host decide cosa vede il modello e cosa deve approvare l’utente. Il server decide cosa farà il sistema sottostante.

1. Host Claude Desktop · un IDE · il tuo agente

   mostra gli strumenti al modello, chiede il consenso all’utente

2. Client uno per connessione al server

   parla JSON-RPC su stdio o Streamable HTTP

3. Server MCP strumenti · risorse · prompt

   descrive cosa offre ed esegue le chiamate

4. Sistema sottostante database · API SaaS · file locali

   fa il lavoro

Strumenti, risorse e prompt

Un server può offrire tre tipi di cose:

• Strumenti (tool): funzioni che il modello può eseguire, come create_issue, query_orders, send_email. Ognuno ha un nome, una descrizione e un JSON Schema per i suoi input.
• Risorse: contesto e dati che l’utente o il modello possono leggere, come un file, lo schema di un database, un record.
• Prompt: messaggi e flussi di lavoro predefiniti che l’utente può scegliere, per esempio “riassumi questa pull request”.

Gli strumenti attirano quasi tutta l’attenzione perché agiscono. Per lo stesso motivo concentrano quasi tutto il rischio.

Una chiamata a uno strumento, passo dopo passo

La revisione 2026-07-28 ha reso MCP stateless, cioè senza stato. Non c’è più l’handshake initialize: ogni richiesta porta con sé la versione del protocollo e le capacità del client in un campo _meta, e i server devono implementare un metodo server/discover perché un client possa chiedere in anticipo cosa supportano. Una singola chiamata a uno strumento ora si svolge così:

1. L’utente chiede: apri un ticket per questo bug

2. Passo 1

   Scoperta

   • Il client può chiamare server/discover per versioni e capacità
3. Passo 2

   Elenco degli strumenti

   • tools/list restituisce nomi, descrizioni e schemi di input
4. Passo 3

   Il modello sceglie uno strumento

   • L’host passa al modello le definizioni degli strumenti
5. Passo 4

   Consenso dell’utente

   • Secondo la specifica, gli host devono ottenere un consenso esplicito prima di invocare qualsiasi strumento
6. Passo 5

   Chiamata

   • tools/call con gli argomenti, versione del protocollo in _meta

7. Manca un input? Il server restituisce input_required; il client riprova con le risposte

   Passo 6

   Risultato

8. Il risultato torna al modello come contesto

Il passo 6 è nuovo in questa revisione. Un server che ha bisogno di altre informazioni non invia più una propria richiesta al client. Restituisce un risultato marcato input_required, il client raccoglie la risposta e ripete la chiamata originale. La specifica chiama questo schema Multi Round-Trip Request.

Trasporti: stdio e Streamable HTTP

La specifica definisce due trasporti standard:

• stdio: il client avvia il server come sottoprocesso e scambia JSON-RPC delimitato da a capo tramite standard input e standard output. È così che gira la maggior parte dei server locali, e significa che il server gira sulla tua macchina con i tuoi privilegi.
• Streamable HTTP: ogni messaggio è un HTTP POST verso un unico endpoint, e le risposte tornano come oggetto JSON o come flusso di eventi legato alla singola richiesta. È così che girano i server remoti in hosting.

Il vecchio trasporto HTTP+SSE è formalmente deprecato. La revisione 2026-07-28 ha anche eliminato le sessioni a livello di protocollo e l’header Mcp-Session-Id: un server che deve mantenere uno stato tra le chiamate ora genera un proprio identificativo e lo riceve indietro come normale argomento dello strumento.

Autorizzazione

L’autorizzazione in MCP è facoltativa e vale solo per HTTP. Su stdio, la specifica dice che i server dovrebbero invece prendere le credenziali dall’ambiente. Su HTTP, un server MCP protetto agisce come resource server OAuth 2.1. Deve pubblicare gli OAuth Protected Resource Metadata (RFC 9728) perché i client trovino il suo server di autorizzazione. I client devono indicare esattamente il server a cui è destinato un token (resource indicator secondo RFC 8707). I server devono rifiutare qualsiasi token non emesso per loro, e le linee guida di sicurezza indicano come esplicitamente vietato il “token passthrough”, cioè inoltrare senza modifiche il token di un client a un’API a valle.

Quest’ultima regola conta più di quanto sembri. Un server che inoltra qualsiasi token riceva diventa un proxy per chiunque ne possieda uno.

Cosa aggiunge MCP UI: server che restituiscono un’interfaccia

Le risposte testuali smettono di funzionare nel momento in cui un utente deve confrontare quaranta righe, sistemare un modulo con dodici campi o approvare un gruppo di modifiche una per una. “MCP UI” è il nome con cui le persone cercano la soluzione: un server restituisce un’interfaccia interattiva che viene mostrata dentro il client di IA, accanto alla conversazione.

Lo stato del progetto va precisato. L’idea è nata con MCP-UI, un progetto della comunità. OpenAI ha sviluppato un meccanismo simile nel suo Apps SDK. Il progetto MCP ha proposto uno standard comune con entrambe le iniziative il 21 novembre 2025 e ha pubblicato MCP Apps il 26 gennaio 2026 come prima estensione ufficiale di MCP. I pacchetti MCP-UI implementano ora quello standard e restano un terreno di sperimentazione per miglioramenti futuri.

Quindi oggi MCP UI significa MCP Apps. È ufficiale, ed è un’estensione, non il nucleo del protocollo. Le estensioni sono facoltative: client e server devono supportarle entrambi, e la documentazione dice chiaramente che «il supporto degli host varia da client a client». La documentazione di MCP Apps elenca Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam e Archestra.AI come host supportati. Un server i cui strumenti restituiscono un’interfaccia deve comunque funzionare con un client che mostra solo testo.

Dal punto di vista meccanico, riusa i pezzi che MCP ha già:

1. La descrizione di uno strumento include un _meta.ui.resourceUri che punta a una risorsa ui://.
2. L’host recupera quella risorsa, una pagina HTML con i suoi script, e può precaricarla prima che lo strumento venga chiamato.
3. L’host la mostra in un iframe isolato (sandbox) che non può leggere la pagina che lo contiene, i suoi cookie o il suo storage.
4. L’app e l’host comunicano tramite postMessage in un dialetto JSON-RPC di MCP. L’app può richiedere chiamate agli strumenti, e l’host decide quali consentire.

Il costo è reale. Adesso stai distribuendo un front-end web dentro l’applicazione di qualcun altro, con una content security policy da dichiarare, regole di rendering che non controlli e un’alternativa testuale per ogni host che la ignora. Il guadagno è che il lavoro di approvazione smette di essere una trascrizione di chat. L’elenco dei casi d’uso adatti nella documentazione si chiude con «approvare note spese, revisionare modifiche al codice o smistare le segnalazioni», ed è questo il centro onesto della questione: MCP UI dà il meglio sulle decisioni, non sulla decorazione.

Un esempio Tajo di sola lettura

L’interfaccia Alto MCP di Tajo include query_contacts, che cerca i contatti salvati nello spazio collegato. Cerca un contatto esistente tramite email e controlla ID, stato del consenso email e data dell’ultima rilevazione restituiti. Lo strumento separato get_contact_topic_status legge le iscrizioni del contatto per argomento.

Sono letture dei dati dello spazio. Non recuperano una copia aggiornata dal fornitore, non avviano una sincronizzazione e non inviano messaggi. Non dimostrano neppure che tutti i connettori siano attivi. Indaga alla fonte sui dati mancanti o obsoleti. Un risultato vuoto non prova che la persona non esista in Brevo.

Usa la documentazione MCP di Tajo per collegare un client compatibile e controllare gli strumenti effettivamente esposti al tuo spazio autorizzato. Un pannello interattivo facilita la verifica se l’host supporta MCP Apps; anche il risultato testuale deve spiegare l’esito.

Una chiamata a uno strumento non è una sincronizzazione persistente

Una sincronizzazione ricorrente richiede anche una pianificazione, identità stabili dei record, avanzamento salvato, regole per i nuovi tentativi e un registro delle scritture completate. Queste responsabilità appartengono all’applicazione che esegue il lavoro. MCP standardizza l’accesso agli strumenti; elencarli non fornisce queste regole di business.

Dopo un timeout puoi generalmente ripetere una lettura. Un invio o un pagamento potrebbe essere già avvenuto. Conserva il registro d’esecuzione e riconcilia l’esito prima di riprovare. La confidenza del modello non autorizza l’azione né rende sicura la sua ripetizione.

Per la scrittura a destinazione in un percorso concreto dei contatti, leggi la guida all’API Brevo. Per capire quando i campi calcolati richiedono una sincronizzazione dedicata e mantenuta, consulta il reverse ETL.

Il conto della sicurezza arriva con il protocollo

L’obiezione merita di essere riportata per intero: «MCP consegna a un modello probabilistico un elenco di funzioni che possono cancellare dati e inviare email, e poi si fida di testi scritti da sconosciuti per descriverle. Non è uno standard di integrazione. È un attacco alla supply chain con tanto di specifica». In gran parte è vero. La specifica ne condivide la premessa. La sua sezione sulla sicurezza dice che gli strumenti «rappresentano l’esecuzione di codice arbitrario e vanno trattati con la dovuta cautela», che le descrizioni degli strumenti «vanno considerate non affidabili, a meno che non provengano da un server affidabile», e che MCP «non può far rispettare questi principi di sicurezza a livello di protocollo».

Ecco il bilancio finora:

• Avvelenamento degli strumenti (tool poisoning). La segnalazione di Invariant Labs di aprile 2025, lo strumento add descritto sopra. Lo stesso articolo descriveva i rug pull (il tappeto tirato via da sotto i piedi), in cui un server cambia la descrizione di uno strumento dopo che l’hai approvato, e lo shadowing (adombramento), in cui un server malevolo riscrive il comportamento del modello verso un server affidabile.
• Compromissione dei server locali. A luglio 2025 JFrog ha reso nota la CVE-2025-6514 in mcp-remote, versioni dalla 0.0.5 alla 0.1.15, che permetteva a un server malevolo di eseguire comandi sulla macchina dell’utente. La stessa estate, la CVE-2025-49596 ha colpito l’MCP Inspector di Anthropic, distribuito senza autenticazione per impostazione predefinita.
• Inflazione degli scope. Le best practice di sicurezza ufficiali danno un nome allo schema: token che ricevono files:* o admin:* fin dall’inizio perché un server elencava ogni scope e il client li ha chiesti tutti.
• Preoccupazione ufficiale. A maggio 2026 la National Security Agency statunitense ha dichiarato che la «rapida proliferazione» di MCP «ha superato lo sviluppo del suo modello di sicurezza».

L’obiezione sbaglia nella conclusione. La soluzione non è mai stata smettere di collegare i modelli ai sistemi: i team lo facevano già, con chiavi API in chiaro incollate in prompt e script, senza alcuna traccia di audit. La soluzione è trattare un server MCP come qualsiasi altra dipendenza privilegiata:

• Installa server solo da fonti a cui affideresti le stesse credenziali anche fuori da MCP.
• Preferisci server remoti con OAuth e scope ristretti a binari locali che custodiscono chiavi a lunga durata.
• Richiedi un’approvazione umana per ogni scrittura e registra chi ha approvato cosa.
• Blocca le versioni dei server e ricontrolla quando cambia la descrizione di uno strumento.
• Esponi strumenti modellati sul compito, non un’intera API. Un modello non può abusare di un endpoint di cancellazione che non è mai stato esposto.

Il protocollo ha standardizzato la scatola. Ispezionare il carico resta compito tuo.

Costruire un server MCP o usarne uno esistente

Directory pubbliche come mcp.so catalogano server costruiti dalla community, e molti fornitori SaaS pubblicano i propri. Brevo, per esempio, offre un server MCP suddiviso anche in server singoli, così a un agente si possono dare i contatti senza le campagne. La scelta dipende meno dallo sforzo che da chi debba decidere la forma degli strumenti.

Quale server MCP dovrebbe usare il tuo agente?

1. Il fornitore pubblica un server che copre il compito

   Usa il server del fornitore

   Segue l’API e lo mantiene il fornitore.

2. Un solo sistema, ma ti servono meno azioni o azioni più sicure

   Usalo, ma con un perimetro ristretto

   Concedi scope minimi ed esponi solo i gruppi di strumenti che servono all’agente.

3. Dati interni o un sistema senza server

   Costruisci un piccolo server

   Pochi strumenti modellati sul compito sopra la tua API, con la tua autenticazione.

4. Il compito coinvolge due o più sistemi

   Costruisci o adotta un livello governato

   Un solo insieme di strumenti, regole di consenso e storico di audit su tutti i sistemi.

Costruire un server di base è la parte facile. Con un SDK ufficiale, un server stdio funzionante con uno strumento è il lavoro di un pomeriggio. Il costo arriva dopo: OAuth per la versione HTTP, le deprecazioni (la revisione 2026-07-28 ha deprecato Roots, Sampling e Logging, oltre a Dynamic Client Registration) e il lavoro continuo di scrivere descrizioni degli strumenti che un modello legga correttamente. Avvolgere un’API con uno strumento per endpoint è l’errore più comune. Ogni descrizione di strumento è testo che il modello deve leggere e soppesare, quindi un breve elenco di strumenti modellati sul compito batte l’intera superficie dell’API.

MCP, API, integrazioni e iPaaS

MCP non sostituisce le API. Quasi ogni server MCP è un involucro attorno a un’API. L’API resta il luogo in cui avviene il lavoro, con i suoi limiti di frequenza, il suo modello di dati e le sue stranezze. MCP cambia chi può chiamarla: un modello, a runtime, che sceglie la chiamata da una descrizione invece di uno sviluppatore che la scrive nel codice in anticipo.

Questa distinzione traccia una linea netta rispetto alle altre due cose con cui viene confuso:

• Integrazioni e iPaaS (qui il confronto tra le principali piattaforme) spostano i dati secondo una pianificazione o un trigger, in modo deterministico, che qualcuno sia in chat o no. Una sincronizzazione notturna di 40.000 ordini verso un CRM non dovrebbe dipendere da un modello che decide di fare 40.000 chiamate agli strumenti.
• Il reverse ETL riporta i dati modellati da un data warehouse agli strumenti operativi. Cos’è il reverse ETL e quando è adatto è un argomento a sé, ed è una pipeline, non una conversazione.
• MCP serve nei momenti in cui una persona o un agente deve chiedere, ispezionare o agire su quei sistemi, su richiesta.

L’errore va in entrambe le direzioni. Alcuni team costruiscono server MCP per fare sincronizzazioni massive e ottengono pipeline lente, costose e non ripetibili. Altri costruiscono integrazioni accurate e poi danno al loro assistente di IA una chiave API in chiaro per interrogarle, e ottengono una porta di servizio senza governance.

Per un’integrazione supportata, il lavoro persistente e gli strumenti per ispezionarlo devono condividere un confine esplicito di autorizzazioni. Verifica connettore, azioni consentite ed esiti registrati per quel flusso. La documentazione delle integrazioni distingue le istruzioni di configurazione dai percorsi ancora da verificare in produzione. MCP può esporre strumenti approvati separati; elencarli non dimostra che siano attivi una sincronizzazione ricorrente o tutti i controlli necessari.

In 22 mesi MCP è passato da sei server di riferimento a un progetto della Linux Foundation che Claude, ChatGPT, VS Code e Cursor parlano tutti. Collegare un modello a un sistema ora è la parte economica. Decidere cosa gli è permesso fare lì è il lavoro.