MCP est mort discrètement. Corsair montre ce qui le remplace.

MCP est mort discrètement. Corsair montre ce qui le remplace.

J'avais quarante-trois outils connectés à un seul agent et je le regardais perdre la tête en temps réel.

La tâche était stupidement simple. "Récupérez les dix derniers e-mails de mon Gmail et résumez tout ce qui concerne la proposition que j'ai envoyée mardi." Un travail en deux temps. Lisez le courrier électronique. Résumer. C'est ça. Au lieu de cela, l’agent a appelé un outil de recherche Slack. Puis un outil de calendrier que j'avais connecté pour un autre projet. Ensuite, il a essayé d'invoquer gmail_get_messages, sauf que ce n'était pas le nom de la fonction. L'outil réel était read_gmail_inbox. L'agent avait halluciné un appel d'API plausible à partir d'un schéma dont il se souvenait à moitié grâce à 38 000 jetons de définitions d'outils initiales.

J'ai arrêté la course, ouvert le journal d'entrée et compté. Avant même que mon invite n'atteigne le modèle, MCP avait injecté plus de 40 000 jetons de schémas d'outils dans la fenêtre contextuelle. Quarante mille jetons. Pour répondre à une question une dizaine de mails. L'agent n'a jamais eu aucune chance.

C’est à ce moment-là que j’ai arrêté de défendre MCP et que j’ai commencé à chercher la suite. Je vais passer en revue ce que j'ai trouvé, y compris un petit projet open source appelé Corsair qui, je pense, indique la véritable architecture d'utilisation des outils en 2026. Mais d'abord, vous devez comprendre ce qui s'est réellement cassé. Parce que "MCP est mort" n'est pas un battage médiatique. C'est ce que disent les calculs lorsque vous poussez le protocole au-delà des démonstrations de jouets.

Ce que MCP était censé faire

Anthropic a livré le Model Context Protocol fin 2024 avec un pitch clair et ambitieux. Les LLM sont des cerveaux sans mains ni jambes. Ils peuvent raisonner avec brio sur le code, le langage et la stratégie, mais ils ne peuvent pas publier un tweet, lire votre boîte de réception ou mettre à jour une feuille de calcul sans une plomberie externe. MCP était censé être cette plomberie : standardisée, indépendante du fournisseur et universelle.

Le mécanicien était simple. Vous exposez un outil. L'outil annonce un schéma JSON décrivant son nom, ses paramètres et ce qu'il fait. Le client MCP injecte le schéma de chaque outil disponible dans la fenêtre contextuelle du modèle au début de la conversation. Le modèle sélectionne le bon outil, génère un appel structuré et le runtime l'exécute. Ajouter un outil. Obtenez des capacités. Répéter.

