MCP vs API per agenti AI

Il malinteso

La frase MCP vs API suggerisce una sostituzione, e il protocollo invita alla lettura perché sembra un'API: un endpoint HTTPS, JSON, un elenco di operazioni chiamabili. Sotto, è JSON-RPC 2.0 su Streamable HTTP, il che significa che è un'API HTTP con una forma di messaggio fissa. Ciò che standardizza non è come raggiungere un sistema, ma come un'applicazione AI chiede a un sistema cosa può fare, come chiama quelle cose con un modello che sceglie gli argomenti, come gli errori vengono restituiti affinché il modello possa auto-correggersi e come la persona dietro il modello è autorizzata. Un'API REST non standardizza nulla di tutto ciò, perché non ne aveva mai bisogno: i suoi chiamanti erano programmi i cui autori leggevano la documentazione una sola volta.

Ogni serio server MCP per un sistema aziendale è uno strato sopra il livello di servizio o API esistente di quel sistema. La domanda quindi non è quale costruire, poiché hai bisogno dell'API in ogni caso, ma quale dare a un agente.

Cosa offre un'API a un agente e cosa non offre

Dai a un modello un'API REST e può usarla, con aiuto. L'aiuto è il problema. Qualcuno deve trasformare gli endpoint in definizioni di funzione che il modello può vedere, nel formato che il fornitore del modello si aspetta; i formati di chiamata delle funzioni di Claude e OpenAI sono simili ma non identici. Qualcuno deve scrivere il ciclo che prende la funzione scelta dal modello, chiama l'endpoint con le credenziali corrette e restituisce la risposta. Qualcuno deve decidere come gli errori raggiungono il modello, perché un 422 con un corpo di validazione non è qualcosa che un modello legge bene a meno che non venga convertito. E qualcuno deve risolvere l'autorizzazione, perché una chiave API nell'ambiente dell'agente rende ogni azione simile allo stesso account di servizio, non alla persona che chiede.

Niente di tutto ciò è difficile per un sistema e un agente, motivo per cui era all'avanguardia prima del protocollo. Scalano male. Ogni accoppiamento di un prodotto agente e un sistema aziendale è su misura, le definizioni si allontanano dall'API e non c'è modo per un utente di Claude o ChatGPT di connettere un sistema da solo. L'API rimane eccellente per ciò per cui è stata costruita: chiamate program-to-program ad alto volume, operazioni in blocco, webhook e integrazioni in cui la logica è fissa e il chiamante è codice.

Cosa aggiunge MCP

Il protocollo risponde a ciascuna di queste lacune con una regola che ogni client implementa una volta. Scoperta: tools/list restituisce gli strumenti con nomi, descrizioni e JSON Schemas a runtime, quindi il prodotto agente non ha bisogno di conoscenze pregresse e l'elenco può cambiare man mano che le app vengono installate o i ruoli cambiano. Invocazione: tools/call porta un nome e argomenti; il risultato porta contenuto che il modello legge, contenuto strutturato opzionale e un isError flag che dice al modello di correggere e riprovare piuttosto che arrendersi. Autorizzazione: OAuth 2.1 con il token legato al server e alla persona, quindi l'elenco degli strumenti e ogni chiamata possono essere limitati a chi sta chiedendo. Consenso: le annotazioni consentono a un server di dire che uno strumento è di sola lettura, distruttivo o idempotente, e i client li usano per decidere quando confermare; un server può anche restituire un risultato che richiede input per porre una domanda alla persona durante la chiamata. Ecco una chiamata e la sua risposta, mentre un client le invia e le riceve.

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "recordPayment",
    "arguments": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "amount": 4850,
      "payment_date": "2026-09-18",
      "payment_reference": "BACS 41877"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 12,
  "result": {
    "content": [
      { "type": "text", "text": "Payment recorded against INV-1057. Amount paid 4850.00 of 4850.00; status is now paid." }
    ],
    "structuredContent": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "number": "INV-1057",
      "amount_paid": 4850,
      "status": "paid"
    },
    "isError": false
  }
}

