El Model Context Protocol tiene un problema que nadie menciona en los posts de lanzamiento: conectar el servidor MCP oficial de GitHub cuesta aproximadamente 54.000 tokens solo para que el agente sepa qué herramientas tiene disponibles. El equivalente CLI —usar el comando gh— necesita 562 tokens para lo mismo. Una diferencia de casi 100 veces, antes de ejecutar una sola acción real.
Este overhead no es anecdótico. En loops de agentes donde la misma infraestructura se carga repetidamente, el costo se multiplica de forma exponencial. Y el caso de Cloudflare ilustra el extremo: su servidor MCP equivalente a su API completa, sin optimización, consumiría 1,17 millones de tokens — superando la ventana de contexto de los modelos más avanzados disponibles hoy.
El problema estructural de MCP con los tokens
El Model Context Protocol dejó de ser solo de Anthropic para convertirse en estándar bajo la Linux Foundation. La promesa es correcta: conectar LLMs a APIs y herramientas de forma estandarizada es exactamente lo que la infraestructura de agentes necesita.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀El problema está en cómo se implementa esa conectividad. Cuando un agente se conecta a un servidor MCP, todas las definiciones de herramientas — sus parámetros, descripciones, esquemas de entrada — se inyectan en el contexto de forma anticipada y completa. El modelo recibe todo el schema antes de ejecutar su primera acción. La premisa es que el agente necesita conocer todas sus capacidades para razonar qué usar.
Eso funciona bien con 5 herramientas simples. Con una API compleja de decenas de endpoints, se vuelve un problema de escala. Y con múltiples servidores MCP conectados en paralelo — un patrón cada vez más común en agentes empresariales — el consumo de contexto previo a cualquier trabajo real puede dominar el presupuesto de tokens de toda la sesión.
La alternativa: CLI-first para agentes
El argumento de Apideck, documentado en un paper técnico de marzo 2026, es que las CLIs existentes ya resuelven este problema mejor que los servidores MCP, por una razón simple: la documentación se carga bajo demanda, cuando se necesita, no toda de golpe.
Con un agente CLI-first, el flujo cambia: el modelo tiene acceso al comando base (ej. gh) y consulta la documentación específica del subcomando solo cuando va a ejecutarlo. El contexto se usa para trabajo, no para infraestructura. Los 562 tokens mencionados antes no son el costo de ignorar documentación — son el costo de saber exactamente dónde buscar la que necesitas.
Esto no elimina MCP. Para herramientas que no tienen CLI equivalente, o para casos donde la integración estandarizada aporta más que el overhead de tokens, MCP sigue siendo la respuesta correcta. Pero para herramientas con CLIs robustas y bien documentadas — git, kubectl, aws, gh — la alternativa CLI puede ser significativamente más eficiente.
Cuándo usar cada enfoque
La decisión práctica depende de algunos factores:
Prefer MCP cuando: la herramienta no tiene CLI, necesitas descubrimiento automático de capacidades, el equipo no quiere mantener wrappers de CLI, o el volumen de herramientas es bajo y bien acotado.
Prefer CLI cuando: la herramienta ya tiene una CLI madura con buena documentación, el agente va a ejecutar muchas operaciones en un loop, el presupuesto de tokens es el constraint principal, o el schema MCP excede varios miles de tokens.
Para los equipos construyendo sistemas de ingeniería agentiva, este tradeoff es parte del diseño arquitectónico que determina si un agente es viable en producción. Un agente que consume 50.000 tokens de infraestructura por sesión antes de hacer trabajo real tiene costos operativos muy diferentes a uno que arranca con 500.
Por qué importa ahora
A medida que MCP se convierte en estándar y los servidores proliferan, la tentación es conectar todo. Cada proveedor quiere su servidor MCP. Cada API tiene su schema. El resultado, si no se diseña con cuidado, es un agente que pasa la mayoría de su contexto cargando definiciones de herramientas que nunca va a usar en esa sesión.
El principio de carga bajo demanda no es nuevo en ingeniería de software. Aplicarlo al contexto de agentes de IA es simplemente reconocer que el contexto es un recurso finito y caro, y que la arquitectura del agente determina cómo se usa ese recurso antes de que empiece el trabajo real.
