MCP vs API : quand choisir MCP ou OpenAPI ?

MCP (Model Context Protocol) et OpenAPI/function calling sont deux façons de connecter des agents IA à des outils externes. OpenAPI décrit des interfaces REST classiques, intégrées en dur dans l'agent via le function calling. MCP est un standard ouvert de découverte dynamique d'outils, utilisable par de nombreux clients. MCP vaut le coup quand les agents sont nombreux et les outils changeants ; OpenAPI, pour une intégration circonscrite et stable.

• OpenAPI/function calling est le choix pragmatique lorsqu'un seul agent utilise un petit ensemble d'outils stable et que tu en es le seul consommateur.
• MCP devient intéressant dès que plusieurs clients ont besoin des mêmes outils, que l'ensemble d'outils s'agrandit ou que les outils doivent changer à l'exécution (découverte dynamique).
• Les deux ensemble, c'est le cas normal : un serveur MCP encapsule souvent précisément les API REST documentées avec OpenAPI et les rend exploitables par des agents.

De quoi s'agit-il vraiment : connecter des outils aux agents

Un agent IA est un LLM qui utilise des outils en boucle. La question d'architecture centrale n'est pas « MCP ou OpenAPI » au sens d'une alternative exclusive, mais : comment mon agent accède-t-il de manière fiable, sûre et maintenable à des fonctions externes ? Il existe pour cela deux écoles de pensée.

Function calling classique avec OpenAPI. Tu décris tes fonctions sous forme de schéma d'outil (nom, paramètres, types, description) et tu transmets ce schéma au modèle directement dans l'appel d'API. Souvent, le schéma est généré à partir d'une spécification OpenAPI existante, c'est-à-dire de la description lisible par machine d'une interface REST. Le modèle décide quelle fonction appeler et avec quels arguments ; ton code exécute la requête HTTP proprement dite et renvoie le résultat. C'est direct, transparent et cela ne demande aucune infrastructure supplémentaire.

MCP : Model Context Protocol. Anthropic a présenté MCP le 25 novembre 2024 comme standard ouvert pour connecter des applications d'IA à des systèmes externes : systèmes de fichiers, bases de données, systèmes métier et outils de développement. Techniquement, MCP repose sur JSON-RPC 2.0 via plusieurs transports : stdio pour les serveurs locaux, à l'origine Server-Sent Events et, depuis la révision de la spécification de mars 2025 (2025-03-26), Streamable HTTP. Cette même révision a ajouté la prise en charge d'OAuth 2.1 et les annotations d'outils. Le batching JSON-RPC, introduit en même temps, a été retiré par la spécification 2025-06-18. La spécification de novembre 2025 a notamment apporté des tâches expérimentales pour les opérations asynchrones et les Client ID Metadata Documents pour l'enregistrement des clients. Avec la spécification 2026-07-28, MCP est devenu sans état : le handshake d'initialisation disparaît, et chaque serveur doit déclarer ses versions de protocole, ses capacités et son identité via la méthode server/discover. Au lieu d'inscrire le schéma de l'outil en dur dans l'agent, un client MCP interroge le serveur à l'exécution : « Quels outils, ressources et prompts as-tu ? »

La différence semble minime, mais elle est structurelle : OpenAPI/function calling lie les outils de manière statique au client, MCP les découple du client sous forme de serveur réutilisable.

Les cinq dimensions de la décision

1. Découverte : statique ou dynamique

Avec le function calling pur, l'agent ne connaît que les outils que tu lui fournis lors de l'appel. Si un outil s'ajoute, tu modifies le code. Avec MCP, le client interroge les capacités à l'exécution, et les nouveaux outils du serveur sont disponibles sans modification du code. C'est l'avantage fondateur de MCP pour « de nombreux outils changeants ».

2. Gestion d'état (statefulness)

Les appels OpenAPI sont par définition des requêtes HTTP sans état. Les sessions MCP étaient à l'origine avec état (une connexion ouverte avec contexte). Avec Streamable HTTP, l'identifiant de session est devenu facultatif : dès mars 2025, des serveurs pouvaient donc fonctionner sans session. La spécification 2026-07-28 rend MCP stateless par principe : les sessions et le handshake d'initialisation disparaissent, chaque requête transporte elle-même la version du protocole et les capacités du client. Pour conserver un état sur plusieurs appels, le serveur utilise des handles explicites, transmis comme des arguments d'outil ordinaires. Cela facilite la mise à l'échelle horizontale et les déploiements serverless.

3. Standardisation et écosystème

C'est ici que MCP a son argument le plus fort. OpenAI a adopté MCP en mars 2025, Google DeepMind en avril 2025, sans oublier Microsoft Copilot Studio, Cursor, Zed, Windsurf, Replit, Sourcegraph, Block et des dizaines d'autres. Les SDK affichent plus de 97 millions de téléchargements mensuels pour Python et TypeScript ; Claude, d'Anthropic, propose un répertoire de plus de 75 connecteurs MCP officiels. Le 9 décembre 2025, Anthropic a fait don de MCP à la toute nouvelle Agentic AI Foundation (AAIF), placée sous l'égide de la Linux Foundation, avec Block et OpenAI comme cofondateurs et le soutien de niveau Platinum d'AWS, Bloomberg, Cloudflare, Google et Microsoft. MCP n'est donc plus le standard d'un éditeur, mais un consensus de l'industrie. OpenAPI est lui aussi un standard établi et largement soutenu, mais il décrit les API HTTP en général, pas le protocole d'utilisation d'outils propre aux agents.

4. Effort

