25 min di lettura

Server MCP: cos'è, come funziona e come usarlo (guida 2026)

In breve: Un server MCP è un programma che dà a un assistente di intelligenza artificiale (Claude, ChatGPT, Copilot, Cursor) la possibilità di usare strumenti e dati esterni: un database, GitHub, una cartella di file, il browser, un intero PC. Parla con l'assistente attraverso MCP (Model Context Protocol), uno standard aperto e gratuito nato in Anthropic nel 2024 e oggi gestito dalla Linux Foundation. Una volta collegato, l'assistente vede l'elenco delle azioni che il server offre e le usa da solo quando servono.

L'idea: una presa unica per l'intelligenza artificiale

MCP fa per l'AI quello che la presa USB-C ha fatto per i dispositivi: prima ogni accoppiata aveva il suo cavo, ora la presa è una sola.

Prima di MCP, collegare un assistente a un servizio voleva dire scrivere un'integrazione apposta: una per Claude e GitHub, un'altra per ChatGPT e GitHub, un'altra ancora per Claude e Slack. Con 10 assistenti e 100 servizi servivano fino a 1.000 integrazioni diverse.

Con MCP ogni servizio scrive un solo server, e ogni assistente impara un solo protocollo. Le combinazioni diventano 10 + 100: chi costruisce un server lo rende disponibile a tutti gli assistenti compatibili in un colpo.

Come è nato. L'idea viene da una frustrazione quotidiana: David Soria Parra, uno dei due creatori, passava le giornate a copiare e incollare testo tra Claude Desktop e il suo editor di codice. Con Justin Spahr-Summers ne fece un protocollo; a una settimana di progetti liberi interna ad Anthropic, a settembre 2024, quasi tutti costruirono un server MCP, compreso uno per comandare una stampante 3D. Il lancio pubblico, a fine novembre 2024, fu tiepido: la domanda più frequente era "che cos'è MCP?". (Anthropic, The Model Context Protocol)

Perché è aperto. Chi costruisce un'integrazione non sa quale app di AI sopravviverà: con uno standard chiuso nessuno investe. Rendendolo aperto, Anthropic ha spostato la concorrenza su ciò che secondo lei conta davvero, l'intelligenza del modello e i flussi di lavoro costruiti sopra, non il numero di integrazioni.

Un esempio concreto del problema. Un'azienda costruisce un assistente clienti che deve leggere gli ordini nel database, cercare nel catalogo, fare rimborsi con Stripe e avvisare il reparto su Slack. Con due modelli di AI diversi servono 2 × 4 = 8 integrazioni, ognuna con la sua autenticazione e i suoi errori; se domani si aggiunge un terzo modello, si ricomincia. Con MCP i quattro servizi restano quattro server, e cambiare modello è una riga di configurazione. (TechWorld with Nana)

Come funziona: host, client e server

Il modello non parla mai direttamente col server: tra i due c'è sempre il client, che porta le richieste e riporta i risultati.

Il giro di una richiesta, in cinque passi:

1. Il client chiede al server quali strumenti offre (tools/list).
2. Il client passa l'elenco al modello: nomi e descrizioni.
3. Tu chiedi qualcosa, e il modello decide che gli serve uno strumento.
4. Il client lo chiama sul server (tools/call), e il server fa il lavoro, di solito chiamando un'API o agendo sul computer.
5. Il risultato torna al modello, che lo usa per risponderti o per decidere il passo successivo.

Cosa offre un server: strumenti, risorse e prompt

Un server MCP può offrire tre tipi di cose, e la differenza sta in chi decide di usarle.

I messaggi sono testo in formato JSON (lo standard JSON-RPC 2.0). Ecco come appaiono, semplificati, con un server meteo immaginario. Dalla specifica del 28 luglio 2026 ogni richiesta porta con sé, nel campo _meta, la versione del protocollo e le capacità del client.

1. Il client chiede quali strumenti ci sono

{"jsonrpc": "2.0", "id": 1, "method": "tools/list",
 "params": {"_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
                      "io.modelcontextprotocol/clientCapabilities": {}}}}

2. Il server risponde con l'elenco: nome, descrizione per il modello, e lo schema dei dati che lo strumento si aspetta

