MCP spiegato a partire dalla specifica: che cos’è davvero un server

Prima del wire, l’aritmetica. Hai $N$ applicazioni AI e $M$ cose che dovrebbero poter raggiungere: un calendario, un tracker di ticket, un database di warehouse, uno strumento di design. Senza un contratto condiviso, qualcuno scrive $N \times M$ integrazioni, e ognuna è uno schema più un endpoint più una storia di autenticazione più un onere di manutenzione. Con un contratto, il vendor del tool scrive un server, il vendor dell’applicazione scrive un client, e il totale è $N + M$.

Non è un’osservazione nuova, e la specifica dice da chi arriva l’idea:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

Prendi questo confronto alla lettera, non come un complimento. Prima di quel protocollo, supportare un linguaggio in un editor significava un plugin per editor; dopo, il team di un linguaggio spediva un solo server e ogni editor lo otteneva. La misura del successo non era l’eleganza, era il fatto che il numero di integrazioni smetteva di moltiplicarsi. Qui segue la stessa cosa: il valore è nel numero di implementazioni, non nel design. Un protocollo che due prodotti parlano è un formato dati con cerimonia extra.

I messaggi MCP sono JSON-RPC 2.0. Una richiesta è un oggetto con jsonrpc, un id, un method e params opzionali; una risposta porta lo stesso id e o result o error; una notifica è una richiesta senza id e non riceve risposta. La specifica aggiunge tre vincoli: l’id deve essere una stringa o un numero e non deve essere null, non deve collidere con un’altra richiesta ancora in volo, e ogni risultato deve portare un campo resultType.²

Sul transport stdio — quello usato dal comando sopra — la regola di framing è una riga per messaggio:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

Quest’ultima clausola è il modo più comune in cui un server fatto in casa si rompe, e si rompe in silenzio: un console.log fuori posto, una progress bar, un warning di deprecazione da una dependency, e il parser a righe del client incontra qualcosa che non è JSON. La via di fuga è nella stessa sezione: il server può scrivere qualunque cosa voglia su stderr, e il client non dovrebbe trattarlo come errore. Il reference server sopra stampa Starting default (STDIO) server... a ogni avvio, su stderr, ed è per questo che la pipe ha comunque funzionato.

L’altro transport standard è Streamable HTTP: ogni messaggio è un POST a un singolo endpoint, e la risposta è o un oggetto JSON o uno stream di Server-Sent Events scoped alla richiesta — il wire format che il Capitolo 14 ha parsato a mano. Le semantiche sono identiche su entrambi, perché un transport è un binding: definisce framing e consegna, non significato.⁴

Il comando sopra ha inviato tools/list e nient’altro. Secondo la revisione attuale quella richiesta è malformata, e un server conforme deve rifiutarla.

Dal 2026-07-28, MCP è un protocollo stateless, e la specifica lo dichiara senza sfumature:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

Quindi ogni richiesta porta la propria versione del protocollo e le proprie capability del client, in un oggetto riservato _meta dentro params. Due di quei campi sono richiesti in ogni singola richiesta; una richiesta a cui manchi uno dei due è malformata e il server deve rispondere -32602:²

Scritta per intero, una tools/list corretta è questa — ed è l’ultima volta che questo capitolo mostra i metadati per intero, perché da qui in poi sono su ogni richiesta:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

L’oggetto delle capability è la negoziazione. Non c’è più un passaggio di negoziazione separato: il client dichiara cosa può fare in ogni richiesta, il server dichiara cosa può fare nel risultato, e nessuna delle due parti può usare una feature che l’altra non ha dichiarato. Un server che ha bisogno di una capability non dichiarata dal client deve rispondere -32021 e nominare la capability mancante in data.requiredCapabilities. Un server che non parla la versione richiesta deve rispondere -32022 ed elencare le versioni che parla.²

I client che vogliono la risposta in anticipo possono chiederla: server/discover è una RPC obbligatoria che restituisce versioni supportate, capability, identità e un blocco opzionale di instructions in un solo round trip.⁵ Chiamarla è opzionale. Implementarla no.

Il comando ha funzionato. Secondo la revisione attuale non avrebbe dovuto, e il motivo per cui lo ha fatto merita una misurazione più che un paragrafo, perché in una riga racconta lo stato dell’intero ecosistema.

Sonda il reference server nel modo in cui la specifica dice a un client moderno di sondare:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

Questo è il terzo ramo della regola di compatibilità: un DiscoverResult significa moderno, un errore moderno riconosciuto significa moderno-ma-versione-sbagliata, e qualunque altra cosa — incluso -32601 — significa legacy, torna all’handshake initialize.³ Quindi fallo, chiedendo la revisione attuale:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

