Corso
Creare sistemi agentici scalabili
1 h 30 min
16K
Un anno e mezzo fa, il Model Context Protocol era ancora un termine di nicchia al di fuori di Anthropic. Oggi compare nei colloqui per ruoli di AI engineering, developer relations e backend, perché molti team che distribuiscono agent hanno un server o un client MCP da qualche parte nello stack.
MCP (Model Context Protocol) è un protocollo aperto che standardizza come le applicazioni di IA si connettono a strumenti esterni, dati e template di prompt. Risolve il problema di integrazione N x M: senza un protocollo condiviso, ogni coppia modello-strumento richiede il proprio connettore. Con MCP, crei il connettore una volta e qualsiasi host conforme può usarlo. Potresti sentirlo chiamare "la USB-C dell'IA", utile come prima spiegazione e poco oltre.
Le domande dei selezionatori dipendono molto dal ruolo. A uno sviluppatore junior potrebbe essere chiesto di spiegare la differenza tra tools e resources. A un platform engineer è più probabile venga chiesto come un core stateless del protocollo cambi il deployment. Ho organizzato la guida per difficoltà e caso d'uso: concentrati sulle sezioni che corrispondono al tuo ruolo.
Qui il tempismo conta, e lo dico esplicitamente perché MCP sta ancora cambiando. Al momento della stesura, la spec stabile corrente è 2025-11-25. Una release candidate per 2026-07-28 è bloccata e in uscita tra circa quattro settimane, quindi qualunque cosa proveniente da quella RC è etichettata come orientata al futuro.
Domande per colloqui MCP per principianti
Queste capitano in molti screening, a prescindere dalla seniority. Inizierei dal vocabolario.
Che cos'è MCP e perché è stato creato?
MCP è uno standard aperto, originariamente sviluppato da Anthropic e open-source a novembre 2024, per connettere applicazioni di IA a strumenti e fonti dati esterne. Più direttamente: implementa MCP una volta e puoi parlare con qualsiasi server compatibile MCP invece di scrivere un nuovo connettore per ogni strumento.
Che cos'è un server MCP?
Un server è un programma che espone strumenti, risorse e prompt a un client MCP. Può essere eseguito come subprocess locale su stdio o come processo remoto indipendente raggiungibile via HTTP. Il server non sa nulla del modello in sé; risponde alle richieste secondo il protocollo.
Che cos'è un client MCP?
Il client è il connettore a livello di protocollo che vive dentro un'applicazione host (pensa a Claude Desktop, VS Code o Cursor) e parla con un server alla volta tramite JSON-RPC. Un singolo host può eseguire più client, ciascuno con la propria connessione uno-a-uno a un server.
In cosa MCP differisce da una normale REST API?
Una REST API è scritta per essere chiamata dagli sviluppatori via codice. MCP è pensato perché un LLM la scopra e la chiami a runtime. Questa distinzione conta più del formato sul filo. Un client può chiedere a un server tools/list e ottenere una descrizione strutturata delle capacità disponibili, cosa che una tipica REST API non offre di default. Per un'integrazione semplice, una chiamata diretta all'API spesso è più rapida ed economica.
Che tipi di risorse può esporre un server?
Qualsiasi cosa indirizzabile tramite URI: file, record di database, documenti, valori di configurazione, risposte di API. Le risorse sono contesto in sola lettura, non azioni, ed è un errore comune tra i principianti confonderle.
Domande sui concetti core di MCP
Una volta chiarito il vocabolario, i selezionatori passano a come le parti comunicano tra loro.
Com'è l'architettura ad alto livello?
Tre ruoli: host, client, server. L'host è l'applicazione che una persona usa. Istanzia uno o più client, e ogni client mantiene una singola connessione a un server. Ogni messaggio tra client e server è JSON-RPC 2.0, che ti dà un formato stabile sul filo indipendentemente dal trasporto.
Quali sono le tre fasi del ciclo di vita di una connessione?
Inizializzazione, operatività e spegnimento. Durante l'inizializzazione, il client invia la versione del protocollo e le capacità che supporta, e il server risponde con le proprie. Una volta che entrambe le parti concordano, richieste normali come tools/list e tools/call avvengono nella fase operativa. Lo spegnimento è solo una chiusura pulita.
Quali trasporti usa MCP oggi?
stdio per server locali basati su subprocess e Streamable HTTP per server remoti. Streamable HTTP ha sostituito il vecchio trasporto HTTP più SSE nella spec 2025-03-26, quindi descrivere due endpoint SSE separati è già superato.
Qual è la differenza reale tra tools, resources e prompts?
Questa distinzione riguarda il controllo, non il tipo di dato:
- Gli strumenti sono controllati dal modello. L'LLM decide quando chiamarne uno in base al contesto.
- Le risorse sono controllate dall'applicazione. L'host o l'utente decide quando caricarne una.
- I prompt sono controllati dall'utente. Una persona seleziona esplicitamente un template prima che inizi l'inferenza.
Molti candidati li definiscono in base al tipo di dato che trasportano, mancando il punto.
Domande su MCP Tools, Resources e Prompts
Chiarito il modello di controllo, la domanda successiva è come appaiono queste primitive nella pratica.
Cosa include la definizione di uno strumento?
Un name, una description, un inputSchema scritto in JSON Schema e, dalla spec 2025-06-18, un outputSchema facoltativo più le annotations che descrivono comportamenti come se uno strumento sia in sola lettura o distruttivo. I client dovrebbero trattare le annotazioni come non affidabili a meno che non provengano da un server fidato. Sono suggerimenti, non garanzie.
Quando qualcosa dovrebbe essere uno strumento invece di una risorsa?
Se ha effetti collaterali o richiede un calcolo fresco, live, è uno strumento. Se è un dato statico o semi-statico di riferimento senza effetti collaterali, è una risorsa. Una consultazione meteo su un'API live è uno strumento. Un elenco in cache delle città supportate è una risorsa.
Cosa rende buono uno strumento MCP, oltre al semplice funzionamento?
Progettalo attorno a ciò che l'utente vuole ottenere, non agli endpoint che ti ritrovi. Uno strumento dovrebbe incapsulare un flusso di lavoro completo, non una singola chiamata API grezza. Conta anche la sua descrizione: quel testo entra nel contesto del modello e influisce sul fatto che il modello scelga lo strumento giusto. Ecco un esempio minimo con il layer FastMCP dell'SDK Python:
from mcp.server.fastmcp import FastMCP
app = FastMCP("weather-demo")
@app.tool()
async def get_weather(city: str) -> str:
"""Get the current weather for a city."""
return f"Weather data for {city}"
@app.resource("config://units")
async def get_units() -> str:
"""Static configuration for the unit system in use."""
return '{"temperature": "celsius"}'La docstring dello strumento diventa la sua descrizione; la risorsa è un dato statico dietro un URI, senza effetti collaterali.
Come recupera una risorsa un client?
Chiama resources/read su un URI ottenuto da resources/list. Se il server supporta la capability listChanged, può notificare il client quando l'elenco delle risorse cambia. Senza quella capability, il client non ha segnali e deve fare polling o aggiornare manualmente.
Domande sullo sviluppo di server MCP
Qui la conoscenza concettuale deve trasformarsi in qualcosa che gira davvero.
Quali SDK ufficiali esistono, e sono tutti ugualmente maturi?
No. Gli SDK sono a livelli: TypeScript, Python, C# e Go sono nel Tier 1 con pieno supporto delle feature, Java e Rust sono Tier 2, e Swift, Ruby, PHP e Kotlin sono Tier 3. L'SDK Python include FastMCP, la sua API per server basata su decorator.
Qual è il bug più comune che rompe un server locale?
Scrivere su stdout quando non dovresti. Un trasporto stdio usa stdout esclusivamente per i messaggi JSON-RPC, quindi una print() o console.log() fuori posto corrompe il flusso dei messaggi e il parser del client va in errore. Qualsiasi cosa tu voglia loggare per il debug deve andare su stderr.
MCP Inspector che mostra strumento e risorsa. Video dell'autore.
Come funziona la gestione degli errori in MCP, e perché conta in un colloquio?
Ci sono tre livelli. I fallimenti a livello di trasporto sono problemi di connessione. Gli errori a livello di protocollo usano i codici standard JSON-RPC (-32700 per un errore di parsing, -32600 fino a -32603 per richieste non valide, metodi sconosciuti e problemi simili). I fallimenti a livello applicativo, come una chiamata API dentro il tuo strumento che ritorna un errore, dovrebbero tornare con isError: true nel risultato dello strumento, così il modello può vederli e reagire.
return {
"content": [{"type": "text", "text": "Rate limit exceeded, try again later"}],
"isError": True
}Quel flag permette al modello di vedere il fallimento e provare qualcosa di diverso.
MCP è stateful in questo momento?
Sì, oggi le sessioni sono tracciate a livello di connessione. Questo crea problemi di scalabilità per i team in produzione, che tratterò nella sezione di system design.
Domande su sicurezza e governance MCP
Le domande sulla sicurezza compaiono ormai in molti colloqui MCP, specialmente per ruoli platform ed enterprise.
In che cosa l'autenticazione differisce tra i trasporti stdio e HTTP?
Per i server locali stdio, l'autenticazione è facoltativa in pratica; stai già fidandoti del processo che hai avviato. Per i server remoti basati su HTTP, OAuth 2.1 è il framework e i server sono classificati come resource server OAuth 2.0 a partire dalla spec 2025-06-18. OAuth non è richiesto ovunque in MCP.
Cos'è il tool poisoning?
Istruzioni malevole nascoste nei metadati di uno strumento, di solito nella descrizione o nello schema, che il modello legge mentre decide quale strumento chiamare. Lo strumento non deve essere invocato perché questo abbia effetto, perché il modello ha già visto le istruzioni quando lo strumento è stato elencato.
In che cosa un attacco rug pull differisce dal tool poisoning?
Il tool poisoning è un problema di punto d'ingresso. Un rug pull è un problema di persistenza: uno strumento sembra pulito quando lo approvi, poi la sua definizione cambia in seguito, e la maggior parte dei client non ha un modo integrato per imporre una nuova approvazione. Difendersi da uno non difende dall'altro.
Cos'è l'Enterprise-Managed Authorization e perché conta adesso?
EMA è un'estensione MCP diventata stabile il 18 giugno 2026. Sposta la decisione di autorizzazione sull'identity provider dell'organizzazione invece del consenso per-server cliccato da ogni dipendente. Il client ottiene un Identity Assertion JWT firmato durante il single sign-on e lo scambia con un access token con ambito dal server di autorizzazione del server. Anthropic, Microsoft e Okta la supportano.
Domande su MCP e AI Agent
Qui il protocollo inizia a collegarsi con il design degli agent.
Perché MCP è importante specificamente per gli agent?
Gli agent hanno bisogno di contesto e azione. MCP mette entrambi dentro un unico protocollo. Come detto prima, tools/list permette a un agent di scoprire cosa è disponibile invece di affidarsi a un elenco hardcoded nel codice dell'agent.
Modello di host, client e server dell'agent. Immagine dell'autore.
Qual è la differenza tra MCP e A2A?
La regola breve è: MCP connette gli agent agli strumenti, A2A connette gli agent ad altri agent. Entrambi i protocolli ora rientrano nella Agentic AI Foundation, quindi di solito vengono discussi come layer separati, non come concorrenti.
Cos'è la primitive di sampling, e dovrei ancora menzionarla?
Il sampling consente a un server di richiedere una completion del modello tramite il client, che è il modo in cui un server può eseguire comportamenti simili a un agent senza detenere chiavi API. Conosci la primitiva, ma aggiungi l'avvertenza: la RC 2026-07-28 segna Sampling, Roots e Logging come deprecati secondo la nuova policy sul ciclo di vita delle feature. Restano funzionanti per almeno dodici mesi, ma agli autori di server viene sempre più consigliato di chiamare direttamente l'API di un provider di modelli.
Come evitano gli agent di esplodere la finestra di contesto con le definizioni degli strumenti?
Non caricando tutte le definizioni degli strumenti in anticipo. L'approccio Tool Search di Anthropic rimanda il caricamento degli schemi degli strumenti finché non servono, e il write-up ingegneristico riporta una riduzione dell'85% dell'uso di token per setup ricchi di strumenti mantenendo accessibile l'intera libreria. In un colloquio, abbinerei il caricamento differito a server con ambito ristretto.
Domande di system design su MCP
Le domande scenario testano se sai applicare queste idee sotto vincoli, non solo recitare definizioni.
Progetta un sistema di recupero documenti usando MCP.
Qui MCP e RAG non competono. RAG gestisce il retrieval vettoriale pre-indicizzato; MCP espone quel retrieval come strumento o risorsa che l'agent può chiamare live, insieme a qualunque altra azione gli serva. Considera la domanda come come si incastrano i due pezzi, non quale sostituisce l'altro.
Progetta un server MCP per dati interni aziendali.
Parti dalla responsabilità singola: un server per dominio, come un server per il database e uno separato per i file, invece di un unico server che fa tutto. Aggiungi OAuth 2.1, scope a minimo privilegio per strumento e audit logging fin dall'inizio, perché il controllo accessi è più difficile da correggere a server attivo.
Come scaleresti oggi un deployment MCP, prima che la spec stateless arrivi?
Spesso i candidati inciampano descrivendo la spec futura come se fosse già uscita. La statefulness dalla sezione server è il problema di scalabilità qui: lo scaling orizzontale richiede routing sticky, uno store di sessioni condiviso o un gateway MCP. La RC 2026-07-28 rimuove le sessioni a livello di protocollo, ma quella parte non è ancora live.
Come eviti che un grande deployment multi-server sommerga il modello di token?
L'idea del caricamento differito della sezione agent aiuta anche qui. A livello di deployment, filtra e aggrega anche i dati lato server prima che raggiungano il contesto del modello e pagina qualsiasi elenco restituito. La regola principale è controllare cosa entra nella finestra di contesto.
Domande di integrazione MCP
Le domande di integrazione verificano se capisci dove MCP appare nei comuni strumenti per sviluppatori.
Come appare MCP all'interno dei prodotti Claude?
Claude.ai, Claude Desktop e Claude Code supportano tutti MCP, e Anthropic gestisce una directory di connettori con server predefiniti. C'è anche un connettore MCP nel Messages API per server remoti, ancora in beta al momento della stesura.
Claude Desktop mostra un server MCP connesso. Immagine dell'autore.
MCP è utile solo con Claude?
No. OpenAI ha adottato MCP nei suoi Agents SDK e Apps SDK a partire da marzo 2025. VS Code ha distribuito il supporto per l'intera spec a metà 2025, Cursor supporta MCP tramite mcp.json, e Google Cloud aveva più di 50 server MCP gestiti già disponibili o in anteprima ad aprile 2026.
In cosa MCP differisce da RAG, concretamente?
Questa è la risposta da system design in forma più corta: RAG risponde da una base di conoscenza aggiornata a intervalli, mentre MCP gestisce lookup live e azioni.
Domande MCP avanzate
Le domande avanzate verificano se stai seguendo l'evoluzione del protocollo, non solo come funziona oggi.
Puoi ripercorrere la storia delle versioni della spec?
I selezionatori lo chiedono per vedere se sai cosa è cambiato e quando. Cinque revisioni contano, e solo una è ancora speculativa:
|
Versione |
Data |
Cosa è cambiato |
|
2024-11-05 |
Nov 2024 |
Release iniziale |
|
2025-03-26 |
Mar 2025 |
Streamable HTTP sostituisce HTTP+SSE; introdotto OAuth 2.1 |
|
2025-06-18 |
Giu 2025 |
Output strutturati degli strumenti, elicitation, classificazione come OAuth resource server |
|
2025-11-25 |
Nov 2025 |
Spec stabile corrente; Tasks async (sperimentale), governance formalizzata |
|
2026-07-28 |
RC bloccata Mag 2026 |
Core stateless, MCP Apps, framework per estensioni |
La chiave è sapere quale riga è effettivamente uscita.
Chi governa effettivamente MCP ora?
Anthropic ha donato il protocollo alla Agentic AI Foundation, un fondo diretto sotto la Linux Foundation, il 9 dicembre 2025. Block e OpenAI hanno co-fondato l'AAIF insieme ad Anthropic, con Google, Microsoft, AWS, Cloudflare e Bloomberg come membri sostenitori. I maintainer hanno mantenuto il controllo sulle decisioni tecniche; la governance è passata a una fondazione più ampia.
Cosa sta cambiando davvero nella release 2026-07-28?
Il cambiamento principale è il core stateless della sezione di system design: l'handshake initialize/initialized e l'header Mcp-Session-Id scompaiono, sostituiti dalle informazioni sulle capability che viaggiano in _meta su ogni richiesta. Questo elimina il requisito di sticky routing. Un framework di estensioni definisce anche come capability opzionali come MCP Apps e Tasks vengano distribuite e stabilizzate separatamente.
Cosa sono le estensioni MCP, e funzionano ovunque?
No. Le estensioni sono capability opt-in, come Enterprise-Managed Authorization, OAuth Client Credentials per l'autenticazione machine-to-machine e MCP Apps per UI interattive dentro un host. Il supporto varia da client a client, quindi non progettare dando per scontato un supporto universale alle estensioni.
Domande scenariali su MCP
Queste testano il ragionamento diagnostico più che fatti a memoria, quindi struttura le risposte come percorso da sintomo a causa a fix.
Le chiamate agli strumenti falliscono a intermittenza. Cosa controlli per primo?
Controlla se i fallimenti tornano come isError: true nel risultato dello strumento o come errore a livello di protocollo. Ti dice se il problema è dentro la logica dello strumento o nel trasporto. Da lì, guarda i rate limit di ciò che lo strumento incapsula e verifica i timeout prima di attribuirlo al modello.
Un agent continua ad agire su dati di risorsa obsoleti. Perché?
Torna alla domanda sulle risorse di prima: listChanged è ciò che dice a un client che una risorsa è cambiata. Senza che sia dichiarata, il client non ha segnali e continua a servire uno snapshot in cache finché qualcosa non forza un aggiornamento.
Un server MCP è diventato un chiaro collo di bottiglia. Cosa fai?
Dividi per domini, aggiungi pooling delle connessioni e scala orizzontalmente. Finché il core stateless non arriva, potresti ancora aver bisogno dell'affinità di sessione discussa nel system design.
Dati sensibili sono trapelati tramite una chiamata a uno strumento. Com'è successo?
Due cause comuni sono uno strumento con permessi più ampi del necessario o l'assenza di sanitizzazione dell'output prima che i dati entrassero nel contesto del modello. Minimo privilegio per strumento e uno step di sanitizzazione prima del contesto sono i rimedi. Anche il tool poisoning è correlato: un modello può essere istruito a inoltrare dati senza che nessuno scriva codice di esfiltrazione.
Errori comuni nei colloqui su MCP
Alcuni schemi compaiono abbastanza spesso da meritare una menzione diretta:
-
Trattare MCP come un sostituto REST drop-in dopo la distinzione su REST vista sopra
-
Definire strumenti e risorse in base al tipo di dato dopo che il modello di controllo è già stato spiegato
-
Supporre che valga la stessa regola di auth per
stdioe HTTP -
Dare la risposta legacy su SSE dopo il cambio di trasporto spiegato sopra
-
Mischiare la spec rilasciata con la RC 2026-07-28
-
Saltare i rischi di sicurezza trattati sopra quando viene chiesto di progettare un sistema di chiamata a strumenti
La maggior parte di questi errori viene da tutorial datati.
Come prepararsi ai colloqui MCP
La pratica hands-on conta per questo protocollo.
-
Costruisci un piccolo server con FastMCP o l'SDK TypeScript, esponi uno strumento e una risorsa e mettilo in esecuzione
-
Installa l'Inspector ufficiale (
npx @modelcontextprotocol/inspector) e osserva il traffico JSON-RPC grezzo che ti mostra -
Collega il tuo server a un client reale, Claude Desktop, VS Code o Cursor, e osserva l'handshake di inizializzazione
-
Leggi il changelog della spec reale invece di un riassunto di seconda mano, in particolare le voci 2025-06-18 e 2025-11-25
-
Scegli uno scenario di system design da questo articolo e scrivi una risposta completa prima del colloquio
Questi passaggi separano la conoscenza di definizione dalla familiarità pratica.
Conclusione
Non penso che memorizzare le definizioni MCP basti più. La parte difficile è sapere quale risposta appartiene a quale versione della spec. I deployment attuali gestiscono ancora sessioni a livello di connessione; la RC 2026-07-28 punta a un core stateless. Se confondi le due cose, la tua risposta architetturale suona più sicura che accurata.
Ecco perché tratterei MCP come qualcosa da testare, non solo da leggere. Costruisci il piccolo server della sezione preparazione, guarda un client elencare gli strumenti e leggere le risorse e fai attenzione a dove finisce il protocollo e inizia il design della tua applicazione. La risposta utile al colloquio non è "MCP è la USB-C dell'IA." È "ecco cosa MCP standardizza, ecco cosa non standardizza ed ecco cosa è cambiato di recente."
Per un approfondimento più strutturato, il nostro corso Building Scalable Agentic Systems copre MCP e A2A nel contesto del design, del testing e del deployment di agent.
Devo memorizzare tutte le date delle versioni della spec?
Il sampling sta venendo deprecato. Vale ancora la pena impararlo?
Con quale SDK dovrei iniziare se non ho mai toccato MCP?
MCP conterà ancora quando uscirà la spec 2026-07-28?
Quanto diventano tecnici in realtà i colloqui MCP per principianti?
Argomenti