Este documento resume un patrón para evitar que las respuestas de herramientas MCP "inunden" la ventana de contexto principal, usando aislamiento por subagentes + modos resumen/detalle + separación lectura/escritura.
Cuando el agente principal llama herramientas MCP directamente, la respuesta completa se inyecta en el contexto principal. Esto suele causar dos problemas:
En vez de usar el contexto principal como "almacén", delega lecturas a un subagente en un contexto aislado y devuelve solo lo esencial.
[Main] "Revisa el PR #123"
-> spawn
[Subagente (contexto aislado)]
-> Metadatos del PR
-> Diff
-> Lista de archivos
-> Reviews/comentarios/estado
-> Quitar ruido + análisis de patrones + estructurar
<- Devolver solo resumen (o texto completo)
Esto es aplicar el principio de "progressive disclosure" de gestión de contexto/tokens (coreano) a la capa de herramientas.
Dar capacidades de escritura a un subagente de lectura aumenta el impacto de prompt injection o acciones no deseadas.
Las búsquedas tipo Context7 separan "Resolve" y "Fetch":
resolveLibraryId convierte un nombre difuso en un ID precisoqueryDocs obtiene solo lo necesario con "ID + pregunta"Esto se generaliza a otras integraciones MCP.
El subagente agrupa esto como "consulta compuesta" y devuelve resumen + riesgos + próximos pasos.
Entonces "Resolve (buscar) -> Fetch (leer detalle)" suele mejorar tokens y calidad.
Aquí, "upstream" no significa repos de servidores MCP. Significa que un vendor (p. ej. Atlassian/GitHub) distribuya un plugin oficial que implemente aislamiento por subagentes.
Es técnicamente posible, pero la distribución oficial suele tener incentivos débiles y una carga de mantenimiento y responsabilidad mucho mayor:
Además, MCP se centra en el intercambio de contexto y deja la gestión del presupuesto de contexto (resumen/caché/consultas compuestas) a hosts y middleware; por eso este patrón suele aparecer como middleware de usuarios/comunidad más que como plugin oficial del vendor.
Esta idea encaja especialmente en integraciones cuyo objetivo principal es obtener información no estructurada (read), más que en MCPs de manipulación directa (write).
Plantilla común:
Ejemplos genéricos:
La clave no es hacer el server más listo; es que el middleware gestione el presupuesto de contexto.
Comparación aproximada basada en caracteres inyectados al contexto principal.
| Tipo | MCP directo | Subagente | Ahorro |
|---|---|---|---|
| Docs (routing) | 12,800 chars | 3,800 chars | 70% |
| Docs (hooks) | 15,000 chars | 3,200 chars | 79% |
| Issue único | 1,200 chars | 600 chars | 50% |
| Búsqueda (10) | 12,000 chars | 1,100 chars | 91% |
| Búsqueda docs (5) | 3,000 chars | 2,000 chars | 33% |
| Resumen PR | 14,500 chars | 2,500 chars | 83% |
| Diff PR grande | 30,000 chars | 3,500 chars | 88% |
| Consulta PR compuesta | 59,500 chars | 3,500 chars | 94% |
Estructura minimal, neutral al proveedor.
mcp-subagent-plugins/
.claude-plugin/marketplace.json
plugins/acme-github/{plugin.json,commands,skills,agents}
plugins/acme-atlassian/{...}
plugins/acme-context7/{...}