{"jsonrpc": "2.0", "id": 1, "result": {"tools": [
  {"name": "meteo_oggi",
   "description": "Previsioni di oggi per una citta'",
   "inputSchema": {"type": "object",
                   "properties": {"citta": {"type": "string"}},
                   "required": ["citta"]}}
]}}

3. Il modello decide di usarlo, e il client lo chiama

{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
 "params": {"name": "meteo_oggi", "arguments": {"citta": "Como"}}}

4. Il server fa il lavoro e restituisce il risultato, che torna al modello

{"jsonrpc": "2.0", "id": 2, "result": {
  "content": [{"type": "text", "text": "Como: 18 gradi, sereno"}],
  "isError": false}}

Una risorsa si legge allo stesso modo, indicandone l'indirizzo:

{"jsonrpc": "2.0", "id": 3, "method": "resources/read",
 "params": {"uri": "file:///documenti/listino.csv"}}

Il punto da capire: il modello non vede codice né password, vede solo nome e descrizione degli strumenti. Per questo una descrizione scritta male rende uno strumento inutile, e una descrizione scritta con cattive intenzioni lo rende pericoloso (vedi Sicurezza).

La regola per scegliere tra i tre. Il co-creatore la chiama interaction model: lo stesso dato si può esporre in tre modi, e la scelta dipende da chi deve decidere quando usarlo. I prompt li sceglie l'utente (di solito compaiono come comandi con la barra, tipo /riassumi, e possono suggerire i valori mentre scrivi). Le risorse le usa l'applicazione, anche per indicizzarle e fare ricerca semantica, un uso che lui stesso definisce ancora poco esplorato. Gli strumenti li sceglie il modello. (Anthropic, MCP 201)

Due cose che il server può chiedere al client, quasi sconosciute:

• Sampling: il server chiede un ragionamento al modello che l'utente ha già scelto. Un server che deve riassumere una discussione non ha bisogno di una sua chiave API: usa l'abbonamento dell'utente, che resta padrone di costi e privacy.
• Roots: il server chiede quali cartelle di progetto sono aperte nell'editor, per lavorare solo lì.

Con la specifica di luglio 2026 queste richieste, insieme a quelle di conferma all'utente (elicitation), passano dal meccanismo delle richieste in più passaggi descritto più avanti.

Le MCP Apps. Un server può portarsi dietro anche la sua interfaccia grafica, che funziona identica dentro Claude, ChatGPT, VS Code e Cursor: l'utente la usa con le mani, il modello con gli strumenti dello stesso server. È un'estensione recente e la mostrano solo le app con interfaccia web. (David Soria Parra, The Future of MCP)

Server locali e remoti

Un server locale gira sul tuo computer e parla solo con l'app installata lì; un server remoto è raggiungibile da internet e si usa da qualsiasi dispositivo.

Un server locale in Claude Desktop si aggiunge con un'estensione (un clic) oppure a mano, nel file claude_desktop_config.json. Questo esempio dà a Claude l'accesso a una cartella con il server ufficiale per i file:

{
  "mcpServers": {
    "documenti": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\Mario\\Documenti"]
    }
  }
}

Un server remoto invece non si configura in nessun file: si incolla il suo indirizzo come connettore personalizzato nelle impostazioni dell'assistente, per esempio https://mcp.esempio.com/mcp, e si conferma l'accesso.

Esiste anche una via di mezzo: un server che gira sul tuo PC ma è raggiungibile da remoto attraverso un tunnel cifrato, come fa MCP DeskManager. Unisce l'accesso al tuo computer con l'uso da qualsiasi chat.

Perché il remoto è il futuro. A metà 2025 la grande maggioranza dei server esistenti era locale. Il remoto cambia il rapporto di fiducia: invece di eseguire sul tuo PC un programma scritto da uno sconosciuto, ti colleghi a mcp.ilmiofornitore.com di un'azienda a cui affidi già i tuoi dati, che lo aggiorna senza che tu scarichi nulla. In azienda il server sta nella rete interna e si entra con lo stesso accesso unico (SSO) di tutte le altre applicazioni. (Anthropic, MCP 201)

Come si entra in un server remoto: l'autenticazione

