« On va migrer toute l’API vers MCP » : cette phrase, entendue lors d’un cadrage de projet, part d’une confusion fréquente entre deux couches qui n’ont pas la même fonction. Le Model Context Protocol ne remplace pas une API REST ou GraphQL existante : il ajoute une couche de description destinée spécifiquement à un agent capable d’appeler des outils.
Cette confusion mérite d’être clarifiée avant qu’un projet ne s’engage dans une réécriture inutile. Sur aucun de nos projets ayant adopté MCP, une seule route REST n’a été supprimée en conséquence — et c’est précisément le signe que le raccourci « MCP remplace toute API » simplifie à l’excès ce que ce protocole apporte réellement.
Ce que transporte une API REST classique
Une API REST WordPress, exposée via register_rest_route(), sert un client web, une application mobile ou un service tiers qui a besoin de lire ou d’écrire des données selon un contrat fixe, connu à l’avance par le développeur qui consomme l’API. Ce client sait exactement quelle route appeler et quel format de réponse attendre, parce que la documentation de l’API le lui indique.
Cette API continue de fonctionner exactement de la même façon, que le site expose ou non un serveur MCP en parallèle. Les deux ne se substituent pas l’une à l’autre, elles répondent à des besoins différents.
Ce qu’ajoute réellement un serveur MCP
Un serveur MCP répond à un besoin différent : permettre à un agent, qui ne connaît pas à l’avance les capacités précises du site auquel il se connecte, de découvrir dynamiquement quels outils sont disponibles et comment les appeler correctement. Cette découvrabilité est ce qui manque structurellement à une API REST classique, pensée pour un développeur qui lit la documentation, pas pour un agent qui doit décider seul quel outil utiliser.
- Découverte dynamique des outils disponibles, sans documentation externe préalable
- Description standardisée des paramètres attendus par chaque outil
- Format de communication commun à tous les clients compatibles MCP
- Aucune garantie de performance ou de latence comparable à une API REST optimisée
Un exemple concret : un site avec les deux couches
Sur un projet e-commerce, l’API REST WooCommerce continue de servir l’application mobile de l’équipe commerciale, qui l’appelle avec un contrat fixe et documenté. En parallèle, un serveur MCP expose un sous-ensemble d’outils — vérifier un stock, créer une commande de test — destinés spécifiquement à un agent de support capable de répondre à une demande client en langage naturel.
