Model Context Protocol (MCP)

Executive summary

Quando un sistema di intelligenza artificiale deve interagire con strumenti esterni, interrogare un database, leggere un documento, inviare un'email, ha bisogno di un linguaggio comune per comunicare con ciascuno di essi. Senza uno standard condiviso, ogni combinazione di sistema intelligente e strumento richiede un collegamento costruito su misura, moltiplicando i costi di sviluppo e manutenzione. Questo articolo analizza il protocollo aperto che si è affermato come riferimento per risolvere questo problema, esaminandone l'architettura interna, l'ecosistema di adozione, le vulnerabilità di sicurezza documentate e i limiti strutturali che ne condizionano l'uso in produzione. Dall'analisi emerge un protocollo con un'adozione straordinariamente rapida e un supporto industriale trasversale, ma con criticità concrete, in particolare sul consumo di risorse e sulla sicurezza, che richiedono attenzione progettuale specifica.

Background: il problema N×M dell'integrazione strumenti

L'utilità pratica di un agente AI dipende dalla sua capacità di interagire con il mondo esterno: leggere dati da database, invocare API, manipolare file, eseguire query su sistemi gestionali. Senza uno standard di comunicazione, ogni combinazione di client AI (Claude, ChatGPT, Cursor, un agente custom) e strumento esterno richiede un'integrazione dedicata. Con $N$ client e $M$ strumenti, il numero di integrazioni necessarie scala come $N \times M$, un problema combinatorio che rende insostenibile la costruzione di ecosistemi interoperabili [1].

Il Model Context Protocol (MCP) è stato rilasciato da Anthropic nel novembre 2024 [1] come protocollo aperto per risolvere questo problema, riducendo la complessità da $N \times M$ a $N + M$: ogni client implementa un client MCP, ogni strumento espone un server MCP, e l'interoperabilità è garantita dal protocollo. L'adozione è stata rapida e trasversale: nel marzo 2025 OpenAI ha integrato MCP nel proprio Agents SDK e nella Responses API [2]; Google ha aggiunto il supporto nel proprio Agent Development Kit [3]; e a dicembre 2025 Anthropic ha donato MCP alla Agentic AI Foundation (AAIF) sotto la Linux Foundation, con Anthropic, OpenAI, Google, Microsoft e Amazon come membri platinum [4].

I numeri di adozione ad aprile 2026, secondo le stime aggregate disponibili [5], sono significativi: oltre 97 milioni di download mensili degli SDK (Python e TypeScript combinati, dato verificabile dalle statistiche npm e PyPI), più di 10.000 server MCP pubblicati e oltre 300 client compatibili. Il protocollo è supportato nativamente da Claude Desktop, ChatGPT Desktop, VS Code Copilot, Cursor, Windsurf, JetBrains IDE, Zed Editor e Google Gemini [5]. Tuttavia, come l'analisi che segue dimostrerà, la velocità di adozione ha preceduto la maturazione di aspetti critici, sicurezza, scalabilità e governance, che condizionano il deployment in ambienti enterprise.

Architettura del protocollo

Modello a tre ruoli

L'architettura MCP definisce tre ruoli distinti [6]:

• Host: l'applicazione che l'utente interagisce direttamente (es. Claude Desktop, un IDE, un'applicazione custom). L'host crea e gestisce i client MCP.
• Client: il componente che mantiene una connessione 1:1 con un server MCP. Un host può istanziare più client, ciascuno connesso a un server diverso.
• Server: il processo che espone strumenti, risorse e prompt tramite il protocollo MCP.

Questa separazione consente a un singolo host di connettersi simultaneamente a più server, un database PostgreSQL, un'API REST, un file system locale, attraverso client dedicati, mantenendo isolamento tra le connessioni.

Wire format e trasporto

MCP utilizza JSON-RPC 2.0 come formato dei messaggi [6]. Ogni messaggio, richiesta, risposta, notifica, segue la semantica JSON-RPC standard, con campi method, params, result e error. Le connessioni sono stateful: il protocollo prevede un ciclo di vita esplicito con inizializzazione, operazione e chiusura.

La scelta di JSON-RPC 2.0 come formato dei messaggi ha implicazioni architetturali rilevanti: da un lato, garantisce leggibilità, debuggabilità e compatibilità con qualsiasi linguaggio; dall'altro, il formato testuale contribuisce al problema di consumo della finestra di contesto discusso nella sezione sui limiti, le definizioni dei tool, serializzate come JSON Schema, occupano 550-1.400 token ciascuna. Un formato binario (protobuf, Cap'n Proto) ridurrebbe il payload ma sacrificherebbe la trasparenza che ha facilitato l'adozione rapida del protocollo.