Le function calling via OpenAPI demande moins d'effort initial : pas de serveur, pas de couche de transport, pas de couche d'authentification pour MCP. MCP exige que tu construises ou exploites un serveur, mais devient rentable dès que plus d'un client utilise le même outil. Dans les PME européennes, la règle empirique en 2026 est la suivante : utiliser les serveurs MCP standard des éditeurs, plus un petit ensemble de serveurs MCP maison pour les API internes propriétaires.

5. Utilisation d'outils ou agent-to-agent

Point important pour bien délimiter : MCP est le standard pour la relation agent-outil. Pour une véritable collaboration entre agents, il existe A2A (Agent2Agent, Google 04/2025, Linux Foundation 06/2025). La ligne officielle de Google, Salesforce, Microsoft et IBM est la suivante : « MCP sert aux capacités (agent-to-tool), A2A à la collaboration (agent-to-agent). » Les recommandations de Microsoft sont explicites : « Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging. » On peut certes exposer un agent comme « serveur » MCP avec des capacités en forme d'outils, et cela fonctionne, mais ce n'est pas l'objectif de conception de MCP.

Tableau comparatif : MCP vs. OpenAPI/function calling

Exemple concret : un agent d'audit SEO

Imaginons qu'une agence développe en interne des outils autour du SEO : un crawler, une base de données de mots-clés, un CMS et une fonction de reporting.

Scénario A : un seul agent, OpenAPI suffit. Il y a exactement un agent d'audit qui appelle quatre endpoints REST stables. Tu génères les quatre schémas d'outils à partir des spécifications OpenAPI existantes, tu les intègres directement, et c'est terminé. Aucun serveur à exploiter, effort minimal. Si tu introduisais MCP ici, tu paierais une infrastructure serveur sans contrepartie.

Scénario B : outils productisés, MCP l'emporte. L'agence exploite désormais plusieurs agents (agent d'audit, agent OnPage, pipeline de newsletter) et ses clients doivent pouvoir appeler la recherche de mots-clés depuis leurs propres stacks (par exemple Copilot Studio ou n8n). Au lieu de maintenir à nouveau le schéma de mots-clés dans chaque client, tu construis un serveur MCP « SEO-Keyword-Research » et une bibliothèque partagée de serveurs MCP pour tous les produits. Pseudo-code :

keyword_server = MCPServer("seo-keyword-research")

keyword_server.tool("get_keyword_volume", schema=...)

keyword_server.tool("get_serp_overview", schema=...)

Chaque client (Claude, n8n, LangGraph) se connecte à ce serveur et détecte les deux outils à l'exécution grâce à la découverte dynamique.

Un nouvel outil sur le serveur est immédiatement disponible pour tous les clients, sans modification du code des agents. C'est précisément cet effet de levier de la réutilisation qui constitue en 2026 l'argument le plus fort en faveur de MCP. Dans un projet réaliste pour une PME, le budget de la première année d'un programme multi-agents se situe, selon le nombre de serveurs MCP maison, entre 150 k€ et 500 k€ ; le haut de la fourchette s'explique surtout par des serveurs MCP sur mesure couvrant plusieurs systèmes internes (situation en 2026).

Aide à la décision en trois questions

1. Combien de clients utilisent l'outil ? Un seul → OpenAPI/function calling. Plusieurs → MCP.
2. Quelle est la stabilité de l'ensemble d'outils ? Stable et réduit → OpenAPI. En croissance ou changeant → MCP (découverte dynamique).
3. S'agit-il d'outils ou de coopération entre agents ? Outils/données → MCP. Véritable collaboration agent-to-agent entre plateformes → A2A (ne détourne pas MCP de son usage).

Une remarque réaliste tirée de la pratique : dans les projets avec des PME de la zone DACH (Allemagne, Autriche, Suisse), tu vas « écrire ou consommer des serveurs MCP, que tu l'aies prévu ou non ». SAP Joule Studio 2.0, Microsoft 365 Copilot, Copilot Studio, Salesforce Agentforce, n8n et LangGraph parlent tous MCP. La question est donc souvent moins « faut-il MCP » que « où commencer avec MCP ».

Ne sous-estime pas la sécurité

L'ouverture de MCP a son revers. En 2025, plusieurs classes d'attaques ont été documentées : injection de prompt indirecte via les descriptions de serveurs MCP, tool poisoning (Invariant Labs, avril 2025, avec un PoC sur WhatsApp), squatting de serveurs look-alike et le Full-Schema Poisoning de CyberArk (chaque partie d'un schéma d'outil est un vecteur d'injection, pas seulement la description). En cause : le « modèle de confiance optimiste » de MCP. La sécurisation incombe à l'exploitant : sandboxing, jetons à portée limitée, scopes OAuth 2.1, moindre privilège et aucune installation autonome de serveurs MCP depuis des registres non fiables. Les intégrations OpenAPI classiques ont ici l'avantage de modèles de sécurité REST éprouvés et bien compris.

Pour les agences et les décideurs B2B

Si tu lances un projet pilote délimité avec un agent et quelques API stables, commence léger avec OpenAPI/function calling : cela réduit le time-to-value. Dès que tu veux productiser plusieurs agents ou réutiliser des outils à travers les systèmes de tes clients, MCP est l'investissement stratégiquement juste : un serveur, de nombreux clients. Pour les agences, c'est un levier produit concret : des serveurs MCP verticaux maison (SEO, CMS, newsletter) associés à des Agent Cards A2A rendent tes services directement appelables depuis les environnements Salesforce, Joule ou Copilot Studio de tes clients. Blck Alpaca accompagne les entreprises en Europe précisément dans ce choix d'architecture, de la connexion d'outils via MCP jusqu'à l'orchestration multi-agents sécurisée et conforme aux règles de gouvernance.