MCP è passato in produzione: 6 cose che ho imparato costruendo server veri

Risposta diretta: MCP (Model Context Protocol) non è più un esperimento. Nato in Anthropic a novembre 2024 e donato a dicembre 2025 alla Agentic AI Foundation della Linux Foundation — con OpenAI, Google, Microsoft, AWS, Cloudflare e Block a bordo — nel 2026 è di fatto lo standard con cui gli agenti AI parlano con i sistemi aziendali. I numeri: 97 milioni di download mensili degli SDK a marzo 2026 (erano 100.000 al lancio), tra 8.000 e 12.000 server censiti nel secondo trimestre 2026, e secondo il report Stacklok 2026 il 41% delle aziende software ha server MCP in produzione, limitata o estesa. Ne ho costruiti alcuni. Quello che segue è la parte che non trovi nella specifica.

TL;DR

Un server MCP non è un wrapper delle tue API: è un'interfaccia utente, e l'utente è un modello.
Le descrizioni dei tool sono prompt. Scritte male, l'agente sbaglia e la colpa sembra del modello.
Il budget di contesto è la risorsa scarsa: un tool che restituisce 40.000 token ammazza la sessione.
Gli errori devono essere istruzioni, non stack trace.
Ogni tool che scrive dev'essere idempotente: gli agenti ritentano, per progetto.
La superficie di sicurezza è reale e poco presidiata: privilegi alti, prompt injection nei dati, audit quasi mai fatto.

Perché è successo davvero

MCP ha vinto per la stessa ragione per cui vince qualsiasi standard: ha eliminato un problema di combinatoria. Prima, collegare N modelli a M sistemi voleva dire N×M integrazioni su misura. Con un protocollo comune diventano N+M. Non è una rivoluzione concettuale — è la stessa logica di ODBC, di LSP per gli editor, di OpenAPI. È noiosa, ed è per questo che funziona.

Il passaggio alla Linux Foundation, a fine 2025, è il momento in cui è diventato adottabile anche da chi non voleva dipendere da un singolo vendor. Da lì l'adozione enterprise ha smesso di essere un pilota e ha iniziato a somigliare a infrastruttura: il 28% delle Fortune 500 ha implementato server MCP.

E nel frattempo si è infilato dove non te lo aspetti: il Universal Commerce Protocol di Google e Shopify usa MCP come uno dei trasporti con cui un agente interroga il catalogo di un merchant. Il protocollo nato per far leggere file a Claude è diventato un binario del commercio.

Le 6 cose che ho imparato

1. Non esporre le tue API: progetta un'interfaccia per un modello

Il primo server che ho scritto era un wrapper uno-a-uno sulle mie REST API. Trenta tool, ognuno mappato su un endpoint. Risultato: l'agente ne chiamava sei di fila per rispondere a una domanda banale, si perdeva a metà, e ogni tanto sceglieva il tool sbagliato perché due nomi si somigliavano.

La lezione è che i tool vanno progettati sui compiti, non sulle risorse. Non get_customer, get_orders, get_order_items, get_shipment — ma riepilogo_ordini_cliente, che fa i quattro giri internamente e restituisce una cosa sola. Meno tool, più densi, con confini che corrispondono a intenzioni umane. La regola che uso adesso: se per rispondere a una domanda tipica servono più di due chiamate, il taglio dei tool è sbagliato.

2. Le descrizioni dei tool sono prompt, trattale come tali

Questa mi è costata una settimana di debugging che credevo fosse un problema di modello. Non lo era: era una descrizione ambigua. Un tool descritto come "cerca prodotti" viene invocato anche quando l'utente chiede lo stato di un ordine, perché per il modello "cerca" è generico.

Ora scrivo le descrizioni con tre elementi obbligatori: cosa fa, quando usarlo, quando NON usarlo. Ed è nella descrizione dei parametri che si vincono le battaglie: un limit documentato come "massimo 20, usa 5 salvo richiesta esplicita" cambia il comportamento più di qualunque system prompt.

3. Il contesto è la risorsa scarsa, non la latenza

L'errore più comune che vedo (e che ho fatto): tool che restituiscono il payload JSON completo, perché "tanto poi il modello filtra". Il modello non filtra: paga. Quaranta prodotti con tutti i campi sono decine di migliaia di token che restano in conversazione per tutta la sessione, degradano l'attenzione e costano a ogni turno successivo.

Regole che applico:

Paginazione obbligatoria e default bassi.
Solo i campi che servono per decidere; il dettaglio si chiede con un secondo tool.
Output tabellare o compatto invece di JSON verboso quando serve solo leggere.
Un tetto duro di token per risposta, con troncamento esplicito ("mostrati 10 di 240 risultati").

