Il Model Context Protocol, spiegato a chi costruisce
Ogni team che costruisce più di un agente scrive due volte lo stesso adattatore: collegarsi a un sistema, descrivere cosa sa fare ed esporre quelle capacità al modello nella forma attesa dal client del momento. Il Model Context Protocol esiste per fermare questa duplicazione standardizzando l'interfaccia fra client agente e server di strumenti.
È davvero utile ed è anche più stretto di quanto suggerisca l'entusiasmo. MCP descrive come le capacità vengono annunciate e invocate. Non decide chi può invocarle, e confondere le due cose è l'origine degli incidenti di sicurezza.
Cosa standardizza il protocollo#
- Scoperta: il server dice al client quali strumenti e risorse offre, con gli schemi.
- Invocazione: il client chiama con argomenti tipizzati e riceve un risultato strutturato.
- Risorse: contenuti in sola lettura che il client tira nel contesto su richiesta.
- Trasporto: un formato comune perché client e server di autori diversi si capiscano.
Cosa deliberatamente non fa#
MCP non autentica i vostri utenti, non decide quali record ciascuno può leggere e non decide se un'azione richieda approvazione. Tutto ciò resta vostro e deve vivere lato server — un client che chiede il permesso con gentilezza non è un sistema di permessi. L'errore architetturale più comune è esporre uno strumento ampio come `run_query` via MCP confidando nel prompt.
Trattate ogni strumento MCP come se un chiamante confuso o manipolato lo invocasse con i peggiori argomenti plausibili.
Dove conviene oggi#
| Situazione | Valore di MCP |
|---|---|
| Un sistema interno, più client agente | Alto — il server si scrive una volta |
| Assistenti desktop con contesto locale | Alto — l'ecosistema è nato lì |
| Un agente con tre strumenti propri | Basso — le chiamate dirette sono più semplici |
| Strumenti di terzi che non controllate | Medio — comodo, ma verificate il server |
Un modo sicuro di adottarlo#
- Incapsulate capacità strette, non potere generale: `get_order(id)` invece di `sql(query)`.
- Applicate l'autorizzazione nel server, a ogni chiamata, con l'identità dell'utente finale.
- Restituite errori brevi e onesti — `non trovato`, `non consentito`.
- Registrate ogni invocazione con argomenti e identità: è la vostra pista di audit.
- Fissate i server usati a versioni riviste, come ogni dipendenza.
Domande frequenti
Serve MCP per costruire un agente?
No. Per un agente con pochi strumenti propri, le chiamate dirette sono più semplici. MCP conviene quando la stessa capacità deve essere raggiunta da più client.
MCP è sicuro per impostazione predefinita?
È uno standard di trasporto e scoperta, non un modello di sicurezza. Autenticazione, autorizzazione per utente e cancelli di approvazione li implementate lato server.
I server MCP possono essere un vettore di injection?
Sì, sia tramite le descrizioni che entrano nel contesto sia tramite i contenuti restituiti.
model context protocolmcp spiegatostandard strumenti agentisicurezza mcpscoperta strumenti