Due trasporti sono definiti nella specifica [6]:

Il trasporto HTTP+SSE originario è stato deprecato nella specifica del giugno 2025 in favore di Streamable HTTP, che supporta sia interazioni request-response sia streaming in un unico endpoint [6].

Handshake di inizializzazione

La connessione segue un handshake a tre fasi rigorosamente ordinato [6]:

1. Il client invia una richiesta initialize dichiarando la versione del protocollo e le proprie capabilities
2. Il server risponde con la propria versione e le capabilities supportate (quali primitive espone)
3. Il client invia una notifica notifications/initialized segnalando la disponibilità operativa

Se le versioni non sono compatibili, la connessione viene terminata. Questo meccanismo garantisce che la configurazione sia bloccata prima dell'inizio della logica applicativa. Un limite di questo design è l'assenza di rinegoziazione: se un server aggiunge tool dinamicamente, il client deve riconnettersi per scoprirli, un vincolo rilevante per server con cataloghi di tool variabili.

Primitive: Tools, Resources, Prompts

I server MCP dichiarano supporto per tre primitive durante la negoziazione delle capabilities [6]:

Tools sono funzioni eseguibili che l'agente AI può invocare: eseguire una query SQL, inviare un'email, creare un record nel CRM. Ogni tool è descritto da un nome, una descrizione in linguaggio naturale e uno schema JSON dei parametri. La descrizione è critica perché il LLM la utilizza per decidere quando e come invocare il tool.

Resources sono sorgenti di dati che forniscono contesto: contenuti di file, schemi di database, documentazione. A differenza dei tool, le resource sono read-only e non producono side-effect.

Prompts sono template riutilizzabili che strutturano l'interazione con il LLM, consentendo ai server di esporre pattern di utilizzo predefiniti.

Ecosistema: SDK, server e adozione

SDK ufficiali

Il progetto MCP mantiene SDK ufficiali per cinque linguaggi sotto l'organizzazione GitHub modelcontextprotocol [7]:

L'SDK TypeScript funge da implementazione di riferimento per il comportamento del protocollo [7]. Gli SDK forniscono sia primitive di basso livello per la gestione del protocollo sia astrazioni di alto livello per la costruzione di server e client.

Ecosystem di server

Il repository ufficiale modelcontextprotocol/servers [8] contiene implementazioni di riferimento per filesystem, GitHub, GitLab, Google Drive, PostgreSQL, Slack, Puppeteer e altri. L'ecosistema complessivo supera i 10.000 server, con copertura estesa su database, API cloud, strumenti di sviluppo e servizi aziendali [5].

Un benchmark indipendente su 3,9 milioni di richieste con metodologia pubblicata [9] indica che server implementati in Java e Go raggiungono il throughput più elevato con variabilità minima (0,5-0,7%), mentre Python si attesta al 18% del tier ad alte prestazioni. Questi risultati, sebbene coerenti con le aspettative sui runtime, richiedono validazione indipendente prima di orientare decisioni architetturali in produzione.

Governance: da Anthropic alla Linux Foundation

La donazione di MCP alla AAIF nel dicembre 2025 [4] ha trasformato il progetto da iniziativa single-vendor a standard governato da una fondazione multi-stakeholder. I singoli progetti mantengono autonomia tecnica completa; il Governing Board gestisce investimenti strategici, budget e reclutamento di nuovi membri. Accanto a MCP, la AAIF ospita anche A2A (Google, per la comunicazione agente-agente), goose (Block) e AGENTS.md (OpenAI) [4].

La specifica utilizza un versionamento date-based (YYYY-MM-DD) con rilasci trimestrali [6]. Le versioni principali hanno introdotto progressivamente: Streamable HTTP (giugno 2025), OAuth 2.1 (giugno 2025), output strutturato dei tool e interazioni server-initiated (giugno 2025), e tool calling nei sampling request e loop agentici lato server (novembre 2025) [10].

Sicurezza: superficie d'attacco e mitigazioni

La sicurezza è l'area più critica e meno matura del protocollo. La survey di Hou et al. [11], pubblicata su ACM TOSEM, analizza l'intero ciclo di vita dei server MCP (creazione, deployment, operazione, manutenzione) identificando rischi di sicurezza in ciascuna fase. L'analisi che segue sintetizza le vulnerabilità più rilevanti documentate.

Prompt injection via tool response

Le risposte dei tool MCP entrano direttamente nel contesto del LLM come testo non privilegiato. Un attaccante può inserire istruzioni malevole nei dati restituiti da un tool, ad esempio, risultati di una query che contengono comandi nascosti diretti al modello. Questo vettore è strutturalmente difficile da eliminare nell'architettura attuale perché il LLM non distingue tra dati e istruzioni nel proprio contesto [12]. La prompt injection è classificata come il rischio #1 nella OWASP Top 10 for LLM Applications [21], e l'architettura MCP la amplifica fornendo un canale strutturato attraverso cui dati non fidati raggiungono il contesto del modello.

