Si eres desarrollador y has escuchado mucho de MCP, CLI y skills, pero todavía no tienes claro cuándo usar cada uno, aquí va un ejemplo práctico. Vamos a crear una aplicación sencilla de tareas y le vamos a añadir dos "puertas" para que una IA pueda manejarla: un CLI y un servidor MCP.

La idea no es el proyecto en sí, sino entender para qué sirve cada pieza. Y hay un detalle interesante: con cualquiera de las dos opciones, los tokens no los pagas tú, porque el usuario usa su propia suscripción (Claude, Codex u otro agente) para manejar tu aplicación. Tu proyecto solo expone las acciones.

🎥 Mira el video completo: CLI vs MCP: hice que Claude y Codex controlen mi app

Antes de la IA: frontend, backend y API

Para entender el MCP y el CLI primero hay que recordar cómo se construye una aplicación típica:

  • El frontend es la interfaz que ve el usuario.
  • El backend es una API que recibe los datos y se comunica con la base de datos.
  • La base de datos guarda la información.

La pieza más importante aquí es la API, porque es el puente para que otras aplicaciones se comuniquen con la tuya. Ese patrón no ha cambiado: si sabes que tu proyecto se va a conectar con otros sistemas, crea una API. Hoy, si generas código con IA, puede que el agente lo meta todo en un solo proyecto y se salte la API; en un proyecto importante, en mi opinión, es una mala idea.

El tercer usuario de tu aplicación: los agentes

Antes tu aplicación tenía dos tipos de usuarios: la persona que usa la interfaz y otras aplicaciones que se conectan por la API. Ahora hay un tercero: los agentes de IA, que quieren ir directo a tus datos para hacer tareas en nombre del usuario, sin pasar por la interfaz.

No hay una sola forma de que una IA se conecte a tu aplicación, y ahí es donde entran el MCP y el CLI. La elección depende sobre todo de quién es tu usuario y desde dónde trabaja.

MCP: conectores para cualquier usuario

Si tu usuario usa interfaces como la web de ChatGPT, Claude o sus apps de escritorio, probablemente no es técnico y solo quiere que la IA acceda a sus datos de forma simple. Para él, la opción es un MCP.

En Claude, por ejemplo, los MCP aparecen como conectores en la configuración. El usuario pulsa Conectar, inicia sesión en la plataforma (en el video lo hago con Supabase, que incluso me pide elegir una organización) y autoriza el acceso. A partir de ahí la IA tiene una lista de tools o herramientas: crear un proyecto, ejecutar SQL, consultar gastos…

Algo importante: la IA solo puede hacer lo que esas herramientas permiten. Si no existe una herramienta para eliminar un proyecto, el agente no puede eliminarlo.

CLI + skills: la opción para desarrolladores

Si tus usuarios son técnicos y trabajan con herramientas de terminal o editores de código, tienes otra opción: un CLI, una herramienta de consola. Los CLI existían mucho antes de la IA, pero como un agente también puede ejecutar comandos, se convierten en una alternativa al MCP.

La diferencia es que el usuario tiene que instalar el CLI. Y como puede tener muchos comandos, se complementa con un skill: un texto que describe la herramienta y sus comandos para que el agente sepa usarla. El formato de skills (un archivo SKILL.md) nació en Anthropic y hoy es un estándar abierto que entienden herramientas como Claude Code, Codex o Cursor.

La demo: un CRUD de tareas con Express y PostgreSQL

Le pedí a Claude Code un CRUD de tareas, pero con un requisito clave: un backend real (Express sobre Node.js) conectado a una base de datos PostgreSQL, no solo datos guardados en el navegador. Puede ser cualquier lenguaje o base de datos; es solo mi preferencia. El resultado es una app sencilla para crear, marcar, editar y eliminar tareas.

Crear el CLI e instalarlo como comando global

Después le pedí: "Crea un CLI que permita comunicarse con la API y permita hacer el CRUD". Eso genera un proyecto aparte, una carpeta cli, que es otro cliente de la API.

Un CLI hay que instalarlo como comando del sistema, así que le pedí que lo instalara como comando global. Ahora tengo un comando tareas:

tareas --help                          # lista las operaciones disponibles
tareas create "Una tarea desde el CLI"
tareas get 38

Si refrescas la interfaz, la tarea creada desde la terminal aparece en la app: es otra forma de llegar a los mismos datos.

