Vous avez commence avec un seul serveur MCP. L'acces aux fichiers, pour que votre agent Claude Code puisse lire et ecrire votre projet. Raisonnable.

Puis vous avez ajoute la recherche web. Puis GitHub. Puis un outil de base de donnees pour que l'agent puisse interroger votre schema directement. Puis Slack, parce que l'agent devait verifier un fil de discussion pour les exigences. Puis un outil de documentation pour votre wiki interne.

Six serveurs MCP. Chacun enregistre des schemas d'outils dans le contexte de l'agent. Chacun elargit la surface de ce que l'agent pourrait faire, ce qui signifie plus de tokens depenses en descriptions d'outils et plus d'occasions pour l'agent de s'eloigner de sa tache.

Votre agent ecrit toujours du bon code. Mais il l'ecrit plus lentement, et les resultats sont devenus moins previsibles. Vous ne l'imaginez pas. La fenetre de contexte est le goulot d'etranglement, et vous la remplissez avec de la plomberie.

Le probleme de l'accumulation

Les serveurs MCP sont puissants. Le Model Context Protocol donne a Claude Code l'acces a des systemes externes, et chaque integration resout veritablement un probleme. L'acces aux fichiers permet a l'agent de lire votre codebase. La recherche web lui permet de consulter de la documentation. L'integration GitHub lui permet de verifier le statut des PRs.

Le probleme commence quand vous resolvez chaque besoin de l'agent en ajoutant un autre MCP.

L'agent doit verifier le schema de la base de donnees ? Ajoutez un MCP Postgres. L'agent doit lire une page Confluence ? Ajoutez un MCP Confluence. L'agent doit poster un message Slack ? Ajoutez un MCP Slack. Chacun est justifie individuellement. Collectivement, ils creent un probleme difficile a remarquer tant que la qualite des resultats ne chute pas.

Chaque serveur MCP enregistre ses outils dans le contexte de la conversation. Un MCP d'acces aux fichiers peut enregistrer 5 a 10 outils. Un MCP de base de donnees en enregistre d'autres. Un MCP GitHub en ajoute davantage. Quand vous avez six serveurs MCP, l'agent porte des dizaines de definitions d'outils dans sa fenetre de contexte avant de lire une seule ligne de votre code.

Ces definitions d'outils ne sont pas gratuites. Elles consomment des tokens. Et surtout, elles rivalisent pour l'attention de l'agent. Quand un agent a 40 outils disponibles, chaque point de decision devient une question de branchement : dois-je utiliser l'outil fichier, l'outil de recherche, l'outil base de donnees ou l'outil GitHub ? L'agent depense du budget cognitif a decider comment obtenir l'information au lieu d'utiliser l'information pour resoudre votre probleme.

Le contexte est fini. L'attention est plus rare.

La fenetre de contexte de Claude Code est grande. Cela cree une illusion dangereuse : que vous pouvez continuer a ajouter des informations sans consequence.

En pratique, les performances de l'agent se degradent bien avant que la fenetre de contexte ne se remplisse. Le probleme n'est pas la capacite. C'est le rapport signal-bruit. Un agent avec une fenetre de contexte de 200K tokens performe mieux avec 50K tokens d'information ciblee et pertinente qu'avec 150K tokens ou les elements pertinents sont disperses parmi des schemas d'outils, des reponses d'API et des contenus de fichiers tangentiels.

C'est le meme probleme que les humains rencontrent avec trop d'onglets de navigateur. L'information est techniquement disponible. La trouver prend plus de temps que prevu. On finit par relire des choses qu'on a deja vues parce que le contexte pertinent a ete chasse de la memoire de travail par le bruit.

Pour les agents, cela se manifeste par :

Les terriers de lapin. L'agent a un outil de base de donnees, donc il interroge le schema. Le schema est interessant, donc il interroge des donnees. Les donnees revelent quelque chose d'inattendu, donc il poursuit son investigation. Vingt minutes plus tard, vous avez une analyse approfondie du contenu de votre base de donnees et zero progres sur la fonctionnalite demandee.

La confusion d'outils. Avec de nombreux outils disponibles, l'agent choisit parfois le mauvais. Il utilise la recherche web pour trouver de la documentation qui est deja dans un fichier local. Il interroge la base de donnees quand la reponse est dans la description de la tache. Chaque mauvais choix d'outil gaspille des tokens et introduit du bruit.

La dilution du focus. L'attention de l'agent est une ressource finie a chaque generation. Quand le contexte contient des schemas d'outils pour l'acces aux fichiers, la recherche web, les requetes de base de donnees, les operations GitHub, les messages Slack et les consultations de wiki, l'agent traite tout cela avant de traiter votre requete reelle. La tache entre en competition avec l'outillage pour la priorite cognitive.

Le contexte borne : l'alternative a la proliferation d'outils

La reponse reflexe a "mon agent a besoin de l'information X" est de donner a l'agent un outil qui recupere X. Mais il y a une autre approche : mettre X dans la tache.

