---
term: 'MCP (Model Context Protocol)'
seoTitle: 'MCP (Model Context Protocol): server, tool e sicurezza'
headline: 'Che cos''è l''MCP (Model Context Protocol)?'
slug: mcp
category: ai-modern-stack
shortDefinition: '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.'
relatedTerms:
  - api
  - rest-api
  - webhooks
  - api-key-security
contrastsWith:
  - api
aboutTerms:
  - 'MCP Server'
  - 'Tools, Resources, Prompts'
  - 'Host, Client, Server'
faq:
  - question: 'Che cos''è l''MCP in parole semplici?'
    answer: 'Uno standard aperto che permette alle applicazioni IA di collegarsi a tool e dati esterni attraverso un protocollo comune, invece di un''integrazione su misura per ogni tool. L''analogia consacrata è una porta USB-C per l''IA: un connettore, molti dispositivi – ed è il modello a decidere al runtime quale tool usare.'
  - question: 'Chi ha creato l''MCP e quando?'
    answer: 'Anthropic lo ha presentato nel novembre 2024. Nel corso del 2025 i principali fornitori di modelli IA e i produttori di strumenti di sviluppo lo hanno adottato, sono comparsi migliaia di server della community e a fine anno la governance è passata a una fondazione open-source neutrale rispetto ai vendor: la traiettoria che porta dal protocollo di una singola azienda a uno standard di settore.'
  - question: 'L''MCP è un''API? Sostituisce le API?'
    answer: 'No – l''MCP è uno strato protocollare che di solito avvolge API esistenti invece di sostituirle. La maggior parte dei server MCP chiama sotto il cofano una classica API REST o GraphQL; l''MCP standardizza il modo in cui un modello IA scopre, descrive e invoca quelle capacità, non quali esse siano. Un''API si rivolge a chi sviluppa; l''MCP si rivolge al modello, con scoperta al runtime.'
  - question: 'Qual è la differenza tra MCP e function calling?'
    answer: 'Il function calling è una capacità del modello: l''LLM emette una richiesta strutturata per eseguire una funzione con un nome. L''MCP standardizza il modo in cui quelle funzioni vengono scoperte, descritte ed eseguite fra app e provider diversi. Il function calling è l''intenzione; l''MCP è lo strato di esecuzione portabile. I due si combinano; nessuno dei due sostituisce l''altro.'
  - question: 'Che cos''è un server MCP?'
    answer: 'Un programma che espone tool, resource e prompt ai client IA attraverso il protocollo – in locale su stdio oppure in remoto su HTTP. Un server MCP per un database può offrire un tool di query, una resource con lo schema e qualche modello di prompt. Attenzione al vocabolario: l''MCP è il protocollo; l''artefatto che si esegue è un "server MCP".'
  - question: 'Che cosa sono tool, resource e prompt?'
    answer: 'Le tre primitive di un server. I tool sono funzioni che il modello può invocare, eseguite con l''approvazione dell''utente. Le resource sono dati di contesto leggibili, in forma di file. I prompt sono modelli di interazione riutilizzabili. Insieme permettono a un server di dire "ecco che cosa so fare, che cosa so e come chiedermelo".'
  - question: 'L''MCP è sicuro?'
    answer: 'Il protocollo è neutro; i rischi sono reali: prompt injection attraverso gli output dei tool, tool poisoning (istruzioni malevole nascoste nella descrizione di un tool), rug pull (un server che cambia le proprie definizioni dopo l''approvazione) e la catena di fornitura dei server della community non verificati. Le contromisure: scope al privilegio minimo, approvazione umana delle chiamate di tool, pinning delle versioni e allowlist dei server, autenticazione sui server remoti.'
  - question: 'L''MCP funziona con qualunque modello IA?'
    answer: 'È proprio il senso dello standardizzarlo: un server scritto una volta funziona con qualunque host che parli il protocollo, presso qualunque provider. La stessa integrazione che usa un agente di scrittura del codice è raggiungibile da un assistente di chat o da un agente su misura, ed è esattamente la riduzione da N×M a N+M che lo standard esiste per portare.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Model Context Protocol — official documentation'
    url: 'https://modelcontextprotocol.io/docs/getting-started/intro'
  - name: 'MCP architecture — host, client, server'
    url: 'https://modelcontextprotocol.io/docs/learn/architecture'
  - name: 'Introducing the Model Context Protocol — Anthropic'
    url: 'https://www.anthropic.com/news/model-context-protocol'
  - name: 'MCP Tool Poisoning — OWASP'
    url: 'https://owasp.org/www-community/attacks/MCP_Tool_Poisoning'
  - name: 'Model Context Protocol — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Model_Context_Protocol'
