La mayoría de servidores MCP —el protocolo estándar para conectar agentes de IA con productos externos— no aportan valor real y responden a una moda más que a una necesidad de arquitectura. Es la tesis central de un análisis publicado por Evil Martians, consultora conocida por su trabajo con herramientas para desarrolladores, que propone un marco práctico para decidir si conviene construir uno.
El punto de partida es demoledor: un estudio de Bloomberry sobre 1.412 servidores MCP concluye que aproximadamente la mitad de las empresas que lo lanzaron ni siquiera tenían una API pública. Esto significa que esas organizaciones aún no habían definido operaciones estables a nivel de intención para consumidores externos, así que su servidor MCP carecía de base.
El artículo distingue cuatro interfaces que un producto puede ofrecer: la API (contrato de software), la CLI (contrato de ejecución), el servidor MCP (contrato de acceso para agentes) y las skills (instrucciones que enseñan al agente a usar las anteriores con disciplina). Antes de plantearse un MCP, los autores recomiendan asegurar que la API y la CLI están bien diseñadas —con operaciones centradas en lo que el usuario quiere hacer, no en cómo se almacenan los datos— y probar primero con una skill, que es más barata y permite validar demanda real.
La señal clara que justifica construir un MCP es que clientes de IA que la empresa no controla —Claude, Cursor, ChatGPT, Copilot o agentes a medida— necesiten consumir las mismas operaciones del producto. Empresas como Linear, Sentry, Resend, Cloudflare y Stripe han lanzado servidores MCP oficiales precisamente por eso. Sin esa demanda cruzada entre clientes, las llamadas a funciones nativas bastan y el MCP solo añade protocolo innecesario.
Finalmente, el texto detalla qué belongs en el servidor —composición determinista, validaciones, previsualizaciones, comprobaciones de permisos— y qué no: selección autónoma de objetivos, decisiones de negocio irreversibles o planificación oculta sin vista previa inspeccionable. La regla resumida: encapsular operaciones, no flujos de trabajo.