Il client ha chiesto 2026-07-28 e il server ha risposto 2025-11-25. Il 7 settembre 2026, il reference server ufficiale — package npm @modelcontextprotocol/server-everything, versione 2026.8.31, pubblicato il 31 agosto 2026 — non implementa la revisione attuale. Né, guardando le date, lo fa l’SDK TypeScript su cui è costruito: la release 1.30.0 è uscita il 27 luglio 2026, il giorno prima della revisione.

Leggi la conseguenza, non il gossip. Quasi tutto ciò che è stato scritto su MCP descrive un protocollo con un handshake initialize, una sessione, una richiesta roots/list che il server invia al client, e un transport HTTP+SSE. Tutte e quattro le cose sono sparite o stanno sparendo. Quando leggi qualsiasi cosa su MCP, inclusa questa pagina, la prima cosa da cercare è un numero di revisione.

E il motivo per cui il primissimo comando ha funzionato è dichiarato nella specifica come un rischio, non una feature:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Misurato: inviare tools/list a quel server senza alcun handshake restituisce l’intero catalogo. Un metodo che avrebbe dovuto essere rifiutato è stato servito, ed è esattamente per questo che la specifica dice di sondare prima con server/discover anche quando supporti solo versioni moderne.

MCP ha tre parti, e la distinzione tra le prime due è quella che le persone collassano:

Server. Un processo o un servizio che espone risorse, tool e prompt. Può essere locale o remoto, opera in modo indipendente, e il suo intero compito è un’area focalizzata.⁶

Quella regola «esattamente un server» non è contabilità. È ciò che rende implementabile il principio di design qui sotto, e questa è la frase da portare via dalla specifica se ne porti via una sola:

Servers should not be able to read the whole conversation, nor "see into" other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

Ribalta il modello mentale con cui arrivano quasi tutti. Un server meteo che colleghi al tuo assistente non vede cosa hai chiesto. Vede un tools/call con gli argomenti scelti dal modello, e nient’altro: non i turni precedenti, non il tuo system prompt, non i risultati restituiti dal server calendario un attimo prima. Se due server devono cooperare, l’host porta un valore dall’uno all’altro, deliberatamente, perché il modello lo ha chiesto. È per questo che l’isolamento è la proprietà di sicurezza su cui si appoggia il Capitolo 30: un server compromesso ha un blast radius piccolo e definito, e ampliarlo richiede la cooperazione dell’host.

Il primo comando ha chiesto a quel server i tool e ne ha ottenuti tredici. Fagli le altre due domande e risponde anche a quelle: resources/list ne restituisce sette, prompts/list ne restituisce quattro. Nessuno di questi è apparso, perché niente lo ha chiesto. Questo ci porta alla spina dorsale didattica di MCP, presente nella specifica come una tabella che quasi nessuno cita:

Non «tre modi per esporre una capability». Tre risposte a chi decide che questo accade. Il modello decide di chiamare un tool. L’applicazione decide di allegare una risorsa. La persona decide di eseguire un prompt. Se sbagli questo, la feature funziona comunque, ma funziona nel momento sbagliato e per il motivo sbagliato.

Il modo più chiaro per sentirlo è un calendario. Ecco un server che espone lo stesso calendario tre volte, una per ciascuna primitive, in cento righe di semplice Node senza dipendenze:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

Eseguilo e interrogalo in tutti e tre i modi. Output reale, un messaggio per riga sul wire, qui mandato a capo per la pagina, con la richiesta _meta e il blocco di identità del server omessi:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

Tre metodi, tre forme, un calendario. Ora il punto:

Quasi tutti trasformano tutte e tre queste cose in tool. Il risultato è un catalogo in cui una lettura che l’applicazione avrebbe dovuto allegare in silenzio compete per l’attention del modello con una scrittura che richiede approvazione, e in cui l’unica cosa per cui una persona voleva un pulsante è sepolta in uno schema. Non costa niente farlo bene, e si decide prima di scrivere una riga.

Il tool calendario ha un argomento richiesto, title, e uno opzionale, startsAt. Chiedigli di creare un evento senza data, e torna qualcosa di interessante:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

Il server non ha inviato una richiesta. Ha risposto a quella che gli era stata data, con resultType: "input_required" e una descrizione di ciò che gli serve ancora. Il client raccoglie la risposta dalla persona, e poi reinvia la chiamata originale — con un nuovo id, portando inputResponses e riecheggiando l’requestState opaco:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

Queste sono le Multi Round-Trip Requests, introdotte nella revisione attuale, e hanno sostituito il design precedente in cui i server inviavano richieste JSON-RPC ai client. La specifica dei transport ora enuncia la regola in modo netto: «servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses».⁴ C’è una sola direzione dell’iniziativa, e appartiene all’host.

