Les 3 limites du MCP qui empêchent son explosion
S'il est devenu populaire dans les nombreuses démonstrations de solopreneurs sur les réseaux sociaux, l'utilisation du MCP dans le cadre professionnel est encore confidentielle. Scalabilité, sécurité, maturité… Voici les principales limites.
Des contraintes de scalabilité
C'est la grande limite du protocole. Et Justin Spahr-Summers, membre du staff technique d'Anthropic la reconnaît sans aucun détour : "MCP est actuellement un protocole stateful, ce qui est limitant pour les déploiements sans serveur, créant un obstacle à son adoption plus large." Très concrètement, chaque interaction entre le LLM et un outil via MCP repose sur une session persistante, ce qui empêche toute répartition flexible des requêtes entre plusieurs instances de serveurs. Impossible dès lors de déployer MCP dans un environnement serverless. Chaque client devant être, par conception, connecté au même serveur sur l'ensemble de sa session. Un maintien du contexte qui augmente par conséquent les ressources côté serveur, notamment dans un déploiement large avec de nombreux utilisateurs.
De même, la taille des fenêtres de contexte des LLM étant encore finie, en utilisant plusieurs outils simultanément au sein d'une même conversation (exemple : Google Calendar, Gmail, file reader…), il est facile d'atteindre rapidement la limite (200 000 tokens pour Claude 3.7 Sonnet). Même si la fenêtre n'est pas atteinte en totalité, des fenêtres surchargées donnent souvent lieu à des performances dégradées. L'arrivée de fenêtres de contexte à 10 ou 100 millions de tokens (et même possiblement infinie) pourrait cependant régler en partie le problème. Il faudra toutefois encore de nombreuses optimisations de l'inférence pour limiter les coûts d'usage à haut contexte.
Enfin, en raison de contraintes de ressources matérielles et des nombreuses itérations entre le modèle et les outils, le MCP impose souvent une latence plus importante qu'un appel API simple et bien optimisé.
Un manque de maturité, et donc d'adoption
Dévoilé il y a moins d'un an par Anthropic, le model context protocol reste peu adopté par l'industrie. S'il existe bien quelques serveurs MCP officiels (Azure, AWS, Cloudflare, Elevenlabs, Stripe…), la majorité des développements proviennent de la communauté. Rares sont les gros éditeurs à déployer du temps et de l'argent, pour le moment. Côté client MCP, Claude Desktop reste encore l'une des principales portes d'entrée. OpenAI supporte par exemple uniquement le protocole via son Agents SDK avant un déploiement dans l'application Desktop. Enfin, Hugging Face propose, depuis peu, un client local pour appuyer son InferenceClient en local. Des implémentations de clients qui restent encore trop peu nombreuses et écartent de nombreux développeurs de solutions tierces.
Côté modèle également, les choix sont peu nombreux. Pour une utilisation efficace, le MCP nécessite des LLM robustes, dotés du fonction calling. En d'autres mots, le modèle doit avoir spécifiquement été entraîné (instruction tuning) pour répondre au format attendu et éviter les erreurs. La start-up Giskard a d'ailleurs dévoilé, dans son benchmark Phare, un classement des modèles qui répondent le mieux avec les outils. Et ces derniers ne sont pas légions : seuls quatre modèles sur 17 testés obtiennent un score de 75% ou plus (dont une majorité de modèles Anthropic, assez logiquement). Un manque de développement mature côté serveur, client et modèle qui empêche encore de nombreuses entreprises à se lancer dans le MCP.
Des limitations sécuritaires
C'est l'autre limitation majeure du MCP, la sécurité. Les serveurs MCP alternatifs et tiers posent de sérieux problèmes de sécurité, qu'ils soient en local ou dans le cloud. En local, même si le code du serveur est accessible en open source, une faille peut avoir été glissée volontairement ou non, exposant directement les données entrées par l'utilisateur et les autres outils connectés dans la session. L'explosion des serveurs amateurs accentue d'autant ce phénomène qu'il est impossible de procéder à des review de code sur tous les serveurs open source.
Selon un rapport de HiddenLayer (spécialisée dans la cybersécurité de l'IA), 16 serveurs publiquement mis en avant sur la page officielle du protocole contenaient une ou plusieurs failles de sécurité. Ces derniers auraient pu involontairement créer des prompts injection dans le modèle et potentiellement exfiltrer des données. Côté serveur distant, le problème est encore plus flagrant : sans accès au code du serveur, il est nécessaire de faire confiance à 100% à son éditeur, à rebours des procédures zero trust.
Enfin, le MCP reste encore limité dans sa capacité à être audité. En effet, le protocole n'offre pas de manière native d'outils pour la surveillance des interactions entre le modèle et les différents serveurs. Il apparaît ainsi complexe de remonter la chaîne de production en cas d'incident majeur ou même de simple problème technique.
Malgré tout, le MCP reste la piste la plus prometteuse du moment pour utiliser facilement des applications du monde réel avec les LLM. Son adoption devrait croître dans les prochains mois. Au fil des mises à jour, le protocole pourrait supporter le serverless (avec des expérimentations en cours), et de nouveaux outils d'explicabilité. Sur le volet sécurité, MCP vient de recevoir le support de OAuth 2.0 pour sécuriser l'authentification entre les serveurs et les clients.