Tool poisoning e cross-server shadowing

Un server MCP malevolo può registrare tool con nomi che mascherano tool legittimi di altri server connessi allo stesso agent, intercettando invocazioni e dati. Invariant Labs ha dimostrato un attacco in cui un server MCP malevolo ha esfiltrato l'intera cronologia WhatsApp di un utente combinando tool poisoning con un server whatsapp-mcp legittimo nella stessa sessione [22]. Questo tipo di attacco è particolarmente insidioso perché l'utente vede solo i tool legittimi nel proprio agent, mentre il server malevolo opera in modo trasparente.

Remote Code Execution: CVE-2025-6514

JFrog ha scoperto una vulnerabilità critica (CVSS 9.6/10) nel pacchetto mcp-remote (437.000+ download): un server MCP malevolo poteva inviare un URL authorization_endpoint che veniva eseguito come comando shell sulla macchina del client [14]. Questa è la prima RCE documentata contro un client MCP, e dimostra che la supply chain dei server MCP è una superficie d'attacco concreta.

Modello di autorizzazione

La specifica include un framework di autorizzazione basato su OAuth 2.1 con PKCE, introdotto nella revisione di giugno 2025 [6, 15]. Questo framework è applicabile ai server remoti su Streamable HTTP; per i server locali su stdio, la sicurezza dipende dai controlli di accesso del sistema operativo. La specifica raccomanda esplicitamente: "There should always be a human in the loop with the ability to deny tool invocations" [15], una raccomandazione che gli esperti di sicurezza suggeriscono di trattare come requisito mandatorio, non opzionale.

Mitigazioni pratiche

Per deployment in produzione, le mitigazioni raccomandate includono: gateway MCP centralizzati per autenticazione, audit trail e rate limiting; isolamento dei server MCP in container con permessi minimi; validazione degli output dei tool prima dell'iniezione nel contesto del LLM; e human-in-the-loop per operazioni con side-effect [13, 15].

Limiti e problemi aperti

Consumo della finestra di contesto

Il limite operativamente più significativo nel 2026 è il consumo di token da parte delle definizioni dei tool. Ogni tool MCP costa 550-1.400 token (nome, descrizione, schema JSON, istruzioni) [16]. In deployment tipici, il 40-50% della finestra di contesto viene consumato dai metadati dei tool prima dell'inizio della conversazione. Un caso documentato riporta 3 server MCP che consumano 143.000 token su una finestra da 200.000, lasciando solo il 28% per il contenuto effettivo [16]. Il CTO di Perplexity ha annunciato nel marzo 2026 l'abbandono di MCP in favore di API tradizionali e tool CLI per questa ragione [16]. Anthropic ha risposto pubblicando un approccio basato su code execution che riduce il consumo di token del 98% rispetto alle definizioni MCP tradizionali [17], ma questa soluzione richiede supporto esplicito dal client.

Discovery e registry

Non esiste ancora un meccanismo standardizzato per la scoperta automatica dei server MCP. Le proposte di Server Cards (/.well-known/mcp.json) sono in fase di review ma non ancora integrate nella specifica core [18]. Senza discovery, la connessione a un server MCP richiede configurazione manuale, un ostacolo significativo per l'adozione enterprise su larga scala.

Scalabilità orizzontale

Le connessioni MCP sono stateful, ma il deployment enterprise richiede operazione stateless per il bilanciamento del carico e la scalabilità orizzontale. La roadmap 2026 del protocollo identifica esplicitamente la scalabilità del trasporto, i pattern gateway/proxy e la portabilità della configurazione come priorità [18], ma le soluzioni standardizzate non sono ancora disponibili.

Tassonomia dei fault

Uno studio su 419 issue etichettate nelle implementazioni MCP [19] identifica cinque categorie di fault: configurazione server/tool (31,7%), configurazione server/host (28,6%), impostazione server (27,5%), documentazione (6,9%) e bug di programmazione generica (5,3%). La scoperta e registrazione dei tool è stata valutata come il problema più critico dai 41 professionisti intervistati, mentre l'autenticazione dei tool risulta il più oneroso da risolvere [19].

Overhead di protocollo

