curl para MCP: Por qué los agentes de código prefieren la CLI

He estado pensando mucho en cómo los agentes de código interactúan con servicios externos. En Arcade.dev construimos herramientas agénticas, así que paso la mayor parte del día viendo cómo los agentes de AI intentan hacer cosas reales en el mundo real. Y hay un patrón que me tiene inquieto.

Estamos construyendo integraciones cada vez más complejas para conectar agentes de código a servidores MCP. SDKs personalizados, conexiones persistentes, configuraciones de cliente elaboradas. Pero aquí está el detalle: estos agentes ya saben usar la CLI. Se entrenaron con millones de sesiones de shell. curl, git, docker, npm. Conocen los patrones. Flags, stdin, stdout, pipes, códigos de salida; todo está ahí.

¿Por qué entonces les estamos enseñando una interfaz nueva?

Consigue mcpx ahora →

¿Por qué no usar APIs directamente?

Sé lo que algunos están pensando: “¿Por qué no saltarse MCP por completo y darle al agente acceso directo a la API?”

He visto agentes intentarlo. Se rompe de maneras predecibles.

Las APIs están diseñadas para desarrolladores que leen documentación, entienden los flujos de autenticación y saben qué endpoints llamar y en qué orden. Un agente frente a una API REST cruda tiene que descifrar: ¿cuáles de estos 200 endpoints necesito realmente? ¿Cuál es el esquema de auth? ¿Qué headers son obligatorios? ¿Cómo pagino los resultados? ¿Qué significa el error 422 en el contexto específico de esta API?

Eso es mucho trabajo de inferencia antes de que ocurra una sola acción útil, y todo ese trabajo quema tokens e introduce puntos de falla.

MCP resuelve esto a nivel de protocolo. Ofrece una forma estándar de anunciar capacidades, describir esquemas, manejar la autenticación y gestionar el ciclo de vida de las llamadas a herramientas. Una herramienta MCP no expone “aquí tienes 200 endpoints, buena suerte”. Expone “aquí están las 12 cosas que puedes hacer, esto es exactamente lo que necesita cada una y así te autenticas”. El agente gasta sus tokens en la tarea, no en descifrar la plomería.

Nadie escribió posts declarando “REST está muerto, usa solo curl”. curl es cómo hablas con REST desde una terminal. mcpx es cómo hablas con MCP desde una terminal. La misma relación. El protocolo sigue importando. Lo que cambió es la interfaz.

Lo mejor de los dos mundos

¿Y si la interfaz del agente con MCP fuera simplemente… la CLI?

Esa es la idea detrás de mcpx. Es una herramienta de línea de comandos que habla MCP por dentro, pero presenta una interfaz de shell por fuera. Como curl: no necesitas entender HTTP/2 ni los handshakes de TLS para hacer una llamada a una API. Solo escribes un comando y obtienes una respuesta.

El flujo de trabajo para un agente se ve así:

bash

# 1. Search for relevant tools across all configured MCP servers
mcpx search "create issue"

# 2. Inspect a specific tool's schema
mcpx info linear create_issue

# 3. Execute it
mcpx exec linear create_issue '{"title": "Fix the login bug", "priority": "high"}'

Sin conexiones persistentes que administrar. Sin esquemas de herramientas inflando el system prompt. El agente descubre lo que necesita bajo demanda, valida los inputs localmente antes de enviarlos y recibe una salida estructurada que puede parsear.

Cuándo usar CLI, cuándo usar remoto

Quiero ser honesto sobre dónde encaja mcpx y dónde no. Esto importa, y creo que el debate actual no está siendo suficientemente preciso al respecto.

CLI (mcpx) está diseñado para agentes de código de un solo usuario en una sola máquina.

Eres desarrollador. Usas Claude Code, Cursor, Windsurf o Cline. Quieres que tu agente interactúe con GitHub, Linear, Slack o tu base de datos sin configurar un cliente MCP personalizado para cada herramienta. La mitad de los clientes MCP todavía no tienen integraciones sólidas, o están al día con los flujos de auth, o su soporte MCP “técnicamente funciona” pero no está listo para producción. mcpx evita todo eso. Una sola CLI, una sola instalación, todos los servidores MCP que tu agente necesite.

Ese es el punto ideal: un desarrollador, su agente, su máquina.

MCP remoto (HTTP) está diseñado para aplicaciones agénticas multiusuario.

Si estás construyendo algo con LangChain, CrewAI o cualquier framework donde múltiples usuarios disparan agentes que actúan en su nombre, necesitas el flujo completo de MCP remoto. Aislamiento multiusuario, delegación OAuth por usuario, permisos por tenant, auditoría centralizada. La CLI no es la interfaz correcta para eso. Una conexión MCP basada en HTTP a través de un gateway sí lo es.

No son enfoques que compiten. Son interfaces distintas para la misma infraestructura:

Mismo gateway. Mismas herramientas. Mismo auth. Mismo registro de auditoría. Lo único que cambia es cómo te conectas. mcpx es la columna izquierda. Si necesitas la columna derecha, necesitas un MCP remoto, y esa es la decisión correcta.

Construyo mcpx porque la columna izquierda no tenía buenas herramientas. No porque la columna derecha no importe.

Por qué esto importa para la eficiencia de tokens

Hay una razón práctica por la que este enfoque funciona bien para agentes de código: los tokens son caros y las ventanas de contexto son finitas.

La integración MCP típica carga el esquema de todas las herramientas disponibles en el system prompt del agente. Si tienes 50 herramientas en 5 servidores, eso es mucho contexto gastado en esquemas que el agente quizás nunca use. Con mcpx, el agente empieza sin herramientas en contexto y descubre progresivamente lo que necesita. Primero busca, luego inspecciona, luego ejecuta. Solo pagas por lo que realmente usas.

Y como cada llamada es efímera (lanzas el proceso, obtienes el resultado, listo), no hay estado de conexión que administrar entre turnos. El contexto del agente se mantiene limpio.

Las buenas herramientas importan

Si vamos a pedirles a los agentes que usen la CLI para MCP, las herramientas tienen que ser buenas. No “técnicamente funciona” buenas, sino realmente buenas. Como curl lo es para HTTP, o jq lo es para JSON.

Eso significa:

Salida inteligente - tablas legibles en la terminal, JSON cuando se redirige a otra herramienta. Detección automática, sin flags.

Depuración real - mcpx -v te muestra encabezados HTTP, mensajes JSON-RPC y tiempos de ida y vuelta. Cuando algo falla, puedes ver exactamente qué pasó. Esto es lo que se ve al correrlo contra un gateway de producción como el de Arcade:

mcpx -v exec arcade Gmail_WhoAmI

> POST https://api.arcade.dev/mcp/evan-coding
> authorization: Bearer eyJhbGci...
> content-type: application/json
< 200 OK (142ms)
< x-request-id: abc123

Ese encabezado de autorización no es una API key compartida guardada en un archivo .env. Es un token OAuth con alcance definido: el Gateway manejó el flujo de autenticación, aplicó los permisos y registró la llamada. Yo solo escribí un comando.

Búsqueda que funciona - la coincidencia por palabras clave está bien cuando sabes lo que buscas. Pero los agentes muchas veces no lo saben. mcpx incluye búsqueda semántica con un modelo de embeddings local (sin API key, sin llamadas a la red) para que los agentes encuentren herramientas describiendo lo que quieren lograr.

Soporte completo del protocolo - OAuth para servidores remotos, tareas asíncronas para operaciones largas, entrada solicitada por el servidor (elicitation), logging estructurado. La especificación MCP avanza rápido y tu cliente CLI necesita seguirle el ritmo.

Los clientes actualizados también importan

Esta es la parte que no recibe suficiente atención. MCP es un protocolo joven y la especificación evoluciona rápido. Tareas, elicitation, logging estructurado: son adiciones relativamente recientes que importan en el mundo real.

mcpx sigue el SDK de MCP más reciente e implementa la especificación completa: transportes stdio y HTTP (con fallback automático de Streamable HTTP a SSE), descubrimiento OAuth y renovación de tokens, validación de JSON Schema, gestión de tareas con cancelación y flujos de entrada solicitados por el servidor. Cuando la especificación agrega algo nuevo, el CLI debe soportarlo; de lo contrario, los agentes quedan con una vista parcial de lo que MCP puede hacer.

Pruébalo

mcpx es open source (MIT) y está disponible como binario único o vía npm:

bash

# Install
bun install -g @evantahler/mcpx
# or
curl -fsSL https://raw.githubusercontent.com/evantahler/mcpx/main/install.sh | bash

# Configure a server
mcpx add github --url https://mcp.github.com

# Start exploring
mcpx search "pull request"

Si usas Claude Code o Cursor, mcpx incluye skills de agente integradas:

bash

mcpx skill install --claude # Claude Code
mcpx skill install --cursor # Cursor

Un solo comando y tu agente de código sabe cómo descubrir y usar herramientas MCP bajo demanda, sin schema inflado ni conexiones persistentes.

Yo uso mcpx contra el gateway de Arcade a diario, así accedo a herramientas de GitHub, Slack, Google Workspace, Linear y otros servicios sin configurar cada uno por separado. El gateway maneja OAuth y el registro de auditoría, así que no tengo que preocuparme por eso.

bash

mcpx add arcade --url https://api.arcade.dev/mcp/engineering-tools
mcpx search "send email"

Si estás construyendo con servidores MCP o construyendo servidores MCP, dale una oportunidad. La diferencia en velocidad de iteración ha sido significativa para mí.

Obtén mcpx en GitHub → Licencia MIT. Abre un issue si algo falla, o un PR si quieres arreglarlo.

Evan Tahler es Director de Ingeniería en Arcade, el único runtime para MCP. Construyó mcpx porque algo necesitaba existir y no existía.