Codex usando el CLI

Para comprobar que cualquier agente puede usarlo, abrí Codex, que no sabía nada de este proyecto (la app la creé con Claude Code), y le pedí crear tres tareas con el CLI. Lo primero que hizo fue ejecutar tareas --help para descubrir los comandos; luego usó create con título, estado y prioridad. También le pedí renombrar una tarea y lo hizo sin problema.

El skill del CLI

Luego le pedí a Claude un skill para el CLI. Ojo: ese skill no es para ti, sino para los usuarios de tu proyecto, así que tiene que crearse dentro del proyecto y no en tu carpeta personal. Para que lo lean distintos agentes conviene tenerlo en .claude (para Claude Code) y en .agents, la carpeta estándar que leen otras herramientas. Con el skill, el agente ya tiene el contexto de los comandos sin tener que ejecutar nada.

El servidor MCP en Claude Desktop

Por último pedí un servidor MCP, que es otra aplicación más (como un backend aparte) que también habla con la API. Sus tools son el equivalente a los argumentos del CLI: listar, obtener, crear, actualizar y eliminar tareas.

Para usarlo en Claude Desktop fui a Configuración → Desarrollador → Editar configuración y abrí claude_desktop_config.json. En la sección mcpServers añadí algo de este estilo (en Windows usé mcp-remote como intermediario hacia el servidor):

{
  "mcpServers": {
    "tareas-app": {
      "command": "npx",
      "args": ["mcp-remote", "<URL de tu servidor MCP>"]
    }
  }
}

Tras reiniciar Claude, el conector tareas app aparece en la lista. Le pedí crear cinco tareas de demo: Claude pide permiso antes de ejecutar cada herramienta, y puedes darlo una vez o siempre. Después le pedí eliminar todas las tareas: como el MCP solo tiene una herramienta para borrar una tarea a la vez, fue eliminándolas una por una hasta dejar la lista vacía.

Igual que un backend, el servidor MCP también tiene que desplegarse para que lo usen otros.

MCP vs CLI: cuál elegir

Si tu proyecto ya está hecho, no tienes por qué elegir: puedes ofrecer ambos y que cada usuario use el que encaje con su entorno.

MCP CLI + skill
Instalación Solo conectarse Hay que instalar el comando
Herramientas Lista de tools definida Comandos descritos en el skill
Autenticación Login con OAuth y permisos por herramienta Una sesión para todo el sistema
Multiusuario Pensado para varios usuarios Lo usa quien está en esa máquina
Ideal para Chats web y apps de escritorio Terminal, editores y servidores

En resumen: si te conectas desde un chat web o un programa externo de forma remota, usa un MCP. Si tienes acceso al equipo y puedes instalar programas, un CLI te viene mejor, además de que consume menos tokens y es más rápido.

Lo que dicen los benchmarks

Esa última idea tiene datos detrás. Scalekit hizo 75 corridas con Claude Sonnet 4 en tareas de solo lectura sobre GitHub, comparando el CLI gh, el CLI con un skill y el servidor MCP oficial de GitHub (43 herramientas). Según su benchmark, el MCP gastó entre 4 y 32 veces más tokens según la tarea, sobre todo por cargar los esquemas de todas las herramientas en cada conversación, y completó 18 de 25 corridas (72 %) frente al 100 % del CLI; los fallos fueron timeouts de conexión con ese servidor. Es un solo benchmark y con un servidor concreto, pero va en la misma línea.

Y del lado del MCP, la especificación oficial define una autorización basada en OAuth 2.1 para servidores por HTTP (es opcional, pero es lo que permite el login y los permisos por usuario). Por eso la conclusión de Scalekit es parecida a la del video: CLI y skills para automatizar tu propio trabajo; MCP cuando un agente actúa en nombre de tus clientes.

Conclusión

Me quedo con tres ideas:

  • ✅ MCP para usuarios de chat: se conectan con un botón, sin instalar nada, con login y permisos por herramienta.
  • ✅ CLI + skills para desarrolladores: se instalan en su máquina, gastan menos tokens y funcionan con cualquier agente.
  • ✅ No tienes que elegir: si ya tienes una API, puedes ofrecer ambos y dejar que tu usuario decida.

Te recomiendo probarlo en tu próximo proyecto. ¿Tu app ya tiene MCP, CLI o los dos? Cuéntamelo en los comentarios del video en YouTube.

Fuentes