L'overhead di latenza introdotto dal protocollo MCP dipende dal trasporto. Su stdio, il costo è trascurabile (comunicazione inter-processo locale). Su Streamable HTTP, il gateway MCP Bifrost riporta un overhead sub-3ms per richiesta [9], compatibile con la maggior parte dei requisiti di latenza. Il collo di bottiglia reale non è il protocollo ma il LLM stesso: una singola invocazione di tool richiede almeno un round-trip di inferenza (decisione di invocare il tool) più il tempo di esecuzione del tool più un secondo round-trip di inferenza (elaborazione del risultato). In questo contesto, l'overhead del protocollo è marginale rispetto alla latenza end-to-end. Non esistono tuttavia benchmark standardizzati per il confronto sistematico tra MCP e alternative su scenari equivalenti, un'area dove la comunità dovrebbe investire.

Confronto con le alternative

MCP si posiziona in uno spettro di soluzioni per l'integrazione di tool con agenti AI. Le function calling API di OpenAI/Anthropic/Google sono più semplici da implementare per scenari single-provider con pochi tool, ma non offrono portabilità cross-client né discovery dinamica. OpenAPI/Swagger eccelle per ecosistemi HTTP con governance API matura, ma non supporta comunicazione bidirezionale né streaming. A2A (Google) è esplicitamente complementare a MCP: gestisce la comunicazione agente-agente mentre MCP gestisce la comunicazione agente-strumento; entrambi sono ora sotto la AAIF [4, 20].

Un pattern emergente è la generazione automatica di server MCP a partire da specifiche OpenAPI esistenti, consentendo di esporre un'intera API REST come set di tool MCP senza riscrittura. Questo approccio combina i vantaggi di governance e documentazione di OpenAPI con la portabilità cross-client di MCP, al costo di un layer aggiuntivo.

La scelta tra queste opzioni dipende dal contesto: per integrazioni che devono funzionare su più client AI e sopravvivere al cambio di provider, MCP è l'opzione con il maggior supporto industriale. Per integrazioni tight-loop con latenza critica e un singolo provider, le function calling API native restano più efficienti, e consumano significativamente meno token, poiché le definizioni dei tool sono ottimizzate per il formato nativo del provider.

Riferimenti

[1] Anthropic, "Introducing the Model Context Protocol," novembre 2024. https://www.anthropic.com/news/model-context-protocol

[2] OpenAI, "New Tools for Building Agents," marzo 2025. https://openai.com/index/new-tools-for-building-agents/

[3] Google, "Agent Development Kit (ADK)," 2025. https://google.github.io/adk-docs/

[4] Linux Foundation, "Linux Foundation Announces the Formation of the Agentic AI Foundation," dicembre 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation

[5] Pento AI, "A Year of MCP: 2025 Review," 2025. https://www.pento.ai/blog/a-year-of-mcp-2025-review

[6] Model Context Protocol, "Specification and Architecture," 2024-2025. https://modelcontextprotocol.io/specification

[7] Model Context Protocol, "Official SDKs," GitHub Organization, 2024-2026. https://github.com/modelcontextprotocol

[8] Model Context Protocol, "Reference MCP Servers," GitHub, 2024-2026. https://github.com/modelcontextprotocol/servers

[9] TM Dev Lab, "MCP Server Performance Benchmark: Multi-Language Analysis," 2026. https://www.tmdevlab.com/mcp-server-performance-benchmark.html

[10] Model Context Protocol Blog, "MCP First Anniversary Release," novembre 2025. https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/

[11] Y. Hou et al., "Security Analysis of Model Context Protocol Server Lifecycle," ACM Transactions on Software Engineering and Methodology, 2025. https://dl.acm.org/doi/10.1145/3796519

[12] S. Willison, "MCP Prompt Injection," aprile 2025. https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/

[13] Red Hat, "Model Context Protocol (MCP): Understanding Security Risks and Controls," 2025. https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls

[14] JFrog, "CVE-2025-6514: Critical MCP-Remote RCE Vulnerability," 2025. https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/

[15] Model Context Protocol, "Security Best Practices," 2025. https://modelcontextprotocol.io/specification/draft/basic/security_best_practices

[16] Apideck, "Your MCP Server Is Eating Your Context Window," 2026. https://www.apideck.com/blog/mcp-server-eating-context-window-cli-alternative

[17] Anthropic Engineering, "Code Execution with MCP," 2026. https://www.anthropic.com/engineering/code-execution-with-mcp

[18] Model Context Protocol, "2026 Roadmap," 2026. https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/

[19] "Real Faults in MCP Software: A Taxonomy," arXiv:2603.05637, 2026. https://arxiv.org/html/2603.05637v1

[20] Google, "Announcing the Agent2Agent Protocol (A2A)," Google Developers Blog, 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

[21] OWASP, "OWASP Top 10 for LLM Applications," 2025. https://genai.owasp.org/llm-top-10/

[22] Invariant Labs, "MCP Security Notification: Tool Poisoning Attacks," 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks