Che cos'è l'MCP (Model Context Protocol)?

L’MCP è uno standard aperto che permette alle applicazioni IA di collegarsi a tool e dati esterni con un solo protocollo, senza integrazioni su misura. Presentato da Anthropic nel novembre 2024 e diventato standard di settore entro un anno, fa per gli agenti IA più o meno quello che una porta comune ha fatto per le periferiche – la battuta dell‘“USB-C per l’IA” a cui ogni articolo divulgativo ricorre. L’inquadramento più affilato per chi sviluppa backend: un server MCP è un adattatore di API. Un backend esistente già sa rispondere alle richieste; l’MCP è il modo di renderlo scopribile e invocabile da un modello IA invece che da codice client scritto a mano.

Punti chiave

Un server MCP che avvolge un backend già esistente

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/server';
import { z } from 'zod';

const server = new McpServer({ name: 'tasks', version: '1.0.0' });

// A tool is a described, discoverable wrapper over the API you already have
server.registerTool(
  'query_tasks',
  { description: 'List tasks by status', inputSchema: z.object({ status: z.string() }) },
  async ({ status }) => {
    const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
      headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
    });
    return { content: [{ type: 'text', text: await res.text() }] };
  }
);
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

La scheda JavaScript è l’intera idea in quindici righe: un tool query_tasks è un involucro descritto e scopribile su una chiamata REST che il backend già serve. L’agente legge la descrizione al runtime, decide quando il tool è adatto e lo chiama – colpendo gli stessi endpoint, le stesse ACL e gli stessi rate limit dell’app. Un nuovo tipo di client, non un nuovo backend.

Come l’MCP risolve il problema di integrazione N×M

Prima dell’MCP, collegare N client IA a M tool significava fino a N × M integrazioni su misura. Un protocollo condiviso riduce il conto a N + M: ogni client e ogni server implementa l’MCP una volta sola. L’architettura ufficiale nomina tre ruoli – l’host è l’applicazione IA; genera un client per ogni connessione; ogni server fornisce una capacità – su JSON-RPC, con stdio per i server locali sulla stessa macchina e Streamable HTTP per quelli remoti (il trasporto originale HTTP+SSE è ormai deprecato).

Le tre primitive

Un singolo server di database tipicamente le espone tutte e tre: un tool query, una resource schema e qualche prompt few-shot per le richieste più comuni – “ecco che cosa so fare, che cosa so e come chiedermelo”.

MCP vs. API vs. function calling

I due confronti si risolvono in modo netto. Rispetto a un’API: l’MCP non la sostituisce, la avvolge, aggiungendo la scoperta al runtime perché sia il modello a scegliere la chiamata invece del codice dell’applicazione. Rispetto al function calling: il function calling è il modello che emette una richiesta strutturata; l’MCP standardizza il modo in cui quella richiesta viene scoperta ed eseguita fra app e provider diversi. L’MCP aggiunge standardizzazione e portabilità, non capacità: tutto ciò che fa l’MCP, un function calling su misura potrebbe farlo per una singola integrazione; l’MCP lo fa funzionare dappertutto senza riscriverlo.

La superficie di sicurezza, in tutta onestà

La sezione che le pagine neutre saltano e che i vendor di sicurezza gonfiano. La minaccia non è il protocollo, è il modello di fiducia. La prompt injection entra attraverso gli output dei tool: un documento restituito da un tool può contenere istruzioni che il modello poi segue. Il tool poisoning nasconde istruzioni malevole nella descrizione di un tool, che il modello legge prima che qualsiasi essere umano la veda – ora catalogato in OWASP. Rug pull: un server approvato una volta può cambiare in seguito le definizioni dei propri tool. E quella silenziosa: la catena di fornitura dei server della community – ne esistono migliaia, e installarne uno gli concede un appoggio dentro il contesto dell’agente. Le contromisure sono normale disciplina di sicurezza applicata a una superficie nuova: scope al privilegio minimo per ogni server, approvazione umana nel ciclo per le chiamate di tool che agiscono, pinning e allowlist dei server fidati, autenticazione vera sui server remoti e mai credenziali più ampie di quanto il compito richieda.

La specifica oggi

L’MCP si muove in fretta, e la maggior parte degli articoli divulgativi si è congelata a metà 2025 – una nota di freschezza che vale la pena tenere aggiornata. Il trasporto si è consolidato su Streamable HTTP (HTTP+SSE deprecato); i server remoti si sono standardizzati su un’autenticazione in stile OAuth; la revisione 2026-07-28 ha reso il protocollo stateless – nessun handshake, nessuna sessione, metadati per singola richiesta, una chiamata server/discover – e ha deprecato Roots, Sampling e Logging. La governance è il segnale più forte: alla fine del 2025 il protocollo è stato donato a una fondazione open-source neutrale rispetto ai vendor, il marcatore strutturale di uno standard vero e non della convenzione di un singolo fornitore. La lezione pratica per chi costruisce: conviene fissare una versione della specifica, leggere il changelog prima di aggiornare e trattare “MCP” come un bersaglio in movimento con un nucleo stabile.

Casi d’uso tipici

• Agenti di scrittura del codice – gli assistenti nell’IDE raggiungono repo, database e issue tracker tramite server invece che tramite plugin su misura.
• Chat sui dati aziendali – un assistente interroga i sistemi interni, ognuno avvolto come server MCP con i propri permessi.
• Esposizione del backend – trasformare un’API REST o GraphQL esistente in tool invocabili dagli agenti senza ricostruirla.
• Automazione di desktop e di flussi di lavoro – server stdio locali che fanno da ponte fra il modello, i file e le applicazioni di una sola macchina.
• Portabilità fra provider – un solo server che serve ogni host che parla MCP, così un’integrazione sopravvive a qualunque scelta di modello.

Conviene usare l’MCP? Matrice decisionale

Limiti e trade-off

• È uno standard in movimento. L’evoluzione rapida della specifica impone pinning delle versioni e vigilanza sul changelog; “supporta MCP” è un’affermazione con una data.
• Il modello di fiducia è nuovo. Descrizioni e output dei tool sono superficie d’attacco; agenti che agiscono su server non verificati sono il curl \| bash di questa epoca.
• Overhead sotto il punto di pareggio. Per una sola integrazione l’MCP aggiunge un protocollo e un processo server dove basterebbe una chiamata di funzione.
• La scoperta sposta il controllo verso il modello. La selezione dei tool al runtime è potente e meno prevedibile delle chiamate codificate a mano: verifica e approvazione contano di più, non di meno.
• Avvolge, non ripara. Un server MCP sopra un’API mal protetta espone quell’API agli agenti più in fretta; i permessi sottostanti fanno ancora il lavoro vero.

L’MCP su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’inquadramento dell’adattatore di API cade qui in modo naturale: un’app Back4app espone già la superficie che un server MCP avvolge – REST e GraphQL su ogni classe, più le funzioni Cloud Code – quindi renderla accessibile agli agenti è questione di mappare find objects, run function e read schema su definizioni di tool, come abbozzano le schede di codice. La sezione sulla sicurezza diventa indicazione concreta: al server MCP va data una chiave con scope ristretto, mai la master key; le ACL e i permessi di classe della piattaforma limitano ciò che le chiamate di un agente possono toccare, esattamente come limitano quelle dell’app; e le azioni irreversibili vanno messe dietro funzioni Cloud Code con controlli propri invece di concedere accesso diretto alle tabelle. L’agente diventa un client in più di un backend che già sa come dire no.