MCP vs API: quando usare MCP o HTTP diretto

Quando colleghi un agente AI a strumenti e API esterni, ci sono due approcci principali: usare Model Context Protocol (MCP) come livello di astrazione, oppure chiamare direttamente un’API tramite HTTP. Entrambi funzionano. Fanno scelte diverse in termini di flessibilità, complessità, prestazioni e portabilità.

Questo articolo confronta i due approcci con esempi di codice concreti, analisi della latenza e un framework decisionale per scegliere tra i due.

I due approcci

Integrazione HTTP diretta

L’applicazione AI (o il suo backend) chiama direttamente le API esterne usando richieste HTTP standard. Lo sviluppatore scrive il codice per costruire le richieste, gestire l’autenticazione, analizzare le risposte e passare i risultati all’LLM.

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

Integrazione MCP

L’applicazione AI si connette a un server MCP che incapsula l’API esterna. L’applicazione usa il protocollo MCP per scoprire gli strumenti disponibili, chiamarli per nome e ricevere i risultati. Il server MCP gestisce le chiamate HTTP effettive all’API esterna.

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

La differenza principale: con HTTP diretto, l’applicazione AI possiede il codice di integrazione dell’API. Con MCP, lo possiede il server MCP, e l’applicazione AI si limita a chiamare gli strumenti per nome.

Puoi avere la parte MCP di questo diagramma senza creare il server: Quickchat AI ospita un server MCP streamable-HTTP per ogni AI Agent, e trasformare il tuo agente in un server MCP consiste nell’incollare un URL nell’app AI.

Confronto del codice

Confrontiamo entrambi gli approcci con un esempio pratico: recuperare i repository di un utente GitHub.

Integrazione HTTP diretta

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Recupera i repository di un utente GitHub."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

Per integrare questo codice con un LLM, ti servono anche:

• Una definizione dello strumento nel formato previsto dall’LLM (schema di function calling di OpenAI, schema di tool use di Claude, ecc.)
• Codice per analizzare la tool call dell’LLM, invocare get_user_repos e reinserire il risultato nella conversazione
• Gestione degli errori per errori HTTP, rate limit e scadenza dell’autenticazione