Un server remoto si protegge con OAuth, lo stesso sistema dei pulsanti "Accedi con Google": l'assistente non riceve mai la tua password, ma un permesso limitato che puoi revocare.

L'analogia migliore è la chiave magnetica dell'albergo: alla reception mostri il documento e ricevi una tessera che apre la tua camera e la palestra, non tutte le porte. La tessera rappresenta un accesso, non la tua identità, e non ti serve sapere cosa c'è scritto dentro: basta che la porta sappia leggerla. Il token OAuth funziona così. (Aaron Parecki, Okta)

Tre passaggi della storia di MCP spiegano come funziona oggi:

1. Server MCP e server di autorizzazione separati. Nella specifica di marzo 2025 chi scriveva un server MCP doveva anche gestire tutto OAuth. Da giugno 2025 i ruoli sono separati: l'accesso lo gestisce un servizio di identità vero, il server MCP si limita a verificare il token che riceve.
2. Basta l'indirizzo. Uno standard OAuth recente (Protected Resource Metadata) permette al server di indicare dove si trova il suo servizio di autorizzazione: per questo in Claude o ChatGPT si incolla solo l'URL e il resto si configura da solo.
3. Da DCR a CIMD. Per far parlare qualsiasi client con qualsiasi server senza accordi preventivi si usava la registrazione dinamica dei client (DCR), ma in pratica molti server la limitavano ai domini dei propri partner, e il sistema non era davvero aperto. Il co-creatore ammette che la prima versione dell'autenticazione "l'aveva sbagliata". La soluzione, scritta con Aaron Parecki, è che l'identificativo del client diventa un indirizzo web con i suoi dati (CIMD): la specifica di luglio 2026 la rende la strada principale. (AAIF, Why didn't DCR work for MCP?)

In azienda c'è un problema in più: se l'assistente deve collegarsi a venti applicazioni, il dipendente deve autorizzarle una per una e l'IT non vede nessuno di questi collegamenti. La direzione presa (cross-app access) mette in mezzo il sistema di identità aziendale: ti autentichi una volta al mattino, e ogni server ti riconosce senza altri clic.

Come si usa con Claude, ChatGPT, Cursor e VS Code

Ogni assistente compatibile ha un punto dove si aggiungono i server; cambia il nome del menu e quali tipi di server accetta.

Claude e MCP. Claude è il primo assistente nato con MCP e quello che lo supporta in più forme: i connettori remoti funzionano sul web, nell'app desktop e su telefono, mentre le estensioni portano server locali in Claude Desktop senza installare nulla a mano. Anthropic mantiene anche una directory di connettori già pronti, verificati. Due dettagli dalle guide ufficiali: le estensioni di Claude Desktop oggi si chiamano MCP Bundles (file .mcpb, prima noti come DXT), e le connessioni ai server remoti partono dai server di Anthropic, non dal tuo computer: un server remoto deve essere raggiungibile da internet anche se usi Claude Desktop.

ChatGPT e MCP. ChatGPT si collega solo a server raggiungibili da internet, perché è lui a chiamarli dai suoi computer: un server locale avviato sul PC per ChatGPT non esiste. La modalità sviluppatore permette azioni che modificano le cose, non solo letture. Le app costruite per ChatGPT con l'Apps SDK oggi si chiamano Plugins, e per collegare all'API di OpenAI un server che sta in una rete privata OpenAI offre un Secure MCP Tunnel.

I menu cambiano spesso nome: i percorsi in tabella sono quelli di ottobre 2026.

Quanti server collegare? Dipende da quanto si somigliano: tre gestori di ticket collegati insieme confondono il modello, che non sa quale scegliere; un gestore di ticket, un database e un calendario convivono senza problemi. Meglio pochi server ben distinti che tanti sovrapposti. (Anthropic, The Model Context Protocol)

Il problema del contesto, e come lo risolvono le app. Ogni strumento collegato occupa spazio nella memoria del modello con il suo nome e la sua descrizione. Le app più avanzate usano due tecniche (David Soria Parra, The Future of MCP):

• caricamento progressivo (tool search): il modello vede gli strumenti solo quando li cerca, invece di averli tutti davanti dall'inizio; in Claude Code ha ridotto di molto lo spazio occupato;
• chiamate da programma (code mode): invece di chiamare dieci strumenti uno dopo l'altro, il modello scrive un piccolo programma che li combina e lo esegue in un ambiente protetto, con meno attese e meno costi.

