Cos'è l'MCP e perché il tuo SaaS ha bisogno di un server MCP nel 2026

Un server Model Context Protocol (MCP) è un endpoint standardizzato che espone tool, dati e azioni del tuo SaaS agli agenti AI attraverso un unico protocollo basato su JSON-RPC 2.0. È il ponte che permette a Claude, ChatGPT, Cursor, VS Code, Copilot Studio e a qualsiasi altro client compatibile di invocare il tuo prodotto senza un'integrazione custom per ogni client.

Nel 2026 l'MCP non è più una curiosità di ricerca. Anthropic ha introdotto il protocollo a novembre 2024, ha raggiunto 97 milioni di download SDK mensili entro dicembre 2025 e nello stesso mese ha ceduto la governance alla Agentic AI Foundation sotto la Linux Foundation, co-fondata con Block e OpenAI. Se il tuo SaaS ha endpoint che vale la pena chiamare da un agente AI, la domanda nel 2026 non è se ti serve un server MCP, ma quanto presto puoi spedirne uno che regga traffico reale.

La versione da trenta secondi

Le API REST sono state pensate per chiamanti deterministici: app, script, partner. Gli agenti non sono chiamanti deterministici. Scoprono le capacità a runtime, scelgono i tool per intento in linguaggio naturale e compongono chiamate fra servizi. L'MCP gli dà un protocollo per farlo senza un wrapper su misura per ogni prodotto. Scrivi un server MCP. Ogni client conforme lo può usare.

Da dove arriva l'MCP e perché si è diffuso

Anthropic ha introdotto l'MCP a fine novembre 2024 per risolvere la tassa di integrazione che ogni prodotto AI stava pagando: M client per N tool fa M per N adapter custom. Il protocollo trasforma quel conto in M più N. OpenAI l'ha adottato ad aprile 2025. Microsoft l'ha integrato in Copilot Studio a luglio 2025. All'inizio del 2026 un tracker di settore riportava che il 28% delle aziende Fortune 500 aveva messo in produzione server MCP per flussi AI, e Forrester prevedeva che il 30% dei vendor di applicazioni enterprise avrebbe spedito un proprio server MCP nel corso del 2026.

La specifica vive su modelcontextprotocol.io. La revisione più recente al momento della scrittura è 2025-11-25.

Come funziona davvero un server MCP

Un server MCP è un processo che parla JSON-RPC 2.0 su uno dei due trasporti:

