MCP o CLI: la interfaz se elige según quién controla el flujo
Exponer una herramienta como CLI o como servidor MCP depende de quién decide el siguiente paso y de dónde viven los datos, no de si quien llama es una persona o un agente.
¿CLI o servidor MCP? La respuesta cómoda —MCP para la IA, CLI para las personas— se cae en cuanto se mira de cerca: un agente puede ejecutar comandos en un terminal, y cualquiera puede pedirle a un cliente MCP que invoque una herramienta. Lo que decide es quién elige el siguiente paso y dónde viven los datos.
Quién llama y desde dónde
Un CLI encaja cuando quien llama ya tiene una secuencia repetible: construir, probar, publicar e inspeccionar el resultado. Un script de shell o un job de CI le pasan una ruta, leen el código de salida para detectar el fallo y parsean el JSON cuando necesitan una URL o un identificador. De propina, se depura en local sin montar nada más.
Un servidor MCP encaja cuando un asistente tiene que descubrir una operación y llamarla en mitad de una conversación. La herramienta declara que acepta contenido y nombre de fichero, y devuelve un resultado estructurado que el modelo usa en el paso siguiente. MCP da una forma estándar de listar e invocar herramientas; no vuelve segura ni correcta la publicación por sí sola.
El detalle que más se pasa por alto es el transporte. Con un servidor MCP local sobre stdio, una herramienta que recibe ./dist lee ese directorio del equipo. Con un servidor remoto sobre HTTP, el mismo ./dist apunta al servidor, no al portátil de quien escribe: la cadena es idéntica y las consecuencias no. Para el caso remoto toca enviar el contenido de forma explícita o subirlo por una API que devuelva un manejador de fichero. La documentación de transportes de MCP describe stdio y Streamable HTTP, y la frontera del sistema de ficheros se deduce de dónde corre cada proceso.
Fallar también se diseña
Un CLI útil necesita códigos de salida estables, salida fácil de parsear y una vía para las credenciales que no exija un prompt interactivo. Los mensajes de progreso para humanos van por un lado y la salida legible por máquina por otro. Una herramienta MCP útil necesita un esquema de entrada preciso y un resultado que diga al cliente qué salió bien y qué no. Y ojo con stdio: stdout es el canal del protocolo, así que los logs van a otra parte.
Las dos interfaces pueden apoyarse en la misma función de publicación. El CLI se ocupa de los flags, la salida de terminal y los códigos de retorno; el adaptador MCP, de las definiciones y los resultados estructurados. Autenticación, reglas de subida, límites de tamaño y comportamiento de actualización deberían salir de esa operación compartida para que las dos puertas no acaben diciendo cosas distintas. En cualquiera de los casos conviene dejar claro el destino, revisar qué ficheros salen de la máquina, no colar secretos en el paquete y no devolver como URL pública un enlace privado de edición.
El criterio que propone el autor —que avisa de que el borrador lo redactó un asistente— es sencillo: CLI para una secuencia conocida, MCP cuando un cliente capaz de manejar herramientas escoge acciones, interfaz local cuando hay rutas locales. La segunda entrada se añade cuando aparece un consumidor real que la pide.