C'est le patron du contexte borne. Au lieu de donner aux agents l'acces a tout et d'esperer qu'ils trouvent ce qui est pertinent, vous donnez a chaque agent une tache qui contient tout ce dont il a besoin pour terminer le travail. L'agent ne cherche pas le contexte. Le contexte lui est livre.

La difference est structurelle. Avec la proliferation de MCPs, le workflow de l'agent ressemble a :

Lire la tache
Determiner quelles informations manquent
Utiliser divers outils pour collecter ces informations
Synthetiser les informations
Faire le travail reel

Avec le contexte borne, ca ressemble a :

Lire la tache (qui contient tout le contexte necessaire)
Faire le travail reel

Les etapes 2 a 4 du premier workflow ne sont pas juste du surcharge. C'est la que les choses derapent. L'agent collecte trop d'information, ou la mauvaise information, ou se laisse distraire par des donnees interessantes mais non pertinentes. Chaque invocation d'outil est un detour potentiel.

Le contexte borne ne signifie pas que les agents ne peuvent pas utiliser d'outils. L'acces aux fichiers reste necessaire pour lire et ecrire du code. Mais cela signifie que le contexte informationnel (quoi construire, pourquoi, quels fichiers, quels sont les criteres d'acceptation) vit dans la tache, pas dans un outil que l'agent doit interroger.

Structurer les taches comme conteneurs de contexte

Une tache qui fonctionne comme conteneur de contexte est differente d'un ticket Jira ou d'un issue GitHub classique. Elle est autonome. Un agent qui la lit devrait avoir tout ce qu'il lui faut pour commencer a travailler sans interroger de systemes externes.

Voici a quoi cela ressemble en pratique :

Title: Add rate limiting to /api/search endpoint

Description:
The /api/search endpoint currently has no rate limiting.
Add a token bucket rate limiter at 100 requests/minute per IP.

Files to modify:
- server/middleware/rate-limit.ts (create new)
- server/routes/search.ts (apply middleware)
- server/config.ts (add RATE_LIMIT_RPM env var)

Acceptance criteria:
- Requests beyond 100/min from same IP return 429
- Rate limit resets after 60 seconds
- Config value overridable via environment variable
- Existing tests still pass

Context:
- We use Express middleware pattern (see server/middleware/auth.ts for example)
- The config module uses dotenv (see server/config.ts lines 1-15)
- No Redis available; use in-memory store. This is a single-instance app.

Dependencies: None. This can run independently.

Remarquez ce qui est integre dans la tache. L'agent sait quels fichiers toucher, quel patron suivre, quelles contraintes existent (pas de Redis), et exactement a quoi ressemble "termine." Il n'a pas besoin d'un MCP de base de donnees pour verifier le schema. Il n'a pas besoin d'un outil wiki pour trouver le patron de middleware. Il n'a pas besoin de chercher dans le codebase pour comprendre l'approche de configuration. Tout est dans la tache.

Ecrire des taches de cette facon demande plus d'effort en amont. Un ticket classique pourrait dire "Ajouter le rate limiting au endpoint de recherche" et laisser l'agent decouvrir le reste. Mais ce processus de decouverte est exactement ce qui engendre la proliferation de MCPs : l'agent a besoin d'information, donc vous lui donnez des outils, et les outils consomment du contexte.

CLAUDE.md comme frontiere de contexte

La tache dit a l'agent quoi construire. Le fichier CLAUDE.md lui dit dans quel monde il evolue.

Si vous executez plusieurs agents Claude Code, chacun devrait avoir un CLAUDE.md qui definit son perimetre, pas seulement ses instructions. Voyez-le comme une cloture de contexte : tout a l'interieur est la responsabilite de l'agent, et tout a l'exterieur est le probleme de quelqu'un d'autre.

## Identity
Frontend engineer for ProjectX. You own components/, hooks/,
and app/pages/. You write React components with TypeScript.

## What you do NOT own
- server/ (backend engineer handles this)
- database/ (DBA handles schema changes)
- infrastructure/ (ops handles deployment configs)

## How to get information you need
- API contracts are in docs/api-spec.md
- Design specs are linked in the task description
- If you need backend changes, create a task for the backend agent

Ce CLAUDE.md elimine toute une categorie de besoin de MCPs. L'agent frontend n'a pas besoin d'un MCP de base de donnees parce qu'il ne touche pas a la base de donnees. Il n'a pas besoin d'un outil de deploiement parce qu'il ne gere pas l'infrastructure. Sa fenetre de contexte reste propre parce que son perimetre est etroit.

La section "how to get information" est cruciale. Au lieu de donner a l'agent un outil pour chercher les contrats d'API, vous lui dites ou se trouvent les contrats. Au lieu de lui donner un acces Slack pour poser des questions a l'equipe backend, vous lui dites de creer une tache. Le flux d'information est explicite, pas emergent.

C'est le meme principe que pour gerer les taches des agents Claude Code : les agents travaillent mieux avec des limites claires qu'avec un acces illimite. Chaque limite que vous definissez est un serveur MCP dont vous n'avez pas besoin.

Quand les MCPs restent necessaires

Le contexte borne n'elimine pas completement les MCPs. Certains outils sont veritablement necessaires :

L'acces au systeme de fichiers est non negociable. Les agents doivent lire et ecrire du code. Ce n'est pas de la proliferation ; c'est la base.

Les outils de gestion de version (operations git) font partie du workflow central de l'agent. Committer, creer des branches et faire des diffs sont des actions d'implementation, pas des detours de collecte d'information.

Les serveurs de langage et les linters fournissent du feedback en temps reel qui ne peut pas etre pre-charge dans une description de tache. L'agent doit savoir si son code compile et passe les verifications de type.

La distinction est entre les outils d'implementation (ce que l'agent utilise pour faire le travail) et les outils de collecte d'information (ce que l'agent utilise pour comprendre quel est le travail). Les outils d'implementation appartiennent a la configuration MCP de l'agent. Les outils de collecte d'information sont le signe que vos descriptions de taches ont besoin de plus de contexte.