cta:
  title: 'Il tuo backend, pronto per gli agenti'
  text: 'Un''app Back4app espone già API REST e GraphQL – esattamente la superficie che un server MCP avvolge sotto forma di tool, così gli agenti raggiungono i tuoi dati attraverso le stesse ACL, chiavi e rate limit della tua app.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-13'
translationKey: model-context-protocol-mcp
---

**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

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Un protocollo aperto (JSON-RPC) che collega le app IA a tool e dati |
| Il problema che risolve | Integrazioni su misura N client × M tool → N + M con un solo standard |
| Le parti | Host (l'app IA) · client (una connessione per server) · server (la capacità) |
| Le primitive | Tool (fare) · resource (leggere) · prompt (modelli) |
| L'avvertenza onesta | Superficie di sicurezza reale – tool poisoning, rug pull, server non verificati |

## Un server MCP che avvolge un backend già esistente

**JavaScript:**

```javascript
// JavaScript / Node.js — an MCP server wrapping an existing backend API

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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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](/glossary/it/liste-di-controllo-degli-accessi-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

```mermaid
flowchart LR
  accTitle: Host, client e server MCP al posto delle integrazioni su misura
  accDescr: Un'applicazione host di IA genera un client MCP per ogni connessione a un server. Ogni client parla il protocollo standard a un server MCP, che espone tool, resource e prompt appoggiati a un'API o a un database sottostanti. Poiché ogni client e ogni server implementano lo stesso protocollo, le integrazioni crescono come N più M invece che N per M.
  H["Host<br/>(l'applicazione IA)"] --> C1["Client 1"] --> S1["Server MCP:<br/>database (tool + schema)"]
  H --> C2["Client 2"] --> S2["Server MCP:<br/>file (resource)"]
  H --> C3["Client 3"] --> S3["Server MCP:<br/>la propria API REST/GraphQL"]
  S1 -.-> API[("API e dati<br/>sottostanti")]
  S2 -.-> API
  S3 -.-> API
```

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](https://modelcontextprotocol.io/docs/learn/architecture) 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

| Primitiva | Il modello può… | Analogia di backend |
| --- | --- | --- |
| **Tool** | *Fare* – invocare una funzione (con approvazione dell'utente) | Un [endpoint API](/glossary/it/api-rest/) o una [Cloud Function](/glossary/it/cloud-code-funzioni-serverless/) |
| **Resource** | *Leggere* – tirare contesto in forma di file | Una rotta GET o un archivio di documenti |
| **Prompt** | *Riusare* – applicare un modello di interazione | Una query salvata o uno snippet |

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

| | [API](/glossary/it/api/) semplice | Function calling | MCP |
| --- | --- | --- | --- |
| Si rivolge a | Chi sviluppa | Al modello, per ogni app | Al modello, in modo portabile |
| Chi sceglie la chiamata | Il codice dell'applicazione | Il modello, in modo specifico per app | Il modello, da qualunque host |
| Scoperta | La documentazione, al momento della build | Codificata a mano in ogni app | Al runtime, standardizzata |
| Portabilità | n/d | Legata a una sola integrazione | Scritta una volta, qualunque host o provider |
| Aggiunge | La capacità | L'*intenzione* di chiamare | L'*esecuzione* standardizzata |

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](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning). **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](/glossary/it/sicurezza-delle-chiavi-api/) 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](/glossary/it/api-rest/) 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

| Situazione | Orientarsi su |
| --- | --- |
| Molti client IA hanno bisogno di molti tool | L'MCP – il guadagno N+M è il punto |
| Esporre agli agenti il proprio backend | Un server MCP che avvolge l'[API](/glossary/it/api/) già esistente |
| Una sola app, un solo tool, un solo provider | Function calling diretto – meno macchinario |
| Flusso deterministico lato server, senza un modello che scelga | Una semplice [chiamata API](/glossary/it/api-rest/) |
| Installare server di terze parti | Verificare, fissare le versioni, privilegio minimo – oppure lasciar perdere |
| Conta la portabilità fra provider di modelli | L'MCP – il server si scrive una volta sola |

## 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](/glossary/it/liste-di-controllo-degli-accessi-acl/) 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](/glossary/it/sicurezza-delle-chiavi-api/) con scope ristretto, mai la master key; le [ACL e i permessi di classe](/glossary/it/liste-di-controllo-degli-accessi-acl/) 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](/glossary/it/cloud-code-funzioni-serverless/) 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.