Due feature lato client viaggiano su quel meccanismo, e una delle due ha un nome che ti farà inciampare.

Elicitation è il server che chiede qualcosa alla persona: un form con un JSON Schema volutamente ristretto — oggetti piatti, proprietà primitive, niente annidamento — così qualunque client può renderizzarlo senza un layout engine. Porta una regola rigida: i server non devono usare la modalità form per chiedere «passwords, API keys, access tokens, or payment credentials», e devono usare la modalità URL per quelle cose, che manda l’utente a una pagina che il client non legge mai.⁷

Sampling è il server che chiede una generazione al modello dell’host, così un server può essere intelligente senza detenere una API key. Ed ecco l’avviso di vocabolario, perché questa parola significa già qualcos’altro in questo corso: questo non è il sampling del Capitolo 17. Qui non c’entra niente la temperature, il top-p o la forma di una distribuzione di probabilità. È una chiamata annidata a un modello che viaggia all’indietro attraverso un protocollo.

C’è una seconda ragione per non usarlo con leggerezza: a partire da questa revisione, sampling è deprecato, insieme a roots e logging, sotto SEP-2577, con una migrazione suggerita in modo brutale: «integrate directly with LLM provider APIs instead of Sampling».⁸ L’idea non è fallita tecnicamente; non è riuscita a giustificare la sua superficie, e un protocollo che può rimuovere cose è più sano di uno che non può.

La statelessness sembra un dettaglio di wire format finché non la testi. Prendi lo scambio di tre messaggi sopra ed esegui ogni messaggio in un processo separato: un node calendar.mjs fresco, nessuna memoria condivisa, niente portato oltre:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

Il processo B, che non aveva mai visto la domanda, ha completato una chiamata multi-round-trip iniziata dal processo A. Questo è il punto di requestState: la continuation viaggia nel messaggio, quindi niente dipende dal fatto che il processo sia lo stesso.

Il processo C è il fallimento. L’evento è stato creato e non è lì: perché il server giocattolo mantiene EVENTS in un array a livello di modulo, e un array a livello di modulo è stato della connessione. La nota della specifica nomina l’errore con precisione:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

La correzione prescritta non è una sessione. È un handle esplicito: un tool di creazione restituisce un identificatore opaco, e ogni chiamata successiva lo prende come un argomento ordinario. Il protocollo non ne ha alcun concetto: «from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls».⁹ Il che mette il modello incaricato di portarlo, e il server incaricato di validare che questo chiamante sia autorizzato a usarlo in ogni singola chiamata, perché un handle è un nome e non un permesso.

Ogni tool esposto da un server è uno schema che entra nel tuo prompt a ogni richiesta, e il Capitolo 24 ha misurato cosa fa a una context window. MCP aggiunge una seconda voce di costo che è facile perdere, quindi vale la pena contarle entrambe sul reference server sopra.

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

Due osservazioni. La prima è aritmetica: collega cinque server di queste dimensioni e circa ottomila token della tua context window sono occupati a ogni turno, per sempre, che il modello ne usi qualcuno oppure no. Questo è il meccanismo dietro la riduzione da 150.000 a 2.000 citata dal Capitolo 24, e il motivo per cui esiste la scoperta dei tool just-in-time.

La seconda è una nota di sicurezza travestita da contabilità. instructions è testo in linguaggio naturale, scritto dall’autore del server, che atterra nel prompt dell’host, e le descrizioni dei tool accanto sono la stessa cosa. La specifica dice cosa farne nei suoi principi di sicurezza: annotazioni e descrizioni dei tool «should be considered untrusted, unless obtained from a trusted server», e gli host «must obtain explicit user consent before invoking any tool».¹ Collegare un server MCP non è aggiungere una dependency. È concedere a uno sconosciuto 1.619 token del tuo system prompt e il diritto di essere chiamato. Il Capitolo 30 è ciò che accade quando quello sconosciuto è ostile.

Tutto in questa sezione è vero per la revisione del protocollo 2026-07-28, quella attuale, letta il 7 settembre 2026. Le revisioni sono datate YYYY-MM-DD e la data è l’ultima volta in cui è stata fatta una modifica non retrocompatibile.¹⁰ Il documento normativo è un file TypeScript, schema/2026-07-28/schema.ts; il JSON Schema accanto è generato da quello, ed è per questo che qui la specifica viene letta in TypeScript e perché insegnare MCP da qualunque altra cosa significa insegnare una traduzione.