Server MCP

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """Recupera i 10 repository aggiornati più di recente per un utente GitHub.

    Args:
        username: nome utente GitHub da cercare
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "sconosciuto"
            lines.append(f"- {r['name']} ({lang}, {stars} stelle): {r['description'] or 'Nessuna descrizione'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

La versione MCP incapsula la chiamata API, l’autenticazione e la formattazione della risposta all’interno del server. Qualsiasi client compatibile con MCP può usare questo strumento senza sapere nulla dell’API GitHub.

Cosa cambia per l’applicazione AI

Confronto delle prestazioni

MCP aggiunge un livello tra l’applicazione AI e l’API esterna. Questo livello ha un costo.

Latenza

Per il trasporto stdio (server MCP locali), l’overhead è minimo: avvio del processo all’inizio (una tantum, in genere sotto i 100ms) e comunicazione inter-processo per messaggio (meno di un millisecondo sui sistemi moderni). In pratica, la chiamata all’API esterna domina la latenza totale.

Per i server MCP remoti (Streamable HTTP o SSE), aggiungi un round-trip HTTP tra il client e il server MCP, più il round-trip HTTP del server MCP verso l’API esterna. Se il server MCP e l’API esterna sono nella stessa posizione, questo overhead è ridotto (pochi millisecondi). Se si trovano in regioni diverse, si somma. Tuttavia, il trasporto raramente è ciò che l’utente percepisce: durante la creazione di un agente di help center sul server MCP ospitato da Notion, 248 tool call hanno avuto una media di 2,7 secondi ciascuna, quasi tutto dovuto alla ricerca di Notion e al rendering delle pagine, non al passaggio intermedio.

Per la maggior parte dei casi d’uso degli agenti AI, in cui l’inferenza dell’LLM richiede 500ms-5s, l’overhead di MCP è trascurabile.

Gestione delle connessioni

HTTP diretto: la tua applicazione gestisce le connessioni a ogni API esterna. Questo significa gestire pool di connessioni, logica di retry e rate limiting per ogni API.

MCP: la tua applicazione gestisce una connessione per ogni server MCP. Il server gestisce la connessione all’API esterna. Se hai 10 strumenti distribuiti su 3 server MCP, gestisci 3 connessioni invece di 10.

Quando usare MCP

Più integrazioni di strumenti

Se la tua applicazione AI deve connettersi a 5+ servizi esterni, MCP riduce il carico di integrazione. Invece di scrivere e mantenere client API personalizzati per ogni servizio, ti connetti a server MCP (molti dei quali sono disponibili come progetti open source).

Portabilità tra piattaforme AI

Se crei server MCP per i tuoi strumenti, questi server funzionano con qualsiasi client MCP: Claude Desktop, Cursor, Windsurf, applicazioni personalizzate e piattaforme come Quickchat AI. Con HTTP diretto, dovresti reimplementare le definizioni degli strumenti per il formato di ogni piattaforma.

Scoperta dinamica degli strumenti

MCP supporta la scoperta degli strumenti a runtime tramite tools/list. Un’applicazione AI può connettersi a un server e apprendere quali strumenti sono disponibili senza alcuna configurazione hardcoded. Questo è utile negli scenari in cui gli strumenti cambiano spesso o sono configurabili dall’utente.

Separazione delle responsabilità

Se team diversi possiedono strumenti diversi, MCP fornisce un confine chiaro. Il team che possiede l’integrazione Salesforce crea e mantiene il server MCP Salesforce. Il team dell’applicazione AI si connette a quel server senza dover comprendere l’API di Salesforce. Gli aggiornamenti all’API di Salesforce vengono gestiti nel server MCP senza toccare l’applicazione AI.

Quando usare HTTP diretto

Una o due integrazioni

Se il tuo agente AI deve chiamare solo un’API (per esempio, una lookup su database), l’overhead di eseguire un server MCP non è necessario. Una chiamata HTTP diretta è più semplice e ha meno componenti.

Inoltre non devi scrivere la richiesta a mano. Il builder API Action in plain-English legge una REST API documentata, genera metodo, URL, parametri e descrizione, poi ti permette di testare la risposta reale prima di abilitarla.

Massimo controllo sulle richieste

I server MCP astraggono i dettagli HTTP. Se ti serve controllo preciso sulla costruzione della richiesta (header specifici, parametri di query, firma della richiesta o autenticazione non standard), HTTP diretto ti dà quel controllo senza dover combattere con un livello di astrazione.

Operazioni sensibili alla latenza

Se ogni millisecondo conta (per esempio, agenti vocali in tempo reale in cui le tool call devono completarsi entro budget temporali rigidi), rimuovere il livello MCP elimina un hop.

Chiamate HTTP non AI

Se la chiamata HTTP non è attivata da un agente AI (per esempio, un cron job backend che sincronizza dati), MCP non è rilevante. MCP è progettato specificamente per la comunicazione tra AI e strumenti. I normali servizi backend dovrebbero usare normali client HTTP.

Approccio ibrido

Molti sistemi in produzione usano entrambi. Il pattern:

• MCP per integrazioni di strumenti che l’agente AI chiama durante le conversazioni (lookup CRM, creazione di ticket, query alla knowledge base)
• HTTP diretto per operazioni backend interne, webhook e comunicazione sistema-sistema

Questo è il modo in cui Quickchat AI funziona internamente. La piattaforma supporta sia HTTP Request Actions (chiamate API dirette con templating dei parametri) sia Remote MCP Actions (connessioni a server MCP esterni). Scegli l’approccio giusto per ogni integrazione:

Per un confronto dettagliato di come funziona in pratica, incluse le differenze tra GPT Actions di OpenAI e MCP, consulta GPT Actions vs MCP.

Framework decisionale

Usa questo flowchart per scegliere:

1. È l’agente AI a chiamare lo strumento? Se no (è un’operazione backend), usa HTTP diretto.
2. Di quanti strumenti esterni hai bisogno? Se 1-2, HTTP diretto è più semplice. Se 3+, considera MCP.
3. Esiste un server MCP pre-costruito per il servizio? Se sì, usarlo fa risparmiare tempo di sviluppo.
4. Hai bisogno che l’integrazione funzioni su più piattaforme AI? Se sì, MCP offre portabilità.
5. La latenza è critica (budget sotto i 100ms per le tool call)? Se sì, misura l’overhead di MCP e decidi di conseguenza.
6. Team diversi possiedono integrazioni diverse? Se sì, il modello di MCP con un server per integrazione aiuta a definire i confini di ownership.

In pratica, se stai creando un agente AI che deve interagire con servizi esterni, MCP è sempre più spesso la scelta predefinita. L’ecosistema di server pre-costruiti è abbastanza ampio da permetterti spesso di iniziare senza scrivere alcun codice server.

Letture consigliate

• Connetti il tuo AI Agent a un Remote MCP Server: fornisci strumenti live al tuo agente, passo dopo passo
• Come funziona Model Context Protocol. MCP spiegato: introduzione a MCP
• GPT Actions vs MCP: confronto con l’approccio di OpenAI
• Specifica MCP: la specifica ufficiale del protocollo
• HubSpot AI Actions: esempio di azioni AI basate su HTTP nella pratica
• L’incidente OpenAI Hugging Face, cosa è successo davvero: l’incidente spiegato passo dopo passo, e cosa significa davvero hacking