Una richiesta di strumenti/chiamata e risultato per uno strumento di pagamento Sois. La stessa operazione tramite l'API REST richiederebbe una definizione di funzione scritta per il fornitore del modello, un ciclo per inoltrare la chiamata e una decisione su come presentare la risposta; qui il client sa già come fare tutte e tre le cose.

C'è un costo. Il protocollo è più giovane di REST e si sta ancora muovendo: la revisione del 2026-07-28 ha rimosso le sessioni a livello di protocollo e ha cambiato il modo in cui i server chiedono input ai client, e i client sono tenuti a tornare indietro per i server sulla revisione precedente. Gli elenchi degli strumenti consumano contesto, quindi i grandi server necessitano di caricamento differito o ricerca di strumenti sul lato client. E un chiamante guidato dal modello è più lento e meno prevedibile di un programma, motivo per cui non lo useresti per una sincronizzazione notturna.

Quando ciascuno è giusto

Come i principali prodotti per agenti consumano ciascuno oggi

Le API dei fornitori risolvono il confronto per chiunque stia costruendo il proprio agente, perché entrambi ora accettano un server MCP come strumento di prima classe insieme alla chiamata di funzione ordinaria. Sul lato di Claude, i connettori personalizzati nelle app web e desktop e Cowork prendono un URL del server e completano OAuth nell'app; Claude Code aggiunge un server con un comando; e il connettore MCP dell'API Messaggi (beta, dietro il mcp-client-2025-11-20 header) richiede un mcp_servers ingresso e un mcp_toolset, supports tool calls only, and expects you to supply the access token. On the OpenAI side, ChatGPT's developer mode connects a remote server with OAuth or no authentication and asks for confirmation on write actions by default; the Responses API takes a tool of type MCP con un server_url, a richiedere approvazione impostazione e un'opzione strumenti consentiti elenco, restituisce mcp_list_tools e mcp_call elementi e funziona con Streamable HTTP o il trasporto SSE più vecchio.

La chiamata di funzione ordinaria rimane disponibile in entrambe le API ed è il percorso per un sistema solo REST: definisci le funzioni, chiami l'API, restituisci i risultati. La differenza è interamente in chi mantiene il ponte. Con MCP il proprietario del sistema mantiene un server e ogni cliente beneficia; con la chiamata di funzione ogni costruttore di agenti mantiene le proprie definizioni rispetto all'API.

Il modello che funziona: API sotto, MCP sopra

I sistemi che riescono in questo espongono entrambi e li instradano attraverso lo stesso livello di autorizzazione. Sois è una delle implementazioni del modello. Lo spazio di lavoro ha un livello di servizio che ogni schermata utilizza. Il suo server MCP pubblica quel livello come strumenti a un URL, filtrato dal ruolo del chiamante e controllato nuovamente ad ogni chiamata, con OAuth per i connettori e un token bearer per gli script. Lo stesso spazio di lavoro accetta richieste in linguaggio semplice a un endpoint separato per i chiamanti senza agente, dove l'agente stesso dello spazio di lavoro fa il ragionamento e risponde tramite webhook o polling. E per la direzione in uscita, il suo stesso agente può chiamare server MCP esterni attraverso un gateway, sotto la stessa governance di autorizzazione, richiesta e negazione.

Niente in quel design richiede una scelta. L'API serve programmi, il server MCP serve modelli, il gateway serve chiamanti senza nessuno dei due, e un modello di autorizzazione governa tutti e tre. Quando qualcuno chiede quale costruire, la risposta onesta è che l'API è un dato di fatto e il server MCP è ciò che rende il sistema utilizzabile dagli agenti che le persone hanno già.

Domande che le persone pongono

Questo articolo viene revisionato quando i prodotti che descrive cambiano. Prossima revisione programmata: 4 dicembre 2026.