• STDIO per server locali lanciati dal client (pensa a un binario sulla macchina dell'utente).
• Streamable HTTP per server remoti raggiungibili in rete, oggi il trasporto dominante per i casi SaaS.

Il server espone tre primitive:

• Tools. Azioni invocabili (crea fattura, interroga ordini, esegui SQL). Il client le elenca a runtime e le invoca per conto dell'utente.
• Resources. Dati leggibili (un file, un record, il risultato di una query). Il client li recupera per popolare il contesto del modello.
• Prompts. Template di prompt del server che il client può esporre all'utente come scorciatoie.

Alla connessione il client fa un handshake di capacità: chiede cosa offre il server, riceve descrizioni machine-readable e le presenta al modello. Il modello sceglie un tool per intento, il client lo invoca, il server lo esegue, il risultato torna nella conversazione. Nessun endpoint hardcoded. Nessuna versione di SDK da pinnare. Nessun glue code nel client.

Perché REST da solo non basta più

Una domanda comune è "abbiamo già un'API REST, perché spedire un server MCP sopra?". Tre ragioni.

Discovery a runtime. Gli agenti non leggono le spec OpenAPI come uno sviluppatore. L'MCP è progettato perché gli agenti interroghino le capacità al momento della connessione, scelgano il tool giusto e si adattino al cambiare del prodotto. Un nuovo tool sul server? La connessione successiva lo vede.

Economia dei token. Chiamare un'API REST da un LLM significa serializzare gli argomenti, infilare la risposta nella context window e pagare ogni token in entrambe le direzioni. I benchmark collocano l'MCP attorno al 15% o 25% più lento per chiamata rispetto a una REST diretta per l'overhead JSON-RPC, ma con il 50% o 80% in meno di token consumati dal modello, che è la voce di costo che guida la spesa di inferenza.

Costo di integrazione lato consumer. Ogni client che vuole chiamare la tua API REST scrive il proprio wrapper, gestisce il proprio flusso di auth e mantiene i propri retry. Con l'MCP il client scrive zero codice di integrazione per il tuo prodotto. Punta all'URL del server e parte.

Questo non rende REST obsoleto. Il traffico ad alta throughput, deterministico, app-to-app resta su REST o gRPC. L'MCP sta sopra per lo strato degli agenti.

Sicurezza: cosa cambia quando il prodotto diventa agent-addressable

I server MCP remoti usano OAuth 2.1 con PKCE SHA-256 obbligatorio. La specifica vieta esplicitamente il metodo PKCE plain e richiede ai client di provare di possedere l'authorization code. La revisione 2025-11-25 ha aggiunto annotazioni di autorizzazione role-based, così i server possono gatekeepare singoli tool dietro ruoli utente specifici.

La superficie d'attacco è concreta. Durante il 2025 i ricercatori hanno catalogato più di mille server MCP pubblicamente esposti con auth debole o assente, più una famiglia di bug nella gestione delle credenziali fra gli SDK più popolari. Un sondaggio su oltre mille leader tecnologici enterprise riportava che il 62% indicava la sicurezza come la preoccupazione principale nel deployment di agenti AI.

Tratta un server MCP come un'API pubblica: fai threat-modeling, restringi lo scope dei token, logga ogni tool call e ruotali. Non farti convincere dalla novità del protocollo a saltare l'igiene di base.

Quando il tuo SaaS ha bisogno di un server MCP

Ti serve quando è vera almeno una di queste cose:

• I tuoi utenti già provano a usare il tuo prodotto da dentro Claude, ChatGPT, Cursor, Copilot o un agente custom, e l'esperienza è goffa.
• Vendi a sviluppatori o team ops che vivono dentro Claude Code o VS Code.
• Il tuo prodotto contiene dati utili a un agente in mezzo a un task (record CRM, feature flag, dashboard, ticket, documenti).
• Un concorrente nella tua categoria ne ha spedito uno. Il buyer del 2026 se lo aspetta.

Puoi rimandare la spedizione quando il tuo prodotto è consumato quasi solo attraverso la tua UI, la tua API non ha operazioni read-write che valga la pena automatizzare, o i tuoi utenti non sono tecnici e non installeranno tooling da agente.

Cosa esporre (e cosa nascondere)

La tentazione quando avvolgi un'API esistente è esporre tutto. Resisti. Una buona superficie MCP è un insieme curato di verbi che l'agente può usare in sicurezza:

• Operazioni di lettura che restituiscono dati strutturati con shape stabili.
• Operazioni di scrittura ad alto segnale, idempotenti o gated da uno step di conferma.
• Primitive di ricerca e query invece della plumbing di paginazione grezza, che gli agenti ancora faticano a guidare correttamente.

Lascia fuori gli endpoint amministrativi distruttivi, tutto ciò che richiede macchine a stati complesse su cui l'agente non può ragionare e tutto ciò che dipende da contesto UI che il server non può verificare. Se un tool può cancellare una tabella di produzione, non deve vivere su un server MCP a cui un ingegnere junior ha collegato un client di chat.

Hosted vs self-built

Ci sono due strade.

Self-built. Scrivi un server MCP in TypeScript, Python o Go usando gli SDK ufficiali, lo deployi accanto alla tua API e possiedi trasporto, auth e observability. Meglio quando il prodotto ha logica di business non banale, quando vuoi controllo profondo o quando la compliance esclude la gestione di token utente da parte di terzi.

Piattaforme MCP hosted. I vendor espongono API SaaS esistenti come server MCP e gestiscono auth, curatela dei tool e rate limiting. Tempi di go-to-market più brevi, controllo più stretto e un terzo soggetto nel percorso del token. Ok per una v1, più debole come posizione di lungo periodo se gli agenti diventano un'interfaccia primaria.

Una strada pragmatica è self-built per i tool che definiscono il tuo prodotto, hosted per le integrazioni che lo supportano soltanto (per esempio esporre un CRM partner che rivendi).

Concetti adiacenti utili da conoscere

• Tool calling (OpenAI function calling, Anthropic tools). Il meccanismo per vendor che un client MCP usa sotto il cofano per invocare i tool del tuo server.
• A2A (Agent to Agent protocol). Complementare, non concorrente. L'MCP collega gli agenti ai tool; A2A collega gli agenti tra loro.
• llms.txt. Un manifest statico alla radice del sito che indica quali pagine canoniche gli AI crawler devono indicizzare. Distinto dall'MCP ma spesso deployato nella stessa checklist di AI-readiness per il 2026 (vedi il nostro pezzo su Generative Engine Optimization).