API e MCP: le differenze

Il punto più importante da capire: MCP non sostituisce le API, le usa. Un server MCP è quasi sempre un traduttore: da un lato parla il protocollo MCP con l'assistente AI, dall'altro chiama le normali API REST del gestionale, del CRM o del servizio esterno.

La catena completa è questa: l'utente chiede qualcosa in linguaggio naturale, il modello sceglie uno strumento MCP, il server MCP traduce la chiamata in una o più richieste API, il sistema risponde, e la risposta risale la catena fino a diventare una frase comprensibile. Ecco perché la qualità delle API sottostanti resta decisiva: un server MCP costruito sopra API lente o mal progettate erediterà tutti i loro problemi. Prima si mettono in ordine le fondamenta, poi si aggiunge il livello AI.

Per chi conosce la storia del software, MCP suona familiare — e non è un caso.

• Il formato di trasporto di MCP è letteralmente JSON-RPC 2.0, un protocollo del 2010 erede diretto di XML-RPC (1998): una busta minimale con metodo, parametri e id, indipendente dal canale di trasporto. Niente di nuovo sotto il sole: è stata scelta proprio perché leggera, bidirezionale e collaudata.
• La scoperta dei servizi ricorda SOAP: negli anni 2000 il WSDL era il contratto machine-readable che descriveva le operazioni di un web service, e UDDI doveva essere il registro globale dove i client li scoprivano dinamicamente. Quando un server MCP risponde a tools/list con l'elenco dei suoi strumenti e i loro JSON Schema, sta facendo concettualmente ciò che faceva il WSDL.
• Anche REST ci aveva provato con HATEOAS: risposte che contengono i link alle azioni possibili, così il client "naviga" l'API scoprendola. Sulla carta elegante, in pratica quasi mai usato.

Perché quelle tecnologie fallirono nella scoperta dinamica e MCP invece decolla? Perché mancava il client intelligente. UDDI e HATEOAS presupponevano un consumatore capace di leggere un contratto mai visto prima e decidere da solo come usarlo — ma un programma tradizionale non può: il codice va comunque scritto da un umano, quindi tanto vale leggere la documentazione. Il modello linguistico è esattamente il client che mancava: legge le descrizioni degli strumenti a runtime e li orchestra da solo. In un certo senso, MCP realizza il sogno della SOA degli anni 2000 — contratti autodescrittivi e binding dinamico — vent'anni dopo, con JSON al posto delle buste XML e senza lo stack WS-*.

Se il flusso è fisso e ripetitivo, l'integrazione API classica resta la scelta giusta: più semplice, più economica, più prevedibile.

• Sincronizzare il gestionale con l'e-commerce (prodotti, prezzi, giacenze).
• Accettare pagamenti online tramite Stripe, PayPal o Nexi.
• Inviare le fatture elettroniche allo SDI.
• Aggiornare automaticamente lo stato spedizioni dal corriere.
• Raccogliere i lead del sito dentro il CRM.

In questi casi non c'è nessuna decisione da prendere di volta in volta: la macchina deve fare sempre la stessa cosa, e il codice programmato è imbattibile per affidabilità e costi. Aggiungere un livello AI qui non porterebbe alcun vantaggio.