Empezaste con un solo servidor MCP. Acceso a archivos, para que tu agente Claude Code pudiera leer y escribir tu proyecto. Razonable.

Luego agregaste busqueda web. Luego GitHub. Luego una herramienta de base de datos para que el agente pudiera consultar tu esquema directamente. Luego Slack, porque el agente necesitaba revisar un hilo para requisitos. Luego una herramienta de documentacion para tu wiki interno.

Seis servidores MCP. Cada uno registra schemas de herramientas en el contexto del agente. Cada uno amplia la superficie de lo que el agente podria hacer, lo que significa mas tokens gastados en descripciones de herramientas y mas oportunidades para que el agente se desvie del objetivo.

Tu agente sigue escribiendo buen codigo. Pero lo escribe mas lento, y los resultados se han vuelto menos predecibles. No te lo estas imaginando. La ventana de contexto es el cuello de botella, y la estas llenando con plomeria.

El problema de la acumulacion

Los servidores MCP son poderosos. El Model Context Protocol le da a Claude Code acceso a sistemas externos, y cada integracion resuelve genuinamente un problema. El acceso a archivos permite al agente leer tu codebase. La busqueda web le permite consultar documentacion. La integracion con GitHub le permite verificar el estado de PRs.

El problema comienza cuando resuelves cada necesidad del agente agregando otro MCP.

El agente necesita revisar el esquema de la base de datos? Agrega un MCP de Postgres. El agente necesita leer una pagina de Confluence? Agrega un MCP de Confluence. El agente necesita publicar un mensaje en Slack? Agrega un MCP de Slack. Cada uno esta justificado individualmente. En conjunto, crean un problema que es dificil de notar hasta que la calidad de los resultados cae.

Cada servidor MCP registra sus herramientas en el contexto de la conversacion. Un MCP de acceso a archivos podria registrar 5-10 herramientas. Un MCP de base de datos registra otro punado. Un MCP de GitHub agrega mas. Para cuando tienes seis servidores MCP, el agente carga decenas de definiciones de herramientas en su ventana de contexto antes de leer una sola linea de tu codigo.

Esas definiciones de herramientas no son gratis. Consumen tokens. Y mas importante, compiten por la atencion del agente. Cuando un agente tiene 40 herramientas disponibles, cada punto de decision se convierte en una pregunta ramificada: debo usar la herramienta de archivos, la de busqueda, la de base de datos o la de GitHub? El agente gasta presupuesto cognitivo decidiendo como obtener informacion en lugar de usar informacion para resolver tu problema.

El contexto es finito. La atencion es mas escasa.

La ventana de contexto de Claude Code es grande. Eso crea una ilusion peligrosa: que puedes seguir agregando informacion sin consecuencias.

En la practica, el rendimiento del agente se degrada mucho antes de que la ventana de contexto se llene. El problema no es la capacidad. Es la relacion senal-ruido. Un agente con una ventana de contexto de 200K tokens rinde mejor con 50K tokens de informacion enfocada y relevante que con 150K tokens donde los fragmentos relevantes estan dispersos entre schemas de herramientas, respuestas de API y contenidos de archivos tangenciales.

Es el mismo problema que enfrentan los humanos con demasiadas pestanas del navegador. La informacion esta tecnicamente disponible. Encontrarla toma mas tiempo del necesario. Terminas releyendo cosas que ya viste porque el contexto relevante fue desplazado de la memoria de trabajo por el ruido.

Para los agentes, esto se manifiesta como:

Madrigueras de conejo. El agente tiene una herramienta de base de datos, asi que consulta el esquema. El esquema es interesante, asi que consulta datos. Los datos revelan algo inesperado, asi que investiga mas. Veinte minutos despues, tienes un analisis exhaustivo del contenido de tu base de datos y cero progreso en la funcionalidad que pediste.

Confusion de herramientas. Con muchas herramientas disponibles, el agente ocasionalmente elige la incorrecta. Usa la busqueda web para encontrar documentacion que ya esta en un archivo local. Consulta la base de datos cuando la respuesta esta en la descripcion de la tarea. Cada eleccion erronea de herramienta desperdicia tokens e introduce ruido.

