¿Tu app LLM realmente necesita MCP? MCP vs CLI vs function calling
Cada vez aparece más la misma pregunta entre desarrolladores: mi función con LLM necesita consultar una base de datos o ejecutar un comando de despliegue, ¿debo crear un servidor MCP? A veces sí. Más a menudo, la respuesta honesta es: todavía no.
MCP, el Model Context Protocol, es valioso porque ofrece una forma estándar de conectar aplicaciones de IA con herramientas, recursos y prompts. Pero un estándar no debería convertirse en la primera abstracción para todos los casos.
Empieza por la superficie de integración
Function calling, CLI y MCP resuelven el mismo problema: el modelo necesita capacidades seguras y estructuradas. La diferencia está en dónde vive el contrato.
Con function calling nativo, el contrato vive dentro de tu aplicación. Defines esquemas, recibes solicitudes de herramientas, ejecutas código del servidor y devuelves resultados. Es directo, fácil de depurar y normalmente el camino más rápido a producción.
Con una capa CLI, el contrato es un comando ejecutable. Tests, type checks, migraciones, planes de infraestructura y búsquedas en repositorios ya tienen forma de comando. La arquitectura correcta no es abrir una shell libre, sino un broker estrecho con allowlist, timeouts, validación, límites de salida y logs.
Con MCP, el contrato se convierte en un protocolo entre cliente y servidor. Tiene sentido cuando la misma capacidad debe vivir más allá de un SDK, una app host o un equipo.
Cuándo basta function calling
Para la primera versión de una función de producto, function calling suele ser el mejor punto de partida. Autenticación, logging, rate limits, multi-tenancy e incident response permanecen dentro del límite de la aplicación que ya operas.
Si las herramientas son específicas del producto — buscar pedidos, preparar reembolsos o resumir historial de cuenta — MCP puede añadir complejidad sin mejorar la experiencia.
El problema llega cuando varios equipos implementan la misma herramienta en varios hosts. Ahí MCP empieza a ser atractivo.
Cuándo una CLI es mejor
Para agentes de programación e infraestructura, la CLI suele ser la interfaz más honesta. Es reproducible localmente, hereda convenciones del proyecto, produce logs humanos y falla con códigos de salida.
Si el flujo ya es nativo de comandos, envuélvelo primero. Devuelve resúmenes estructurados al modelo y conserva logs crudos para humanos.
Cuándo MCP merece la complejidad
MCP merece la pena cuando la misma capacidad debe estar disponible en varios entornos de IA: búsqueda en conocimiento interno, contexto de repositorios, sistemas de diseño, metadatos de bases de datos o logs de auditoría. Un equipo puede poseer el servidor y muchas apps consumirlo.
Consulta también nuestra guía de patrones MCP en producción y la estrategia para MCP en SaaS.
MCP no elimina el trabajo operativo: autenticación, autorización, secretos, rate limits, telemetría, versionado de esquemas y errores seguros siguen siendo tu responsabilidad.
La regla práctica
Un solo cliente y lógica de producto: function calling. Un flujo humano ya basado en comandos: broker CLI. Múltiples clientes de IA, ownership distribuido y herramientas estables: MCP.
La mejor arquitectura no es la más nueva. Es la que tiene menos fronteras y aun así ofrece seguridad, observabilidad y un camino limpio hacia la reutilización.