Si vous vous trouvez a ajouter un MCP parce que "l'agent a besoin de chercher X," demandez-vous si X pourrait etre dans la tache. Si oui, mettez-le la. Si non (parce que X change frequemment, est trop volumineux ou necessite des donnees en temps reel), alors le MCP est justifie. Mais la question merite d'etre posee a chaque fois.

Beads : les taches comme contexte borne

C'est le patron que nous utilisons pour coordonner 13 agents Claude Code sur un seul codebase. Chaque agent recoit une tache contenant son perimetre complet, et un CLAUDE.md qui definit ses limites. Cette combinaison signifie que les agents ont rarement besoin d'outils au-dela de l'acces aux fichiers et de git.

Le gestionnaire de taches qui rend cela possible est beads, un CLI open-source et local-first. Chaque "bead" est une unite de travail autonome : titre, description, criteres d'acceptation et un fil de commentaires ou les agents publient leurs plans et rapports de completion.

Creer une tache avec du contexte integre :

bd create --title "Add rate limiting to /api/search" \
  --description "Token bucket at 100 req/min per IP. \
    Files: server/middleware/rate-limit.ts (new), \
    server/routes/search.ts, server/config.ts. \
    Pattern: see server/middleware/auth.ts. \
    Constraint: in-memory store, no Redis." \
  --priority p2

L'agent reclame la tache et la lit :

bd update bb-r3k2 --claim --actor eng1
bd show bb-r3k2

Tout ce dont l'agent a besoin est dans le bead. La description inclut les fichiers, les patrons et les contraintes. L'agent n'a pas besoin d'un MCP wiki pour trouver le patron de middleware, parce que la tache dit "see server/middleware/auth.ts." Il n'a pas besoin d'un MCP base de donnees, parce que la tache dit "no Redis, use in-memory store."

Avant d'ecrire du code, l'agent publie son plan d'implementation :

bd comments add bb-r3k2 --author eng1 "PLAN:
1. Create server/middleware/rate-limit.ts with token bucket
2. Wire into search route in server/routes/search.ts
3. Add RATE_LIMIT_RPM to server/config.ts with default 100
4. Add tests for 429 response and reset behavior"

Apres l'implementation, l'agent publie ce qu'il a fait et comment le verifier :

bd comments add bb-r3k2 --author eng1 "DONE: Rate limiting added.
Commit: abc123

Verification:
- curl /api/search 101 times in 60s, 101st returns 429
- Set RATE_LIMIT_RPM=5, verify limit changes
- pnpm test passes (3 new tests added)"

L'ensemble du cycle de vie, de la creation de la tache a l'implementation jusqu'a la verification, vit au meme endroit. Aucun contexte n'a ete perdu a cause du saut entre outils. Aucun token n'a ete depense a interroger des systemes externes pour des informations qui auraient pu etre ecrites dans la tache.

Voir les frontieres de contexte a travers la flotte

Quand vous executez plusieurs agents avec du contexte borne, une nouvelle question emerge : la tache de qui reference les fichiers de qui ? Ou les frontieres de contexte se chevauchent-elles ? Quel agent travaille sur la couche API, et puis-je assigner le travail frontend en parallele en toute securite ?

C'est la que le CLI seul atteint ses limites. bd list montre les taches et les statuts. Il ne montre pas les relations entre elles, ni ne permet de reperer quand les perimetres de deux agents ont derive vers le meme territoire.

Beadbox est un tableau de bord en temps reel qui visualise ces frontieres. Il montre les arbres de dependances (quelles taches bloquent lesquelles), la progression des epics (l'avancement d'une fonctionnalite a travers toutes ses sous-taches) et la propriete des agents (qui travaille sur quoi). Vous voyez la vue d'ensemble sans basculer entre les fenetres de terminal et la reconstituer dans votre tete.

C'est gratuit pendant la beta et fonctionne entierement sur votre machine. Pas de comptes, pas de synchronisation cloud, pas de telemetrie sur les donnees de votre projet.

Si vous construisez des workflows comme celui-ci, mettez une etoile sur Beadbox sur GitHub.

Gerer le contexte des agents Claude Code sans proliferation de MCPs