Foco diluido. La "atencion" del agente es un recurso finito dentro de cada generacion. Cuando el contexto contiene schemas de herramientas para acceso a archivos, busqueda web, consultas de base de datos, operaciones de GitHub, mensajes de Slack y consultas de wiki, el agente procesa todo eso antes de procesar tu solicitud real. La tarea compite con las herramientas por la prioridad cognitiva.

Contexto acotado: la alternativa a la proliferacion de herramientas

La respuesta reflexiva a "mi agente necesita la informacion X" es darle al agente una herramienta que obtenga X. Pero hay otro enfoque: poner X en la tarea.

Este es el patron de contexto acotado. En lugar de dar a los agentes acceso a todo y esperar que encuentren lo relevante, le das a cada agente una tarea que contiene todo lo que necesita para completar el trabajo. El agente no busca contexto. El contexto se le entrega.

La diferencia es estructural. Con proliferacion de MCPs, el flujo de trabajo del agente se ve asi:

Leer la tarea
Determinar que informacion falta
Usar varias herramientas para recopilar esa informacion
Sintetizar la informacion
Hacer el trabajo real

Con contexto acotado, se ve asi:

Leer la tarea (que contiene todo el contexto necesario)
Hacer el trabajo real

Los pasos 2-4 del primer flujo no son solo overhead. Ahi es donde las cosas salen mal. El agente recopila demasiada informacion, o la informacion equivocada, o se distrae con datos interesantes pero irrelevantes. Cada invocacion de herramienta es un desvio potencial.

Contexto acotado no significa que los agentes no puedan usar herramientas. El acceso a archivos sigue siendo necesario para leer y escribir codigo. Pero significa que el contexto informativo (que construir, por que, que archivos, cuales son los criterios de aceptacion) vive en la tarea, no en una herramienta que el agente debe consultar.

Estructurando tareas como contenedores de contexto

Una tarea que funciona como contenedor de contexto se ve diferente a un ticket tipico de Jira o un issue de GitHub. Es autocontenida. Un agente que la lee deberia tener todo lo que necesita para comenzar a trabajar sin consultar sistemas externos para obtener informacion de fondo.

Asi se ve en la practica:

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.

Observa lo que esta incluido en la tarea. El agente sabe que archivos tocar, que patron seguir, que restricciones existen (sin Redis), y exactamente como se ve "terminado." No necesita un MCP de base de datos para verificar el esquema. No necesita una herramienta de wiki para encontrar el patron de middleware. No necesita buscar en el codebase para entender el enfoque de configuracion. Todo esta en la tarea.

Escribir tareas asi requiere mas esfuerzo inicial. Un ticket tipico podria decir "Agregar rate limiting al endpoint de busqueda" y dejar que el agente descifre el resto. Pero ese proceso de descifrar es exactamente de donde viene la proliferacion de MCPs: el agente necesita informacion, asi que le das herramientas, y las herramientas consumen contexto.

CLAUDE.md como limite de contexto

La tarea le dice al agente que construir. El archivo CLAUDE.md le dice en que mundo vive.

Si estas ejecutando multiples agentes Claude Code, cada uno deberia tener un CLAUDE.md que defina su alcance, no solo sus instrucciones. Piensa en ello como una cerca de contexto: todo dentro de la cerca es responsabilidad del agente, y todo afuera es problema de alguien mas.

## 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

Este CLAUDE.md elimina toda una categoria de necesidad de MCPs. El agente frontend no necesita un MCP de base de datos porque no toca la base de datos. No necesita una herramienta de despliegue porque no maneja infraestructura. Su ventana de contexto se mantiene limpia porque su alcance es estrecho.

La seccion "how to get information" es critica. En lugar de darle al agente una herramienta para buscar contratos de API, le dices donde estan. En lugar de darle acceso a Slack para preguntar al equipo de backend, le dices que cree una tarea. El flujo de informacion es explicito, no emergente.

Es el mismo principio detras de gestionar tareas para agentes Claude Code: los agentes trabajan mejor con limites claros que con acceso ilimitado. Cada limite que defines es un servidor MCP que no necesitas.

