Server MCP per agenti AI: guida pratica 2026

Se hai mai provato a far fare a un agente AI un lavoro vero - rispondere a un'email cliente, aprire un ticket Jira, eseguire una query SQL - hai sbattuto contro lo stesso muro. Il modello può ragionare sul compito tutto il giorno, ma finché non riesce a parlare ai tuoi strumenti non lo finisce. È questo il gap che chiude un server MCP, e a metà 2026 il registro del Model Context Protocol elenca oltre 6.400 server, con più di 97 milioni di download di SDK al mese. Questa guida spiega cos'è davvero un server MCP, come si collega a un agente AI e come scegliere quelli che vale la pena usare.

Cos'è davvero un server MCP

MCP sta per Model Context Protocol, uno standard aperto proposto originariamente da Anthropic e oggi supportato da tutti i grandi fornitori di modelli: Anthropic, OpenAI, Google, Microsoft, AWS. Viene spesso descritto come "USB-C per gli agenti AI" perché definisce un modo universale per collegare un modello a uno strumento o a una fonte dati esterna, così non devi riscrivere un'integrazione ogni volta che cambia lo strumento o il modello.

Un server MCP è qualsiasi processo che parla questo protocollo ed espone capacità a un agente. Può vivere sul tuo laptop e incapsulare il filesystem locale, oppure essere un servizio hostato che parla con Salesforce. Sotto il cofano il trasporto è JSON-RPC 2.0, quindi un server può essere piccolo come uno script Python o sostanzioso come un gateway API in produzione.

Un server espone tre tipi di capacità:

Tools - funzioni eseguibili che l'agente può chiamare. get_repo_issues(owner, repo), run_sql(query), send_email(to, subject, body).
Resources - dati strutturati in sola lettura che il modello può portare come contesto. Un file, una riga di database, un documento.
Prompts - template di istruzioni riutilizzabili che il server offre all'agente per compiti comuni.

Un client MCP è la controparte che vive nel runtime del tuo agente e parla al server. Un singolo host, ad esempio un processo agente, può aprire molte sessioni client in parallelo, ognuna collegata a un server diverso, ognuna con stato proprio e isolata dalle altre.

Perché il protocollo conta

Prima di MCP ogni framework di agenti aveva il suo catalogo di strumenti. LangChain aveva LangChainToolkit, LlamaIndex aveva Tool, OpenAI aveva gli schemi di function calling, e nessuno era intercambiabile. Se il tuo team cambiava framework, il codice degli strumenti non veniva dietro.

MCP ribalta questo modello. Il server è definito dal protocollo, non dal framework. Un server MCP per PostgreSQL scritto una volta funziona con Claude Desktop, ChatGPT, Cursor, un runtime locale di Llama o qualsiasi agente custom, senza modifiche. Il risultato dell'ultimo anno è un'esplosione cambriana di server: filesystem, Git, GitHub, Postgres, SQLite, Notion, Slack, Google Drive, Playwright, Puppeteer, Kubernetes, Stripe e migliaia di altri. Il registro ufficiale di MCP è l'indice canonico, e liste curate come awesome-mcp-servers filtrano opzioni mantenute e pronte per la produzione.

Per i team che costruiscono agenti AI conta per tre motivi:

Riuso. Un server scritto per un progetto serve anche per il prossimo.
Portabilità del modello. Passare da Claude a GPT-5 non ti costringe a riscrivere ogni integrazione.
Isolamento. Poiché gli strumenti vivono in un processo separato, puoi imporre permessi, rate limit e audit al confine del server invece che dentro l'agente.

Come un agente si collega a un server MCP

Il ciclo di vita della connessione è breve. L'agente avvia un client MCP, che fa handshake con il server, chiede quali capacità espone e tiene aperto un canale con stato per le chiamate agli strumenti e la lettura delle risorse.

Ecco come appare in pratica con una configurazione minima:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/app"]
    }
  }
}

Questa configurazione ha esattamente la forma che accettano Claude Desktop, Claude Code, Cursor e una lista crescente di altri host. Ogni voce del server diventa una sessione client al boot. L'agente vede poi una lista unificata di strumenti (read_file, list_directory, query) e può chiamarne uno qualsiasi a metà conversazione.

Se stai scrivendo un agente custom, il pattern è lo stesso. Scegli un SDK MCP per il tuo linguaggio (@modelcontextprotocol/sdk per TypeScript, mcp per Python), apri una sessione client per server e lascia che il modello scelga gli strumenti dal catalogo unificato. L'SDK gestisce il framing JSON-RPC così non tocchi mai i socket grezzi.

Come scegliere quali server collegare

