MCP vs API pour agents IA

La méprise

L'expression MCP vs API suggère un remplacement, et le protocole invite à la lecture car il ressemble à une API : un point de terminaison HTTPS, JSON, une liste d'opérations appelables. En dessous, c'est JSON-RPC 2.0 sur HTTP Streamable, ce qui signifie que c'est une API HTTP avec une forme de message fixe. Ce qu'il standardise n'est pas comment accéder à un système mais comment une application IA demande à un système ce qu'il peut faire, comment elle appelle ces choses avec un modèle choisissant les arguments, comment les erreurs sont renvoyées pour que le modèle puisse se corriger, et comment la personne derrière le modèle est autorisée. Une API REST ne standardise rien de tout cela, car elle n'en avait jamais besoin : ses appelants étaient des programmes dont les auteurs ont lu la documentation une fois.

Chaque serveur MCP sérieux pour un système d'entreprise est une couche au-dessus de la couche de service ou de l'API existante de ce système. La question n'est donc pas laquelle construire, puisque vous avez besoin de l'API de toute façon, mais laquelle remettre à un agent.

Ce qu'une API offre à un agent, et ce qu'elle ne fait pas

Donnez à un modèle une API REST et il peut l'utiliser, avec de l'aide. L'aide est le problème. Quelqu'un doit transformer les points de terminaison en définitions de fonction que le modèle peut voir, dans le format attendu par le fournisseur de modèle ; les formats d'appel de fonction de Claude et d'OpenAI sont similaires mais pas identiques. Quelqu'un doit écrire la boucle qui prend la fonction choisie par le modèle, appelle le point de terminaison avec les bonnes informations d'identification, et renvoie la réponse. Quelqu'un doit décider comment les erreurs atteignent le modèle, car un 422 avec un corps de validation n'est pas quelque chose qu'un modèle lit bien à moins qu'il ne soit converti. Et quelqu'un doit résoudre l'autorisation, car une clé API dans l'environnement de l'agent fait que chaque action ressemble au même compte de service, et non à la personne qui demande.

Rien de tout cela n'est difficile pour un système et un agent, c'est pourquoi c'était l'état de l'art avant le protocole. Cela ne s'adapte pas bien. Chaque association d'un produit d'agent et d'un système d'entreprise est sur mesure, les définitions dérivent de l'API, et il n'y a aucun moyen pour un utilisateur de Claude ou de ChatGPT de connecter un système par lui-même. L'API reste excellente pour ce pour quoi elle a été conçue : des appels à fort volume, de programme à programme, des opérations en masse, des webhooks et des intégrations où la logique est fixe et l'appelant est du code.

Ce que MCP ajoute

Le protocole répond à chacune de ces lacunes avec une règle que chaque client met en œuvre une fois. Découverte : tools/list renvoie les outils avec des noms, des descriptions et des schémas JSON à l'exécution, de sorte que le produit d'agent n'ait besoin d'aucune connaissance préalable et que la liste puisse changer à mesure que des applications sont installées ou que des rôles changent. Invocation : tools/call porte un nom et des arguments ; le résultat contient du contenu que le modèle lit, un contenu structuré optionnel, et un isError drapeau qui indique au modèle de corriger et de réessayer plutôt que d'abandonner. Autorisation : OAuth 2.1 avec le jeton lié au serveur et à la personne, de sorte que la liste des outils et chaque appel puissent être limités à qui demande. Consentement : les annotations permettent à un serveur de dire qu'un outil est en lecture seule, destructeur ou idempotent, et les clients les utilisent pour décider quand confirmer ; un serveur peut également renvoyer un résultat nécessitant une entrée pour poser une question à la personne en cours d'appel. Voici un appel et sa réponse, comme un client les envoie et les reçoit.

{
  "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
  }
}

Une demande d'appel d'outils et un résultat pour un outil de paiement Sois. La même opération via l'API REST nécessiterait une définition de fonction écrite pour le fournisseur de modèle, une boucle pour relayer l'appel, et une décision sur la manière de présenter la réponse ; ici, le client sait déjà comment faire les trois.

Il y a un coût. Le protocole est plus jeune que REST et est encore en mouvement : la révision du 28-07-2026 a supprimé les sessions au niveau du protocole et a changé la manière dont les serveurs demandent des entrées aux clients, et les clients doivent revenir à la révision précédente pour les serveurs. Les listes d'outils consomment du contexte, donc les grands serveurs ont besoin d'un chargement différé ou d'une recherche d'outils du côté client. Et un appelant piloté par un modèle est plus lent et moins prévisible qu'un programme, c'est précisément pourquoi vous ne l'utiliseriez pas pour une synchronisation nocturne.

Quand chacun est approprié

Comment les principaux produits d'agents consomment chacun aujourd'hui

Les API des fournisseurs règlent la comparaison pour quiconque construit son propre agent, car les deux acceptent désormais un serveur MCP comme un outil de première classe aux côtés de l'appel de fonction ordinaire. Du côté de Claude, les connecteurs personnalisés dans les applications web et de bureau et Cowork prennent une URL de serveur et complètent OAuth dans l'application ; Claude Code ajoute un serveur avec une commande ; et le connecteur MCP de l'API Messages (bêta, derrière le mcp-client-2025-11-20 en-tête) prend un serveurs mcp entrée et 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 avec un server_url, a exiger une approbation paramètre et optionnel allowed_tools liste, retours outils de la MCP et mcp_call éléments, et fonctionne avec Streamable HTTP ou le transport SSE plus ancien.

L'appel de fonction ordinaire reste disponible dans les deux API, et c'est le chemin pour un système uniquement REST : vous définissez les fonctions, vous appelez l'API, vous renvoyez les résultats. La différence réside entièrement dans qui maintient le pont. Avec MCP, le propriétaire du système maintient un serveur et chaque client en bénéficie ; avec l'appel de fonction, chaque constructeur d'agent maintient ses propres définitions par rapport à l'API.

Le modèle qui fonctionne : API en dessous, MCP au-dessus

Les systèmes qui réussissent cela exposent les deux et les acheminent à travers la même couche de permission. Sois est une mise en œuvre de ce modèle. L'espace de travail a une couche de service que chaque écran utilise. Son serveur MCP publie cette couche comme des outils à une URL, filtrée par le rôle de l'appelant et vérifiée à nouveau à chaque appel, avec OAuth pour les connecteurs et un jeton d'accès pour les scripts. Le même espace de travail accepte des demandes en langage clair à un point de terminaison séparé pour les appelants sans agent, où l'agent propre de l'espace de travail fait le raisonnement et répond par webhook ou polling. Et pour la direction sortante, son propre agent peut appeler des serveurs MCP externes via une passerelle, sous la même gouvernance d'autorisation, de demande et de refus.

Rien dans ce design ne nécessite de choix. L'API sert des programmes, le serveur MCP sert des modèles, la passerelle sert des appelants sans aucun, et un modèle de permission gouverne les trois. Quand quelqu'un demande lequel construire, la réponse honnête est que l'API est une évidence et que le serveur MCP est ce qui rend le système utilisable par les agents que les gens ont déjà.

Questions que les gens posent

Cet article est révisé lorsque les produits qu'il décrit changent. Prochaine révision prévue : 4 décembre 2026.