HTTP è per gli umani, MCP per gli agenti

Da tempo seguo con curiosità i passi del Model Context Protocol (MCP), cercando di capire meglio come si inserisce nel mondo degli agenti AI. Non è una novità per me, ma finora faticavo a mettere insieme tutti i pezzi in modo ordinato.

Poi ho trovato questo articolo di glama.ai, che riesce nell’impresa: spiegare la differenza tra MCP e API in modo chiaro, pragmatico e senza troppi tecnicismi.

Ma quindi, MCP vs API: che differenza c’è davvero?

È una domanda che mi ero già posto, ma che ora riesco a raccontare con più strumenti. Questo post nasce da lì: una rilettura e adattamento in italiano, con lo spirito di chi esplora e prova a condividere ciò che scopre lungo il cammino.

MCP: non un’API, ma un protocollo

Le API HTTP (REST, GraphQL…) sono flessibili, forse troppo. Possono avere parametri in mille posti, rispondere in mille formati. Anche con OpenAPI, che pure prova a mettere ordine, resta un problema di fondo: ogni servizio fa un po’ a modo suo. Per gli umani è tollerabile — leggiamo la documentazione, proviamo, sbagliamo e correggiamo — ma per un agente AI, questa variabilità è un ostacolo enorme.

MCP (Model Context Protocol) nasce proprio da questa osservazione. L’idea è semplice ma potente: non serve solo documentare le API esistenti, serve definire un protocollo chiaro e uniforme, progettato per essere usato da agenti LLM. MCP si basa su JSON-RPC 2.0, uno standard esistente e ben supportato, e introduce alcune convenzioni:

ogni tool ha uno schema d’ingresso e uno di uscita, rigorosamente JSON;
la scoperta degli strumenti disponibili avviene in tempo reale (tools/list);
le chiamate sono bidirezionali, il server può fare domande all’agente;
può girare in ambienti locali, senza HTTP, usando stdio o WebSocket.

Questa combinazione di caratteristiche lo rende prevedibile per un LLM: non deve “indovinare” come invocare qualcosa, può semplicemente scegliere uno strumento da una lista, con parametri già noti. È una differenza sottile ma profonda: documentare un’interfaccia (come fa OpenAPI) è diverso dal prescriverla (come fa MCP).

API vs MCP: una tabella per chiarire

Aspetto	API tradizionali	MCP
Scoperta	statica (docs, SDK)	dinamica (`tools/list`)
Esecuzione	LLM scrive richieste HTTP	LLM sceglie strumenti, esecuzione deterministica
Comunicazione	client-server	bidirezionale (notifiche, prompt, interazioni)
Task umani	frammentati su più endpoint	incapsulati in uno strumento completo
Locale	sempre HTTP, cors, auth	può girare in locale, via `stdio`

Un esempio pratico

Compito: trova tutti i pull request su GitHub che parlano di sicurezza e genera un report.

Con REST: l’agente deve imparare a paginare manualmente attraverso le API di GitHub, gestire il rate limiting, autenticarsi correttamente, interpretare il formato della risposta (che può cambiare nel tempo), e capire come unire più chiamate in un dataset coerente. Ogni errore nel parsing o nei parametri rischia di far fallire l’intera catena.
Con MCP: l’agente ha a disposizione un tool predefinito come github.search_issues_and_prs, con uno schema di input chiaro e validato. Basta passare un oggetto del tipo { query: "security", type: "pr" } e il server MCP si occupa della chiamata, dell’autenticazione, del rate limiting, della paginazione e della costruzione del risultato finale. Il modello riceve una risposta strutturata, sempre nel formato MCP. Così può concentrarsi sul task reale: leggere, sintetizzare e generare il report.

Questa separazione tra “interazione con il mondo” (che sta lato MCP server) e “ragionamento e linguaggio” (che resta lato modello) è uno dei punti chiave dell’approccio MCP. E rende possibile riutilizzare gli strumenti in modo modulare e affidabile, senza richiedere al modello di reinventare ogni volta l’interfaccia verso l’esterno.

E ora?

Trovo l’idea del MCP affascinante. In fondo, gli agenti AI sono bravi a prendere decisioni e coordinarsi, ma non a improvvisare parsing su JSON ambigui. Dare loro un protocollo chiaro, scoperta dinamica e interazione locale mi sembra un passo verso strumenti davvero utili.

Mi piace anche il fatto che MCP non voglia sostituire le API esistenti, ma piuttosto avvolgerle con uno strato più amichevole per gli agenti. È una scelta pragmatica: costruire un ponte invece di chiedere a tutti di ricostruire le fondamenta. MCP si pone come interprete, non come rivoluzionario.

In un certo senso, mi ricorda quello che è successo con GraphQL rispetto a REST: stesso backend, nuovo modo di parlare. Ma con una differenza fondamentale: mentre GraphQL è ancora pensato per umani sviluppatori, MCP nasce esplicitamente per LLM e agenti autonomi.

Questa distinzione mi sembra cruciale. Significa progettare le interfacce non più solo per esseri umani davanti a una tastiera, ma anche per sistemi che ragionano in contesto, imparano e prendono decisioni. Un cambio di prospettiva che potrebbe aprire a forme nuove di collaborazione uomo-macchina.

Vorrei approfondire. Proverò a scrivere piccoli tool MCP per uso personale: magari qualcosa che interagisce con file locali, o che estrae dati da fonti già esistenti. E chissà: magari anche questo sito potrebbe esporre le sue capacità via MCP, per permettere ad agenti di esplorarlo, suggerire contenuti o rispondere alle domande di chi — come te — è capitato a leggere questo blogpost.

👉 Guarda anche il video “What the hell is MCP?”

Fammi sapere che ne pensi!