MCP vs API : quand utiliser MCP ou HTTP direct

Jakub Swistak
Publié le Mis à jour le 7 min de lecture
Schéma comparatif d’architecture montrant les modèles d’intégration MCP et HTTP

Lorsque vous connectez un agent IA à des outils et API externes, deux grandes approches sont possibles : utiliser Model Context Protocol (MCP) comme couche d’abstraction, ou appeler directement une API via HTTP. Les deux fonctionnent. Elles font des compromis différents en matière de flexibilité, de complexité, de performance et de portabilité.

Cet article compare les deux approches avec des exemples de code concrets, une analyse de latence et un cadre de décision pour choisir entre elles.

Les deux approches

Intégration HTTP directe

L’application d’IA (ou son backend) appelle directement les API externes avec des requêtes HTTP standard. Le développeur écrit le code qui construit les requêtes, gère l’authentification, analyse les réponses et renvoie les résultats au LLM.

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

Intégration MCP

L’application d’IA se connecte à un serveur MCP qui encapsule l’API externe. L’application utilise le protocole MCP pour découvrir les outils disponibles, les appeler par leur nom et recevoir les résultats. Le serveur MCP gère les appels HTTP réels vers l’API externe.

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

La différence clé : avec HTTP direct, l’application d’IA possède le code d’intégration de l’API. Avec MCP, c’est le serveur MCP qui le possède, et l’application d’IA appelle simplement des outils par leur nom.

Vous pouvez disposer du côté MCP de ce schéma sans construire le serveur : Quickchat AI héberge un serveur MCP en HTTP streamable pour chaque AI Agent, et transformer votre agent en serveur MCP revient à coller une URL dans l’application d’IA.

Comparaison du code

Comparons les deux approches avec un exemple pratique : récupérer les repositories d’un utilisateur GitHub.

Intégration HTTP directe

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Récupère les repositories d’un utilisateur 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
        ]

Pour l’intégrer à un LLM, vous avez aussi besoin de :

  • Une définition d’outil dans le format attendu par le LLM (schéma OpenAI function calling, schéma Claude tool use, etc.)
  • Du code pour analyser l’appel d’outil du LLM, invoquer get_user_repos et réinjecter le résultat dans la conversation
  • Une gestion des erreurs pour les échecs HTTP, les limites de débit et l’expiration de l’authentification

Serveur 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:
    """Récupère les 10 repositories mis à jour le plus récemment pour un utilisateur GitHub.

    Args:
        username: nom d’utilisateur GitHub à rechercher
    """
    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 "inconnu"
            lines.append(f"- {r['name']} ({lang}, {stars} étoiles): {r['description'] or 'Aucune description'}")
        return "\n".join(lines)

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

La version MCP encapsule l’appel API, l’authentification et la mise en forme de la réponse dans le serveur. Tout client compatible MCP peut utiliser cet outil sans rien connaître de l’API GitHub.

Ce qui change pour l’application d’IA

PréoccupationHTTP directMCP
Définition d’outilÉcrite dans le format natif du LLM (schéma OpenAI, etc.)Générée automatiquement à partir du serveur MCP
AuthentificationGérée par l’application d’IAGérée par le serveur MCP
Analyse de la réponseL’application d’IA extrait et met en forme les donnéesLe serveur MCP renvoie un résultat préformaté
Gestion des erreursL’application d’IA gère les erreurs HTTPLe serveur MCP gère les erreurs et renvoie des messages d’erreur structurés
Ajout d’un nouvel outilÉcrire du nouveau code dans l’application d’IASe connecter à un nouveau serveur MCP (ou ajouter un outil au serveur existant)
Changement de LLMRéécrire les définitions d’outils pour le nouveau format du LLMAucun changement nécessaire

Comparaison des performances

MCP ajoute une couche entre l’application d’IA et l’API externe. Cette couche a un coût.

Latence

Pour le transport stdio (serveurs MCP locaux), le surcoût est minimal : lancement du processus au démarrage (une seule fois, généralement moins de 100ms) et communication interprocessus par message (moins d’une milliseconde sur les systèmes modernes). En pratique, l’appel à l’API externe domine la latence totale.

Pour les serveurs MCP distants (Streamable HTTP ou SSE), vous ajoutez un aller-retour HTTP entre le client et le serveur MCP, plus l’aller-retour HTTP du serveur MCP vers l’API externe. Si le serveur MCP et l’API externe sont colocalisés, ce surcoût est faible (quelques millisecondes). S’ils se trouvent dans des régions différentes, il s’accumule. Le transport est toutefois rarement ce que l’utilisateur perçoit : lors de la création d’un agent de centre d’aide sur le serveur MCP hébergé de Notion, 248 appels d’outils ont pris en moyenne 2,7 secondes chacun, presque entièrement dues à la recherche Notion et au rendu des pages plutôt qu’au saut intermédiaire.

ConfigurationLatence ajoutée approximative
Serveur MCP local (stdio)< 1ms par appel d’outil
Serveur MCP distant (même région que l’API)1-5ms par appel d’outil
Serveur MCP distant (région différente de celle de l’API)10-50ms par appel d’outil

Pour la plupart des cas d’usage d’agents IA, où l’inférence du LLM prend 500ms-5s, le surcoût de MCP est négligeable.

Gestion des connexions

HTTP direct : votre application gère les connexions à chaque API externe. Cela signifie gérer les pools de connexions, la logique de nouvelle tentative et les limites de débit pour chaque API.