Il cambiamento di governance sotto quella tabella conta più di qualsiasi singola riga. Questa revisione ha adottato una feature lifecycle and deprecation policy: le feature sono Active, Deprecated o Removed, una feature deprecata documenta il suo percorso di migrazione e resta nella specifica per almeno dodici mesi prima di diventare candidata alla rimozione, e c’è un registro che elenca tutto ciò che attualmente è nello stato Deprecated.⁸ Prima di quella policy, «deprecated» in un protocollo AI significava qualunque cosa dicesse l’ultimo blog post. Ora significa una data.

Questo è il vocabolario dell’intero blocco in un posto solo.

Due di queste meritano una frase ciascuna, perché è lì che vive davvero la confusione.

MCP rispetto ad A2A non è una rivalità, e lo dicono entrambe le specifiche. La documentazione A2A traccia la linea in base a cosa c’è dall’altra parte: MCP «defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API», dove un tool esegue «specific, often stateless, functions»; A2A riguarda gli agent, «more autonomous systems» che «reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues». Il suo riassunto è la frase da ricordare: «A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.»¹¹ I due si annidano: un’applicazione usa A2A per raggiungere altri agent, e ogni agent usa MCP per raggiungere i propri tool. Il Capitolo 25 ha tracciato quella linea dentro un solo processo, tra chiedere a un sub-agent e passargli la conversazione; A2A la traccia tra organizzazioni.

MCP rispetto ad ACP è un confronto con una premessa scaduta, ed è esattamente per questo che vale la pena rispondervi. L’Agent Communication Protocol era uno standard aperto separato per la messaggistica agent-to-agent. La sua stessa documentazione ora si apre con l’avviso: «ACP is now part of A2A under the Linux Foundation!»¹² La risposta onesta a «MCP o ACP?» nel settembre 2026 è che la domanda ha un’opzione in meno rispetto a quanto suggeriscano le pagine che rankano per essa.

E il confronto che le persone chiedono di più, mcp vs api, ha la risposta meno interessante: MCP è una API. Ciò che aggiunge non è potenza, sono convenzioni: un set fisso di nomi di metodi, una chiamata di discovery, una gerarchia di controllo sulle primitive, e un modello di isolamento. Rinunci alla libertà di progettare la tua interfaccia e ottieni ogni host che parla il protocollo, che è il trade-off che ogni protocollo ha sempre offerto.

Ora puoi leggere la specifica senza un traduttore, distinguere una risorsa da un tool da un prompt in base a chi ne ha il controllo, digitare una richiesta a mano quando una libreria client ti sta mentendo, e datare qualunque articolo su MCP leggi in base a quali feature deprecate insegna ancora come attuali.

Quello che non hai fatto è spedirne uno. Il Capitolo 27 scrive lo stesso server due volte: TypeScript e Python, fianco a fianco, perché MCP è l’unico territorio davvero bilingue di questo corso e i numeri lo dicono in entrambe le direzioni. Copre correttamente i due transport live, l’inspector, il packaging, e la metà del protocollo che questo capitolo ha lasciato deliberatamente da parte: authorization. Perché nel momento in cui il tuo server è remoto invece che un sottoprocesso sul tuo laptop, il client di uno sconosciuto presenterà un token, e la regola della specifica su cosa puoi farne è insolitamente severa.

Il che solleva la domanda a cui il prossimo capitolo deve rispondere, e non è una domanda amichevole: se un token arriva al tuo server ed è stato emesso per l’audience di qualcun altro, che cosa ti impedisce esattamente di inoltrarlo?

Ogni citazione, nome di metodo, codice di errore e regola in questo capitolo è stata letta dalla specifica Model Context Protocol, revisione 2026-07-28, il 7 settembre 2026. Ogni trace è stato prodotto localmente su Node 22: il server calendario giocattolo è di 101 righe senza dipendenze, e il reference server è il package npm pubblicato nominato sotto. Nessuna API a pagamento è stata chiamata per scrivere questo capitolo: qui nulla richiede un modello, che è già il punto.

Le misurazioni: @modelcontextprotocol/server-everything@2026.8.31, pubblicato il 31 agosto 2026, costruito su @modelcontextprotocol/sdk@1.30.0, pubblicato il 27 luglio 2026 — un giorno prima della revisione descritta da questo capitolo. Risponde a server/discover con -32601, negozia 2025-11-25 quando gli viene chiesto 2026-07-28, e serve tools/list senza alcun handshake. Il suo catalogo è di 13 tool in 7.663 byte; i conteggi dei token sono o200k_base tramite tiktoken, sopra name, description e inputSchema di ogni definizione, che è ciò che un provider renderizza nel tuo prompt e non ciò che pesa il frame JSON-RPC.

Anthropic, Code execution with MCP: building more efficient agents, 4 novembre 2025, è la fonte della cifra da 150.000 a 2.000, citata e usata nel Capitolo 24 e qui solo richiamata.