Cuando aun necesitas MCPs

El contexto acotado no elimina los MCPs por completo. Algunas herramientas son genuinamente necesarias:

Acceso al sistema de archivos es innegociable. Los agentes necesitan leer y escribir codigo. Esto no es proliferacion; es la base.

Herramientas de control de versiones (operaciones git) son parte del flujo de trabajo central del agente. Hacer commits, crear ramas y hacer diffs son acciones de implementacion, no desvios de recopilacion de informacion.

Servidores de lenguaje y linters proporcionan retroalimentacion en tiempo real que no puede precargarse en una descripcion de tarea. El agente necesita saber si su codigo compila y pasa las verificaciones de tipos.

La distincion es entre herramientas de implementacion (cosas que el agente usa para hacer el trabajo) y herramientas de recopilacion de informacion (cosas que el agente usa para descubrir cual es el trabajo). Las herramientas de implementacion pertenecen a la configuracion MCP del agente. Las herramientas de recopilacion de informacion son una senal de que tus descripciones de tareas necesitan mas contexto.

Si te encuentras agregando un MCP porque "el agente necesita buscar X," preguntate si X podria estar en la tarea. Si la respuesta es si, ponlo ahi. Si no (porque X cambia frecuentemente, es demasiado grande, o requiere datos en tiempo real), entonces el MCP esta justificado. Pero vale la pena hacer esa pregunta cada vez.

Beads: tareas como contexto acotado

Este es el patron que usamos para coordinar 13 agentes Claude Code en un solo codebase. Cada agente recibe una tarea que contiene su alcance completo, y un CLAUDE.md que define sus limites. La combinacion significa que los agentes raramente necesitan herramientas mas alla del acceso a archivos y git.

El issue tracker que hace esto posible es beads, un CLI open-source y local-first. Cada "bead" es una unidad de trabajo autocontenida: titulo, descripcion, criterios de aceptacion y un hilo de comentarios donde los agentes publican planes e informes de finalizacion.

Crear una tarea con contexto embebido:

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

El agente reclama la tarea y la lee:

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

Todo lo que el agente necesita esta en el bead. La descripcion incluye archivos, patrones y restricciones. El agente no necesita un MCP de wiki para encontrar el patron de middleware, porque la tarea dice "see server/middleware/auth.ts." No necesita un MCP de base de datos, porque la tarea dice "no Redis, use in-memory store."

Antes de escribir codigo, el agente publica su plan de implementacion:

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"

Despues de la implementacion, el agente publica lo que hizo y como verificarlo:

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)"

Todo el ciclo de vida, desde la creacion de la tarea hasta la implementacion y verificacion, vive en un solo lugar. No se perdio contexto por saltar entre herramientas. No se gastaron tokens consultando sistemas externos por informacion que podria haberse escrito en la tarea.

Viendo los limites de contexto en toda la flota

Cuando ejecutas multiples agentes con contexto acotado, surge una nueva pregunta: la tarea de quien referencia los archivos de quien? Donde se superponen los limites de contexto? Que agente esta trabajando en la capa de API, y puedo asignar el trabajo de frontend en paralelo de manera segura?

Aqui es donde el CLI por si solo se queda corto. bd list muestra tareas y estados. No muestra las relaciones entre ellas, ni te permite detectar cuando los alcances de dos agentes han derivado hacia el mismo territorio.

Beadbox es un dashboard en tiempo real que visualiza estos limites. Muestra arboles de dependencias (que tareas bloquean cuales), progreso de epics (que tan avanzada esta una funcionalidad en todas sus subtareas) y propiedad de agentes (quien trabaja en que). Ves la imagen completa sin cambiar entre ventanas de terminal y ensamblarla en tu cabeza.

Es gratis durante la beta y se ejecuta completamente en tu maquina. Sin cuentas, sin sincronizacion en la nube, sin telemetria sobre los datos de tu proyecto.

Si estas construyendo flujos de trabajo como este, dale una estrella a Beadbox en GitHub.

Gestion del contexto de agentes Claude Code sin proliferacion de MCPs