MCP : votre application gère une connexion par serveur MCP. Le serveur gère la connexion à l’API externe. Si vous avez 10 outils répartis sur 3 serveurs MCP, vous gérez 3 connexions au lieu de 10.

Quand utiliser MCP

Intégrations à plusieurs outils

Si votre application d’IA doit se connecter à 5 services externes ou plus, MCP réduit la charge d’intégration. Au lieu d’écrire et de maintenir des clients API personnalisés pour chaque service, vous vous connectez à des serveurs MCP (dont beaucoup sont disponibles sous forme de projets open source).

Portabilité entre plateformes d’IA

Si vous construisez des serveurs MCP pour vos outils, ces serveurs fonctionnent avec n’importe quel client MCP : Claude Desktop, Cursor, Windsurf, applications personnalisées et plateformes comme Quickchat AI. Avec HTTP direct, vous devriez réimplémenter les définitions d’outils pour le format de chaque plateforme.

Découverte dynamique des outils

MCP prend en charge la découverte des outils à l’exécution via tools/list. Une application d’IA peut se connecter à un serveur et découvrir quels outils sont disponibles sans configuration codée en dur. C’est utile dans les scénarios où les outils changent fréquemment ou sont configurables par l’utilisateur.

Séparation des responsabilités

Si différentes équipes possèdent différents outils, MCP fournit une frontière claire. L’équipe responsable de l’intégration Salesforce construit et maintient le serveur MCP Salesforce. L’équipe de l’application d’IA s’y connecte sans avoir besoin de comprendre l’API Salesforce. Les mises à jour de l’API Salesforce sont gérées dans le serveur MCP sans modifier l’application d’IA.

Quand utiliser HTTP direct

Une ou deux intégrations

Si votre agent IA n’a besoin d’appeler qu’une seule API (par exemple, une recherche dans une base de données), le surcoût lié à l’exécution d’un serveur MCP est inutile. Un appel HTTP direct est plus simple et comporte moins d’éléments mobiles.

Vous n’avez pas non plus à écrire la requête à la main. Le constructeur API Action en anglais naturel lit une API REST documentée, génère la méthode, l’URL, les paramètres et la description, puis vous permet de tester la vraie réponse avant de l’activer.

Contrôle maximal sur les requêtes

Les serveurs MCP abstraient les détails HTTP. Si vous avez besoin d’un contrôle précis sur la construction des requêtes (headers spécifiques, paramètres de requête, signature de requête ou authentification non standard), HTTP direct vous donne ce contrôle sans lutter contre une couche d’abstraction.

Opérations sensibles à la latence

Si chaque milliseconde compte (par exemple, des agents vocaux en temps réel où les appels d’outils doivent se terminer dans des budgets de temps stricts), supprimer la couche MCP élimine un saut.

Appels HTTP non liés à l’IA

Si l’appel HTTP n’est pas déclenché par un agent IA (par exemple, une tâche cron backend qui synchronise des données), MCP n’est pas pertinent. MCP est spécifiquement conçu pour la communication entre IA et outils. Les services backend classiques doivent utiliser des clients HTTP classiques.

Approche hybride

De nombreux systèmes en production utilisent les deux. Le modèle :

  • MCP pour les intégrations d’outils que l’agent IA appelle pendant les conversations (recherches CRM, création de tickets, requêtes dans la base de connaissances)
  • HTTP direct pour les opérations backend internes, les webhooks et la communication système à système

C’est ainsi que Quickchat AI fonctionne en interne. La plateforme prend en charge à la fois les HTTP Request Actions (appels API directs avec modèles de paramètres) et les Remote MCP Actions (connexions à des serveurs MCP externes). Vous choisissez la bonne approche pour chaque intégration :

Type d’intégrationApproche recommandée
Appel API simple avec paramètres connusHTTP Request Action
Intégration complexe avec plusieurs outils liésRemote MCP Action
Service tiers avec un serveur MCP existantRemote MCP Action
API interne avec authentification personnaliséeHTTP Request Action
Outil configurable par l’utilisateurRemote MCP Action

Pour une comparaison détaillée du fonctionnement en pratique, y compris les différences entre les GPT Actions d’OpenAI et MCP, consultez GPT Actions vs MCP.

Cadre de décision

Utilisez cet organigramme pour choisir :

  1. L’agent IA appelle-t-il l’outil ? Si non (c’est une opération backend), utilisez HTTP direct.
  2. De combien d’outils externes avez-vous besoin ? Si 1-2, HTTP direct est plus simple. Si 3 ou plus, envisagez MCP.
  3. Existe-t-il un serveur MCP préconstruit pour le service ? Si oui, l’utiliser fait gagner du temps de développement.
  4. Avez-vous besoin que l’intégration fonctionne sur plusieurs plateformes d’IA ? Si oui, MCP apporte la portabilité.
  5. La latence est-elle critique (budget inférieur à 100ms pour les appels d’outils) ? Si oui, mesurez le surcoût de MCP et décidez en conséquence.
  6. Différentes équipes possèdent-elles différentes intégrations ? Si oui, le modèle de MCP avec un serveur par intégration aide à définir les responsabilités.

En pratique, si vous construisez un agent IA qui doit interagir avec des services externes, MCP devient de plus en plus le choix par défaut. L’écosystème de serveurs préconstruits est suffisamment vaste pour que vous puissiez souvent démarrer sans écrire le moindre code serveur.

Pour aller plus loin