Cosa si fa oggi con MCP

Oggi quasi ogni servizio usato da chi lavora al computer ha un server MCP ufficiale o della comunità: l'assistente smette di essere una chat e diventa qualcuno che fa le cose.

La forza sta nelle combinazioni: "leggi l'errore su Sentry, trova il punto nel codice su GitHub, apri una issue e avvisami su Slack" diventa una sola richiesta, eseguita con tre server diversi.

Un server, migliaia di strumenti. Non serve un server per ogni servizio: Zapier ne offre uno solo con oltre 5.000 strumenti, e molte aziende costruiscono un unico server interno che raccoglie tutti i loro sistemi. Un vantaggio poco citato: le regole aziendali stanno nel server e non nelle istruzioni al modello, per esempio "si possono riavviare i servizi di prova solo dopo le 18". (TechWorld with Nana)

Un caso reale: Uber. Uber ha raccontato al MCP Dev Summit 2026 come usa MCP in produzione (AAIF):

Per reggere questi numeri hanno costruito un gateway con un registro centrale: i servizi interni diventano strumenti MCP in automatico, con descrizioni scritte dall'AI e poi corrette da chi conosce il servizio. I server esterni passano controlli più severi di quelli interni, i dati personali vengono oscurati in automatico e le chiamate che modificano sistemi critici si possono bloccare. Per rendere gli agenti affidabili, chi li configura può fissare in anticipo quali strumenti e quali parametri usare, invece di lasciar decidere il modello.

Dove trovare i server MCP e come sceglierli

I server sono migliaia: a metà 2026 se ne contavano oltre 10.000 in produzione, e le directory pubbliche ne elencano quasi altrettanti. Il difficile non è trovarli, è scegliere quelli affidabili.

Prima di installarne uno:

• è il server ufficiale del servizio, o di chi lo pubblica?
• è mantenuto (aggiornamenti recenti, problemi risolti)?
• chiede solo i permessi che servono davvero?
• le azioni che non si possono annullare chiedono conferma?
• il nome del pacchetto è esatto, senza lettere scambiate (i pacchetti falsi imitano quelli veri)?

Le guide ufficiali per costruire un server MCP

Ogni piattaforma ha la sua guida per collegare o costruire un server MCP, e cambiano spesso: nomi dei menu, trasporti supportati, requisiti. Le controlliamo ogni giorno: quando una guida ufficiale cambia, la sua riga qui sotto si aggiorna da sola.

Storia e governance: da Anthropic alla Linux Foundation

In meno di due anni MCP è passato da progetto di un'azienda a standard neutrale, sostenuto anche dai concorrenti diretti di chi l'ha creato.

La fondazione dà una casa neutrale, la stessa di Kubernetes, Node.js e PyTorch; le decisioni tecniche restano ai manutentori del protocollo, con proposte pubbliche discusse dalla comunità.

Quanto è diffuso. Ad aprile 2026 il co-creatore ha parlato di 110 milioni di download al mese degli SDK, contati anche dentro strumenti di altri, come gli SDK per agenti di OpenAI e Google che usano MCP come dipendenza. Il suo paragone: React ha impiegato circa il doppio del tempo per arrivare agli stessi volumi. Aggiunge che la maggior parte dei server non è pubblica: collega sistemi interni delle aziende agli agenti. (David Soria Parra, The Future of MCP)

Cosa arriva. Tra le direzioni annunciate: la scoperta automatica dei server su indirizzi standard di un sito, così un agente che visita un sito trova da solo il suo server MCP; le skill distribuite dai server stessi insieme ai loro strumenti; l'accesso unico aziendale descritto nella sezione sull'autenticazione.

Cosa cambia con la specifica del 28 luglio 2026

La versione 2026-07-28 è la più grande dal lancio: MCP diventa senza stato (stateless), e ogni richiesta viaggia da sola come una normale chiamata web. Se leggi una guida scritta prima di agosto 2026, alcune parti non valgono più.

