MCP spiegato a chi deve deciderlo, non a chi deve implementarlo

Caldo, webcam spenta, microfono spento. A un certo punto qualcuno dice: “dobbiamo adottare MCP, che essenzialmente è lo standard”. Chiedo: standard per fare cosa, esattamente? Silenzio.

Ecco il problema. MCP è diventato una di quelle sigle che si mettono nelle slide per sembrare fighi e up to date, come “blockchain” nel 2018 e “metaverso” nel 2021.

Con una differenza: MCP serve davvero. Ma serve a risolvere un problema specifico, e se quel problema non ce l’hai, stai comprando un ombrello nel deserto. Bello, ben progettato, inutile.

Questo post non spiega come implementare MCP. Di tutorial è pieno il globoterraqueo.

Spiega quando dire sì e quando dire no in quella riunione dove la decisione la prendi tu.

Cos’è, in una riga (ok, forse tre)

Model Context Protocol: un protocollo aperto, rilasciato da Anthropic a fine 2024, che standardizza il modo in cui un modello AI parla con strumenti e dati esterni. Il tuo CRM, il tuo database, il tuo file system, Jira, quello che vuoi.

La metafora ufficiale è “l’USB-C dell’AI”. Carina, funziona nelle slide. Ma l’USB-C te lo ricordi com’è nato: per eliminare il cassetto dei cavi. MCP nasce per eliminare il cassetto delle **integrazioni custom**.

Il problema vero: N per M

Prima di MCP funzionava più o meno così:
Hai 3 modelli (o 3 piattaforme agentiche) e 10 sistemi aziendali da collegare. Ogni collegamento è un connettore scritto a mano: 3 × 10 = 30 integrazioni. Cambi modello? Riscrivi. Aggiungi un sistema? Riscrivi. È il problema N×M, e chi lo paga sei tu, in giornate uomo e manutenzione infinita.

Con MCP l’equazione cambia: ogni sistema espone **un server MCP**, ogni modello parla **un client MCP**. N + M invece di N × M. Il connettore per Jira lo scrivi (o lo scarichi) una volta e funziona con Claude, con GPT, con Copilot, con quello che arriverà dopo.

Questo è il valore. Tutto il resto è contorno.

Perché adesso tutti ne parlano

Perché nel 2025 è successa una cosa rara: i concorrenti si sono messi d’accordo. Anthropic lo ha creato, poi OpenAI, Google e Microsoft lo hanno adottato uno dopo l’altro. Quando i tre litiganti convergono sullo stesso protocollo, non è amore: è solo che a nessuno conviene più mantenere il proprio formato proprietario di tool calling. La standardizzazione qui non è un gesto di apertura, è riduzione dei costi loro travestita da ecosistema. It’s capitalism baby.

Effetto collaterale concreto: esiste già un catalogo enorme di server MCP pronti. GitHub, Slack, Postgres, Google Drive. Roba che prima ti costava uno sprint, ora è un config file.

Quando dire sì

• Primo. Hai più di un sistema da collegare e prevedi di cambiare (o affiancare) modelli nel tempo. Il vendor lock-in sul layer di integrazione è il più subdolo di tutti, perché non lo vedi finché non provi a migrare.
• Secondo. Stai costruendo agenti che devono *agire*, non solo rispondere. Leggere un ticket, aggiornarlo, mandare una mail. MCP standardizza esattamente questo perimetro.
• Terzo. Hai un team piccolo. Il catalogo di server esistenti è manodopera gratis. Per un side project o una PMI è la differenza tra “lo faccio in un weekend” e “non lo faccio”.

Quando dire no (o non ancora)

• Primo. Hai un solo modello, un solo sistema, un solo use case. Una chiamata API diretta è più semplice, più veloce, più debuggabile. MCP lì è overhead travestito da standard: aggiungi un layer, un processo, una superficie di errore, per risolvere un problema di scala che non hai.
• Secondo. Il tuo caso è “chatbot che risponde sui documenti” (chat on documets). Quello è RAG, non serve un protocollo di tool use. Ne ho già scritto: non tutto ciò che luccica è agentic.
• Terzo. Non hai ancora una risposta alla domanda di security. E qui apro la sezione seria.

La parte che nessuno mette nelle slide

Un server MCP è codice che gira con accesso ai tuoi sistemi e che un LLM può invocare.

Tre conseguenze:

• Supply chain. Quel server MCP di Jira scaricato dal catalogo, chi lo mantiene? Chi lo ha auditato? Installare server MCP a caso è come installare estensioni del browser a caso, ma con le chiavi del gestionale in mano.
• Prompt injection. Se l’agente legge contenuti esterni (mail, ticket, pagine web) e ha tool che scrivono, qualcuno prima o poi proverà a fargli fare cose scrivendo istruzioni dentro quei contenuti. Non è teoria, è la classe di attacchi più documentata del 2025.
• Permessi. L’agente agisce con le credenziali di qualcuno. Di chi? Con quali limiti? Se la risposta è “boh, admin”, fermati.

Niente di tutto questo è un difetto di MCP in sé. È il costo di dare le mani a un modello, e quel costo lo paghi con qualunque protocollo. MCP semmai lo rende governabile, perché almeno il perimetro è standard e ispezionabile. Ma governabile non significa governato: quello è lavoro tuo.

La domanda giusta da fare in riunione

Non “adottiamo MCP?”. La domanda giusta è:

quante integrazioni AI-sistemi prevediamo nei prossimi 18 mesi?

– Una o due: API dirette, grazie, arrivederci.
– Da tre in su, o incertezza sul modello che userete: MCP, e la decisione è quasi obbligata.
– In mezzo: MCP solo sui sistemi che toccherà più di un agente.

E una seconda domanda, da fare subito dopo: **chi risponde se un tool fa danni?** Se nella stanza cala il silenzio, avete la risposta anche alla prima.

MCP non è una tecnologia da adottare, è una scommessa sulla direzione dell’ecosistema. La scommessa al momento è buona: quando Anthropic, OpenAI, Google e Microsoft puntano sullo stesso cavallo, il cavallo tende ad arrivare. Ma resta un protocollo di trasporto, non una strategia. Decide come i tuoi agenti parlano coi sistemi, non se ha senso che ci parlino.

Quella decisione, per ora, non c’è protocollo che te la tolga.

Purtroppo.

Le opinioni espresse in questo post sono mie e non rappresentano per niente il mio datore di lavoro.