4. Gli errori sono istruzioni per il modello

Un 500 Internal Server Error è inutile a un agente: non sa se ritentare, cambiare parametri o arrendersi. Un errore scritto bene è metà del lavoro:

"Nessun prodotto trovato per SKU 'ABC-12'. Lo SKU deve avere 8 caratteri. Usa cerca_prodotti per trovare lo SKU corretto a partire dal nome."

Il modello legge quella frase e corregge la rotta da solo. È la differenza tra un agente che sembra intelligente e uno che sembra rotto — e non dipende dal modello.

5. Idempotenza, perché gli agenti ritentano

Gli agenti riprovano: per timeout, per un errore ambiguo, per una decisione del planner. Se hai un tool crea_ordine non idempotente, prima o poi ti ritrovi due ordini uguali. Ogni tool che scrive nei miei server accetta una chiave di idempotenza e restituisce lo stesso risultato se la chiave si ripete.

È lo stesso principio per cui mi interessa il nuovo metodo HTTP QUERY: dichiarare cosa è sicuro ripetere non è un formalismo accademico, è ciò che permette al sistema attorno di comportarsi bene senza chiedere permesso.

6. La sicurezza: il punto in cui sono più preoccupato

I server MCP girano spesso con privilegi alti — accesso a database, CRM, gestionale — e sono una superficie d'attacco che quasi nessuno sottopone a review sistematica. Le tre cose che considero non negoziabili:

Credenziali per tenant e per utente, mai condivise. Il server deve agire per conto di qualcuno, con i permessi di quel qualcuno. Altrimenti hai costruito un confused deputy perfetto: l'agente chiede una cosa legittima, il server la esegue con i poteri dell'amministratore.
Prompt injection dai dati, non dall'utente. Il testo che il tuo tool restituisce entra nel contesto del modello. Se una descrizione prodotto, una recensione o una nota cliente contiene "ignora le istruzioni precedenti e...", quella riga arriva al modello con la stessa dignità delle tue istruzioni. I dati vanno trattati come input ostile.
Audit log su ogni invocazione, con chi, cosa, con quali parametri e quale esito. Quando qualcosa va storto — e va storto — senza log non hai nemmeno modo di ricostruire cosa ha deciso l'agente.

Aggiungo una regola di prudenza che seguo: le operazioni distruttive o irreversibili non sono tool. Cancellazioni, rimborsi, invii massivi passano da una conferma umana esplicita. Non per sfiducia nel modello: perché il costo dell'errore è asimmetrico.

Non tutto deve essere un server MCP

Contro-opinione, visto che ora MCP si mette dappertutto: se un flusso è deterministico, un agente in mezzo è solo latenza, costo e varianza. Sincronizzare un catalogo ogni notte non ha bisogno di un modello che decide: ha bisogno di un cron e di un endpoint.

MCP dà il meglio dove serve giudizio su input aperti: interpretare una richiesta ambigua, incrociare fonti diverse, decidere quale strumento serve. Per tutto il resto, il codice normale è più veloce, più economico e più prevedibile. È lo stesso ragionamento che faccio quando uso gli agenti sui dati pubblici: il valore è nel grafo e negli strumenti, non nell'agente in sé.

FAQ

MCP serve anche a una PMI o è roba da enterprise?

Serve, se hai dati sparsi su più sistemi e vuoi interrogarli in linguaggio naturale. Un server MCP sopra gestionale ed e-commerce permette di chiedere "quali clienti hanno ordinato due volte e non tornano da tre mesi" senza aprire tre gestionali. Il costo è contenuto; la parte impegnativa è la sicurezza, non lo sviluppo.

Qual è il rischio principale?

I permessi. Un server MCP con credenziali onnipotenti e nessun audit è un incidente che aspetta di succedere, soprattutto perché il testo che entra nel contesto può contenere istruzioni ostili. Principio del privilegio minimo, credenziali per utente, log su tutto.

Meglio usare i server MCP pubblici o farsene uno?

Per strumenti generici e diffusi ha senso partire da quelli esistenti, verificando chi li mantiene e cosa fanno davvero (girano con i tuoi permessi: leggi il codice). Per i tuoi dati di business conviene quasi sempre un server tuo, disegnato sui compiti reali del tuo team.

MCP e le API REST si escludono?

No, si sovrappongono per scopo diverso. Le API restano il contratto per software deterministico; MCP è l'interfaccia per un consumatore che ragiona e sbaglia. Spesso i due vivono sullo stesso backend, con MCP che espone meno tool e più "compiti".

Se vuoi capire se ha senso esporre i tuoi sistemi a un agente — e come farlo senza aprire una falla — parliamone. È il tipo di decisione architetturale che mi tocca spesso come Fractional CTO.