J’y ai complètement adhéré. L'année dernière, j'ai écrit sur [les trois MCP qui ont transformé Claude en mon centre d'opérations] (https://www.mejba.me/blog/must-have-mcps-claude-code) — Canva, Zapier et Stripe connectés ensemble ont changé ma façon de travailler pendant environ six mois. Avec trois ou quatre outils, MCP semble magique. Le protocole disparaît. Vous demandez des choses dans un anglais simple et elles se produisent.

Mais trois ou quatre outils, c'est la version jouet. Au moment où vous évoluez – au moment où vous essayez de relier la pile réelle qu’un professionnel en activité utilise – l’architecture se fissure de trois manières spécifiques.

Le problème de gonflement de la fenêtre contextuelle

Voici le numéro qui a mis fin à la romance pour moi.

Selon un benchmark 2025 de Scalekit, la même opération qui a nécessité 1 365 jetons via une CLI a coûté 44 026 jetons via MCP. Cela représente environ 32 fois la surcharge du jeton, et la quasi-totalité était une injection de schéma : 43 définitions d'outils mises en contexte avant que l'agent n'ait lu un seul caractère de la question réelle de l'utilisateur. Toutes les autres analyses réputées que j’ai lues depuis atterrissent dans le même quartier. L'équipe d'ingénierie de CodeRabbit a mesuré dès le départ des serveurs MCP uniques consommant plus de 55 000 jetons de schéma. Les recherches de Cyclr ont révélé qu'avec plus de 50 outils, les schémas peuvent consommer 5 à 7 % d'une fenêtre contextuelle de 200 000 avant le début de la conversation.

Lisez attentivement ces chiffres. Cinq à sept pour cent de votre contexte ont disparu avant que quiconque ait tapé quoi que ce soit.

Le problème est architectural et non au niveau de la mise en œuvre. MCP a été conçu autour de l'hypothèse selon laquelle le modèle doit voir chaque outil pour utiliser chaque outil. Cette hypothèse était raisonnable lorsque les agents disposaient de quatre ou cinq outils. C'est catastrophique quand ils en ont quarante. Et quarante n'est pas la limite supérieure - c'est à peu près ce qu'un seul développeur en activité accumule entre GitHub, Slack, Linear, Sentry, sa base de données, sa messagerie électronique, son calendrier et son CMS.

J'ai regardé mes propres configurations dépasser soixante outils sans essayer. Chacun semble "libre" lorsque vous l'ajoutez. Chacun taxe chaque demande future, que vous l’utilisiez ou non.

Quand les hallucinations commencent

Voici la partie que la plupart des articles enterrent. Le coût des jetons est le problème ennuyeux. Le problème intéressant est de savoir ce qui arrive au raisonnement du modèle lorsque son attention doit s'étendre sur des dizaines de schémas d'outils.

Il existe une tendance que j’ai constatée à plusieurs reprises dans mes propres journaux et dans les recherches publiées. Une fois que l’utilisation du contexte dépasse environ 70 %, la précision de la sélection des outils du modèle s’effondre. Cela commence à confondre les paramètres entre des outils similaires. Il appelle le bon outil avec des arguments provenant du schéma d'un autre outil. Il invente des outils qui n'existent pas mais qui semblent devoir fonctionner. Et – celui-ci est vraiment déconcertant – il fait tout cela en toute confiance. Les appels hallucinés ressemblent exactement aux vrais.

Les benchmarks de style Scalekit s'alignent également sur les travaux universitaires. L'article RAG-MCP d'arXiv (2505.03275) a effectué un test de résistance dans lequel ils ont alimenté un LLM avec un pool croissant de descriptions d'outils MCP et ont vu la précision de la sélection chuter d'une falaise. Avec l'approche de vidage complet du schéma (telle que MCP fonctionne aujourd'hui), ils ont mesuré une précision de sélection d'outils de 13,62 %. Avec la sélection basée sur la récupération, le même modèle sur les mêmes requêtes a atteint 43,13 %. Plus de trois fois la précision avec moins de la moitié des jetons d'invite.

Ce n'est pas un problème de réglage. C'est un problème « toute l'approche est fausse ».

Je vais vous donner l'exemple le plus concret de mes propres tests. J'avais deux outils connectés : send_email (via Gmail MCP) et send_message (via Slack MCP). Même structure verbale. Différentes plateformes. Différentes formes de paramètres. Environ une exécution sur sept, l'agent générerait un appel à send_email avec les paramètres channel et text de Slack. Le runtime le rejetterait. L'agent s'excusait, réessayait, et parfois réussissait et parfois échouait d'une manière différente. Chaque nouvelle tentative brûlait des jetons. Chaque mode de défaillance était unique. Le débogage, c'était comme chasser des fantômes.

Lorsque je suis revenu à douze outils, le taux d’échec est tombé à près de zéro. Douze outils — pour un agent effectuant un seul travail. C'est le plafond pratique que MCP vous offre en production.

La taxe sur la fragmentation des schémas

Bien que les spécifications de MCP soient techniquement standardisées, la réalité de son exécution sur tous les fournisseurs en 2026 est plus compliquée que ne le suggère le marketing.

J'ai maintenant connecté des serveurs MCP d'au moins huit fournisseurs différents, et je peux vous dire avec une certitude absolue que le « schéma JSON » cache un océan d'incohérence. Certains serveurs renvoient des erreurs sous forme d'objets structurés. Certains renvoient des erreurs sous forme de chaînes insérées dans les réponses réussies. Certains serveurs paginent. Certains ne le font pas et tronquent silencieusement. Certains serveurs honorent la distinction de champ optionnelle/required. Certains traitent tout comme requis et s'interrompent si vous oubliez quelque chose. L'authentification va d'OAuth propre à "coller ce jeton dans un fichier de configuration et prier".

Each one of these inconsistencies forces either the model or the developer to write defensive logic. Multipliez cela par le nombre de serveurs MCP que vous exécutez, et la promesse du « protocole unifié » se transforme en « soupe de schéma JSON avec le code de l'adaptateur au milieu ».

The deeper issue is that MCP standardized the transport but not the semantics. Two servers can both be valid MCP and behave nothing like each other. C'est bien quand vous en avez un ou deux. C'est une taxe d'intégration quand on en a vingt.

Plus de constructeurs que d'utilisateurs

Voici le signal dont personne dans les supports marketing de MCP ne veut parler. Regardez les registres. Appuyez sur MCP. Répertoire des connecteurs d'Anthropic. Forge. Glama. Il existe désormais des milliers de serveurs MCP. La plupart d’entre eux ont une poignée d’étoiles GitHub et presque aucun utilisateur réel.

La communauté est pleine de gens construisant des serveurs MCP. Il est étonnamment vide de personnes qui les gèrent en production à grande échelle. La raison n’est pas un mystère, ce sont les trois problèmes que je viens de parcourir. La première fois que vous essayez de connecter quinze de ces éléments à un seul agent, vous vous heurtez au mur. Vous vous repliez tranquillement sur trois ou quatre outils, ou vous abandonnez complètement MCP et revenez aux appels directs d'API, ou vous commencez à écrire du code de gestion de contexte agressif pour compresser ce que MCP injecte.

J'ai écrit exactement sur ce modèle dans mon article sur [comment le mode contextuel a résolu mon problème de mémoire Claude Code] (https://www.mejba.me/blog/context-mode-claude-code-bloat). Le mode Contexte est une solution intelligente au symptôme : il supprime les sorties de l'outil MCP du contexte une fois qu'elles ont été consommées. Mais cela ne résout pas le problème en amont de chaque schéma injecté au démarrage. Cela empêche simplement le saignement de tuer le patient.

Lorsque l’écosystème de solutions de contournement devient plus grand que le protocole lui-même, celui-ci est en difficulté.

Le changement de modèle mental : de la carte de bibliothèque à l'encyclopédie

Voici le cadrage qui a finalement cliqué pour moi. MCP traite les outils comme des livres que vous transportez. Chaque fois que vous démarrez une conversation, vous chargez tous les livres dont vous pourriez avoir besoin dans votre sac à dos, puis vous raisonnez en étant écrasé sous leur poids. Le modèle doit tous les prendre en compte, à tout moment, juste au cas où.

Il existe évidemment une meilleure façon. Ne portez pas les livres. Emportez un index. Lorsque vous avez besoin d'informations, recherchez quel livre les contient, récupérez uniquement ce livre et lisez.

C'est le modèle de l'encyclopédie. Le modèle sait quels livres existent – leurs titres, une description sur une ligne, le domaine approximatif – et récupère le schéma complet uniquement lorsqu'une requête l'exige réellement. C'est exactement l'architecture RAG (génération augmentée par récupération) apportée au document Q&A il y a plusieurs années. Nous ne l'avons tout simplement pas appliqué à la sélection des outils, car la conception originale du MCP n'anticipait pas l'échelle.

Appliquez RAG aux outils au lieu des documents et des inverses mathématiques. Au lieu que chaque conversation commence par 40 000 jetons de schéma, elle commence par peut-être 200 jetons d'outil index. Lorsque l'utilisateur demande quelque chose, une recherche vectorielle récupère les deux ou trois schémas d'outils pertinents, ceux-ci sont injectés dans le contexte et le modèle en sélectionne un. Les taux d’hallucinations chutent parce que le modèle ne se noie pas dans des options similaires. Les coûts des jetons diminuent parce que vous payez pour ce que vous utilisez, et non pour ce que vous pourriez utiliser. Le nombre d’outils devient effectivement illimité.

Karpathy souligne des idées connexes depuis un certain temps - j'ai abordé certaines de ses réflexions sur l'architecture RAG lorsque j'ai écrit sur [la création d'une base de connaissances personnelle RAG dans Obsidian] (https://www.mejba.me/blog/karpathy-obsidian-rag-knowledge-base). Les outils ne sont qu’un autre type d’artefact récupérable. Nous devrions les traiter de cette façon.

Saisissez Corsair

Corsair est un projet open source sur GitHub (github.com/corsairdev/corsair) qui implémente exactement ce modèle. Je ne vais pas encore prétendre que c'est un produit raffiné – ce n'est pas le cas. Le dépôt est jeune, les documents sont rares et la communauté est petite. Mais l'architecture est la réponse la plus honnête que j'ai vue aux questions auxquelles MCP ne peut pas répondre.

Voici comment cela fonctionne au niveau mécanique.

Vous installez Corsair en tant que couche entre votre agent et vos outils. Il est livré avec un catalogue de définitions de plugins pour les services courants – Slack, Gmail, GitHub, Google Calendar et bien d’autres sont ajoutés. Les métadonnées de chaque plugin résident dans un index vectoriel. Lorsque votre agent reçoit une requête, Corsair exécute d'abord une recherche sémantique dans le catalogue de plug-ins, récupère uniquement les schémas d'outils du plug-in concerné et les expose au modèle. Tout le reste reste hors contexte.

Pour l'agent, Corsair ressemble à un petit nombre de méta-outils : recherchez dans le catalogue, récupérez un plugin, exécutez un appel. Pour vous, en tant que développeur, exposer vingt intégrations équivaut à peu près à une ligne de code. La complexité se situe à l’intérieur du runtime de Corsair, à sa place.

The credential model is the part I appreciated most. Corsair stores authentication locally in an on-file database. Pas de relais cloud obligatoire. No third-party dashboard managing your OAuth tokens. If you want to wire your personal Gmail and your client's GitHub into the same agent, the secrets stay on your machine. For anyone who's built agents touching sensitive systems, this matters more than any feature spec line.

La différence en matière d'expérience de développement

Permettez-moi de rendre le contraste concret avec la sensation d'un travail de câblage typique selon chaque approche.

Sous MCP, l'ajout d'un service est une cérémonie en plusieurs étapes. Trouvez le bon serveur MCP. Lisez son README. Configurez-le dans votre client (Claude Desktop, Cursor, runtime personnalisé — ils diffèrent tous légèrement). Authentifier. Redémarrez votre client. Test. Sachez qu'un paramètre est nommé légèrement différemment de ce que dit la documentation. Déboguer. Sachez que le format de réponse du serveur ne correspond pas à la norme. Écrivez une analyse défensive. Redémarrez à nouveau. Maintenant, faites cela pour le prochain service. Et le suivant.

Sous le modèle de récupération de style Corsair, l'ajout d'un service est plus proche de « enregistrer le plugin, stocker les informations d'identification, c'est fait ». L'agent n'a pas besoin d'être reconfiguré. La fenêtre contextuelle ne s'agrandit pas. Rien d’autre dans le système n’a besoin de le savoir.

Je veux être précis ici parce que j’essaie vraiment de ne pas trop vendre. Corsair est spécifiquement précoce. Le catalogue de plugins est petit. Vous rencontrerez des difficultés si vous essayez de l’utiliser pour quelque chose de niche aujourd’hui. Mais le modèle – la récupération d'outils pilotés par RAG – est ce vers quoi convergent tous les projets d'infrastructure d'agents sérieux que j'ai examinés. Anthropic lui-même a récemment publié des recherches sur le chargement paresseux de schémas et le contrôle dynamique des outils. L'article arXiv « Tool Attention Is All You Need » (2604.21816) présente le même argument architectural sous un angle différent. La direction est définie, même si la mise en œuvre principale n’est pas encore complètement cristallisée.

Là où MCP a toujours du sens

Je veux être juste, car je pense que beaucoup de messages « X est mort » exagèrent leur argument et perdent leur crédibilité. MCP n'est pas inutile. Il est tout simplement mal adapté à l’échelle vers laquelle la plupart d’entre nous le poussent.

MCP est vraiment utile lorsque vous disposez d’un petit ensemble d’outils fixes et organisés – disons, trois à sept – auxquels vous souhaitez que chaque conversation ait accès. Le modèle de schéma initial convient à cette échelle. La latence est faible. L'attention du modèle a la possibilité de se propager sans se briser. Les avantages du protocole en matière de standardisation l'emportent sur ses frais généraux. Si vous créez un agent ciblé qui fait une chose – un réviseur de code avec trois outils, un assistant d'écriture avec quatre – MCP convient parfaitement. C'est peut-être la bonne réponse.

MCP a également du sens en tant que backend. Vous pouvez imaginer des systèmes de récupération comme Corsair parlant MCP sous le capot pour l'invocation réelle de l'outil, tandis que la couche de découverte au-dessus fonctionne sur les principes de récupération. Le protocole devient une infrastructure plutôt qu'un modèle orienté utilisateur. C’est probablement là que tout cela aboutira à long terme.

Ce pour quoi MCP n'est pas bon, c'est le travail réel que les agents les plus ambitieux doivent faire : coordonner des dizaines de services, définir dynamiquement quels outils sont pertinents pour quelle tâche et rester en dessous du seuil d'utilisation du contexte où le raisonnement s'effondre. Pour cette charge de travail, le modèle d’injection de schéma est structurellement erroné et aucune compression de contexte ne le sauvegarde.

Ce que je fais maintenant

J'ai divisé ma propre infrastructure d'agent en deux pistes. Pour les agents à portée unique et à usage unique – mon robot de révision de code, mon convertisseur de capture d'écran en CSS, mon agent de tri des e-mails – je reste sur MCP. Trois à cinq outils chacun. Aucune récupération nécessaire. Le protocole fonctionne.

Pour mon agent d'opérations à usage général – celui qui doit toucher la messagerie électronique, le calendrier, GitHub, mon CMS, mes analyses, mon CRM et une douzaine d'autres systèmes – je suis passé à une architecture basée sur la récupération. Style Corsair aujourd'hui, peut-être quelque chose de plus mature dans six mois. Le projet de loi symbolique justifiait à lui seul la migration. La forte baisse des appels d’outils hallucinés l’a justifié à deux reprises.

Le modèle mental que j’applique désormais à chaque nouvel agent est le suivant : de combien d’outils aura-t-il besoin ? Si la réponse est « cinq ou moins, jamais », MCP convient. Si la réponse est « Je ne sais vraiment pas et probablement plus de dix », je cherche à récupérer. D'après mon expérience, le point de croisement se situe autour de huit outils, et ce n'est pas gracieux : les performances se dégradent rapidement une fois que vous le franchissez.

Ce point de décision unique m'a évité des heures de débogage d'appels hallucinés et d'effondrements de raisonnement. J'aurais aimé que quelqu'un me le remette il y a un an.

Questions fréquemment posées

MCP est-il réellement mort ou est-il simplement en difficulté à grande échelle ?

MCP n'est pas mort pour les petits agents ciblés disposant de trois à sept outils : il fonctionne bien là-bas. Il est fonctionnellement mort pour les agents à usage général qui ont besoin d'accéder à des dizaines de services, car l'injection de schéma provoque une surcharge du contexte et des hallucinations de sélection d'outils que les approches basées sur la récupération résolvent proprement. La plupart des équipes de production s’hybrident discrètement.

Qu'est-ce que Corsair et est-il prêt pour la production ?

Corsair est une couche d'intégration open source pour les agents AI (github.com/corsairdev/corsair) qui utilise RAG pour récupérer dynamiquement uniquement les schémas d'outils pertinents par requête au lieu de tous les injecter à l'avance. Il est encore tôt – petit catalogue de plugins, documentation évolutive – mais le modèle architectural qu’il représente est celui vers lequel converge une infrastructure d’agents sérieuse.

Pourquoi l'ajout d'outils MCP aggrave-t-il les agents ?

Chaque outil MCP injecte entre 550 et 1 400 jetons de schéma dans le contexte au début de la conversation. Au-delà de 50 outils, cela consomme 5 à 7 % d'une fenêtre contextuelle de 200 000 avant même que la question de l'utilisateur n'arrive. Une fois que l'utilisation du contexte dépasse environ 70 %, l'attention du modèle se fragmente entre des outils d'apparence similaire, les taux d'hallucinations augmentent et la précision de la sélection des outils s'effondre.

Comment RAG-MCP améliore-t-il la précision de la sélection des outils ?

L'article RAG-MCP (arXiv 2505.03275) a montré que la sélection d'outils basée sur la récupération atteignait une précision de 43,13 % contre 13,62 % pour la référence d'injection de schéma sur le même benchmark, soit plus du triple de la précision avec moins de la moitié des jetons d'invite. Le modèle ne voit que les outils pertinents pour la requête en cours, son attention n'est donc pas fragmentée.

Dois-je migrer de MCP vers une approche basée sur la récupération dès maintenant ?

Si votre agent utilise moins de huit outils et fonctionne bien, restez. Si vous rencontrez des explosions d'hallucinations, augmentez le coût des jetons ou envisagez de dépasser dix outils, commencez dès maintenant à prototyper une couche de récupération comme Corsair. Le point de croisement n'est pas gracieux : les performances se dégradent rapidement une fois que vous le franchissez, et la migration est plus facile avant d'avoir un trafic de production dépendant de l'ancienne architecture.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io