La tentazione, appena vedi il registro, è di collegare venti server e lasciar scegliere all'agente. Non farlo. Due regole pratiche tengono un agente focalizzato:

Una capacità per problema. Se il lavoro dell'agente è "rispondere a domande dalla nostra knowledge base", ti serve quel server e probabilmente niente altro. Strumenti in più gonfiano il contesto del modello e aumentano la probabilità di una scelta sbagliata.
Leggi con attenzione lo scope del server. Un server MCP di GitHub in grado di creare e cancellare repository è un modello di minaccia molto diverso da uno che elenca soltanto le issue. Spesso i server espongono un sottoinsieme "sicuro" con una flag o una credenziale ristretta; usalo.

Le tre categorie in cui quasi ogni agente reale finisce sono:

Categoria	Server d'esempio
Contesto locale	Filesystem, Git
Sistema di team	GitHub, Jira, Linear, Notion, Slack
Dati e ricerca	Postgres, SQLite, un vector store, un server di ricerca web

Parti da qui. Espandi dopo, quando avrai un compito preciso che richiede una capacità precisa in più.

Se stai ancora decidendo se un agente è la forma giusta per il problema, Agente AI vs chatbot racconta la differenza di architettura e vale la pena leggerlo prima di passare una settimana a cablare server in qualcosa che non ne aveva mai avuto bisogno.

Far girare server MCP senza possedere l'infrastruttura

Hai tre opzioni ampie per far girare server MCP in produzione:

Self-hosted, per sviluppatore. Ogni ingegnere esegue i server sul proprio laptop, collegati al Claude Desktop o Cursor locale. È lì che iniziano quasi tutti i team. È gratis, ma ogni sviluppatore mantiene il suo stack.
Self-hosted, condiviso. Un VPS o un cluster Kubernetes ospita i server e ogni client d'agente si collega via rete. Più pulito, ma ora hai una piccola superficie ops: TLS, autenticazione, upgrade, monitoring.
Agente gestito con MCP gestito. Un servizio d'agente hostato porta il proprio runtime MCP-nativo e ti permette di collegare server da un catalogo o dalla tua lista. Resti proprietario dei server che indichi, ma il ciclo di vita dell'agente non è un tuo problema.

La scelta giusta dipende da quanto stack vuoi davvero gestire. Se il tuo obiettivo è "un agente personale sempre attivo che legga i miei file, controlli il mio calendario e aggiorni una board di progetto", l'opzione 3 è di solito la strada più veloce.

Hermify è un modo gestito di eseguire Hermes Agent come AI personale su Telegram. Hermes Agent è MCP-nativo di serie, quindi tutto ciò che riesci a incapsulare in un server MCP, il tuo agente può usarlo. Tu porti i server, Hermify fa girare l'agente e i file di memoria restano tuoi. Inizia con Hermify se vuoi un agente attivo prima ancora di finire di leggere il resto della documentazione dell'ecosistema.

Errori comuni

Tre modalità di fallimento ricorrono di continuo nei deploy reali:

Credenziali con scope troppo ampio. Un server MCP che eredita il tuo PAT personale dà all'agente tutto ciò che puoi fare tu. Riduci lo scope dei token e preferisci server che supportino credenziali granulari.
Server che espongono troppi strumenti. Un server con 60 strumenti può spingere il modello oltre la finestra d'attenzione utile. Cerca server che permettano la allowlist di un sottoinsieme, oppure scrivi un server wrapper sottile che riesponga solo ciò che serve al tuo agente.
Dimenticarsi della rete. I server locali girano in-process; quelli hostati no. Latenza, retry e gestione degli errori cambiano appena una chiamata diventa un round trip HTTPS. Tienine conto nel design del prompt dell'agente.

Per una vista più specifica su Hermes di come i server MCP si agganciano al runtime dell'agente, vedi Hermes Agent e MCP: un solo protocollo per ogni strumento.

Cosa fare adesso

Scorri il registro ufficiale di MCP e identifica i due o tre server che rispecchiano il lavoro concreto che vuoi far fare al tuo agente.
Collegali a un host di cui ti fidi già (Claude Desktop o Cursor sono la prova locale più rapida).
Quando il workflow sembra solido, decidi se continuare a farlo girare sul laptop o promuoverlo a un agente gestito.

MCP non sarà l'ultimo standard di integrazione di cui gli agenti AI avranno bisogno, ma è quello che finalmente disaccoppia il codice degli strumenti dalla scelta del framework. I team che lo trattano come infrastruttura adesso, mentre il registro è ancora gestibile, si risparmiano la stessa riscrittura di integrazioni che tutti gli altri saranno costretti a rifare una seconda volta.