Le versioni precedenti restano supportate: gli SDK principali (TypeScript, Python, Go, C#) leggono sia il vecchio sia il nuovo formato, quindi i server esistenti non smettono di funzionare da un giorno all'altro.

Perché "senza stato" conta, con un esempio. Prima, il server creava una sessione alla prima richiesta. Con tre copie dello stesso server dietro un bilanciatore, la richiesta successiva poteva finire su una copia che quella sessione non l'aveva mai vista: errore "sessione non trovata". Le soluzioni erano scomode (instradare sempre lo stesso utente sulla stessa copia, oppure un database solo per le sessioni). Ora qualsiasi copia risponde a qualsiasi richiesta, e un server può spegnersi quando nessuno lo usa su piattaforme come Cloudflare Workers o Google Cloud Run, costando meno. (Better Stack)

Altre novità con un effetto pratico:

• Intestazioni HTTP leggibili (Mcp-Method, Mcp-Name): un firewall o un limitatore di traffico capiscono cosa si sta chiedendo senza leggere il contenuto.
• Lo stato, se serve, lo gestisce lo strumento: per esempio restituisce un identificativo del carrello, e il modello lo ripassa alle chiamate successive come un normale parametro.
• Niente domande dal nulla: prima il server poteva mandare una richiesta all'utente in qualsiasi momento. Ora risponde "mi serve questo dato" (input required) con tutto il contesto per riprendere, il client lo chiede all'utente e ripete la richiesta. Più chiaro per chi usa l'app, e più sicuro.
• Lavori lunghi: un rimborso o un'elaborazione di ore diventano un'attività (task) che il client controlla quando vuole, senza tenere ferma la conversazione.
• Tempo per adeguarsi: le funzioni dismesse restano supportate per almeno 12 mesi, e gli SDK principali sono passati alla versione 2.

Attenzione alle guide recenti. Anche video pubblicati a settembre 2026 descrivono ancora MCP come un protocollo con sessioni: prima di seguire un tutorial, controlla quale versione della specifica usa.

Sicurezza: i rischi reali

Un server MCP trasforma un testo in un'azione vera, quindi la sua sicurezza dipende da come è costruito, non solo dal protocollo. Nei primi 60 giorni del 2026 sono state registrate oltre 30 vulnerabilità ufficiali (CVE) su server MCP, il 43% delle quali permetteva di far eseguire comandi.

Le regole pratiche, per chi usa un server:

• solo server ufficiali o di editori verificati
• conferma obbligatoria per cancellazioni, pagamenti, invii
• permessi minimi, e un modo rapido per revocarli
• mai collegare insieme, senza controllo, un server che legge dati esterni (email, web) e uno che fa azioni importanti

Da dove entra un attacco: tre porte. Un ricercatore di CyberArk ha raccontato a Nullcon Berlin come un semplice server meteo gli ha fatto uscire la chiave di GitHub, e ha individuato i tre punti da cui il testo di un server arriva al modello (Nullcon):

1. La descrizione dello strumento. Viene aggiunta a ogni messaggio, quindi l'attacco può scattare anche senza usare lo strumento: nella sua dimostrazione bastava scrivere "grazie".
2. Lo schema dei parametri. Anche il nome di un parametro o il campo title possono contenere istruzioni.
3. Il risultato dello strumento. Il caso reale: il server era onesto, ma l'API meteo esterna che interrogava restituiva un messaggio d'errore con istruzioni nascoste. Chi usa un server si fida anche dei servizi che il server chiama.

Le difese che propone: leggere le descrizioni prima di installare, risultati tipizzati (un server meteo restituisca un numero, non un testo libero), marcare i risultati come dati e non come istruzioni, e un piccolo modello che li controlla.

Perché non si può risolvere alla radice. La SQL injection si risolve dal 1998 separando istruzioni e dati. Un modello di linguaggio invece legge tutto come un unico testo: non ha un modo strutturale per distinguere l'ordine dell'utente da una frase dentro un'email. Per questo la difesa non è "impedire l'inganno" ma limitare cosa può fare l'agente se viene ingannato. Il caso documentato: un'automazione di Google che usava l'AI per smistare le segnalazioni su GitHub pubblicava le proprie chiavi segrete se qualcuno scriveva le istruzioni giuste dentro una segnalazione. Lo stesso difetto c'era in altre cinque aziende Fortune 500. La correzione: all'AI che legge testo non fidato, niente chiavi e niente strumenti che modificano. (NDC Conferences)

MCP a confronto

MCP non sostituisce le API e non fa tutto: è lo strato che le rende usabili da un'intelligenza artificiale.

MCP e API non sono rivali, sono strati. Spesso un server MCP è proprio un involucro attorno a un'API: il server di GitHub traduce ogni strumento in una chiamata all'API REST di GitHub. Le differenze vere sono due: MCP permette di scoprire le capacità mentre gira (il client chiede "cosa sai fare?" e si adatta, senza aggiornare il codice), e ogni server parla allo stesso modo, mentre cinque API richiedono cinque adattatori diversi. (IBM Technology) Un'immagine efficace: l'API è il menù stampato del ristorante, MCP è il cameriere che ti dice cosa c'è oggi, anche il piatto aggiunto dallo chef un minuto fa. (TechWorld with Nana)

Due avvertenze che chiariscono le aspettative:

• MCP non dà più poteri dell'API. Se l'API di un servizio permette solo di leggere, anche il suo server MCP potrà solo leggere.
• Tradurre un'API pari pari non basta. Il co-creatore lo dice senza giri di parole: trasformare ogni chiamata REST in uno strumento MCP produce server scomodi per il modello. Un buon server si progetta per l'agente, pensando a come lo userebbe una persona.

Quando serve davvero MCP. Secondo il co-creatore non esiste una soluzione unica: un agente del 2026 usa insieme skill (le istruzioni di dominio), riga di comando, computer use e MCP. La riga di comando funziona bene per un agente locale con strumenti già noti al modello, come Git. MCP serve quando servono interfacce, attività lunghe, risorse, indipendenza dalla piattaforma, autorizzazioni e regole aziendali. (David Soria Parra, The Future of MCP)

Approfondimenti

• Claude Computer Use o MCP: quale usare
• ChatGPT e MCP su Windows: come collegare il PC
• Controllare il PC con Claude: tutte le strade
• Controllare il PC dal telefono con l'AI: 4 modi
• Installare MCP su Windows: 4 metodi, dal più facile
• Claude Desktop e MCP remoto: connettori ed estensioni
• Server MCP su Windows: tutte le opzioni a confronto

Domande frequenti

Cosa vuol dire MCP?

Model Context Protocol: un protocollo, cioè un insieme di regole comuni, per dare ai modelli di AI il contesto e gli strumenti di cui hanno bisogno.

MCP è di Anthropic?

L'ha creato Anthropic nel novembre 2024, ma da dicembre 2025 appartiene all'Agentic AI Foundation della Linux Foundation, con OpenAI, Google, Microsoft e AWS tra i sostenitori.

Serve saper programmare per usare un server MCP?

Per usarlo no: si aggiunge da un menu o con un clic. Per costruirne uno sì, con gli SDK ufficiali in TypeScript, Python, Go, C# e altri linguaggi.

MCP è gratis?

Il protocollo è aperto e gratuito. I singoli server possono essere gratuiti, open source o a pagamento.

Che differenza c'è tra un server MCP e un connettore?

È la stessa cosa vista da due lati: "server" è il programma, "connettore" è il nome che Claude e ChatGPT danno al collegamento con quel server.

MCP funziona con modelli diversi da Claude?

Sì: ChatGPT, Gemini, Copilot, Cursor, VS Code e decine di altri client lo supportano.

È sicuro?

Quanto il server che usi: con server ufficiali, permessi minimi e conferma sulle azioni importanti sì; un server qualsiasi trovato online può essere pericoloso.

Dove si colloca MCP DeskManager

MCP DeskManager è un server MCP per Windows che fa del tuo PC uno strumento dell'assistente: terminale, file, browser e programmi, usabili da Claude o ChatGPT da qualsiasi chat, anche dal telefono. Gira sul tuo computer ma è raggiungibile da remoto attraverso un tunnel cifrato con autenticazione, una chiave separata per ogni assistente e la conferma per le operazioni che non si possono annullare.

Ha senso se vuoi usare il tuo PC da ovunque senza configurare porte, certificati e accessi a mano. Se ti basta lavorare seduto al computer con Claude Desktop, un'estensione locale gratuita può essere sufficiente.