Cupón activo 
Cuándo un MCP sí vale la pena y cuándo no
El ecosistema de MCPs creció más rápido que la capacidad de la mayoría de los equipos para evaluarlos. Hay servidores MCP para todo: búsquedas web, bases de datos, APIs de terceros, sistemas de archivos, correo. La pregunta relevante no es si existe un MCP para lo que necesitas. Es si usarlo mejora el resultado o solo suma complejidad.
Qué es un MCP, en una línea
MCP (Model Context Protocol) es el protocolo abierto de Anthropic para conectar un modelo de lenguaje con fuentes externas de contexto y herramientas. Define cómo un cliente — Claude, un agente, una IDE — puede llamar a un servidor que expone recursos, prompts o herramientas de forma estándar.
En la práctica: es la capa que permite a un agente consultar una base de datos, ejecutar comandos en un sistema de archivos o llamar a una API sin que esa lógica viva dentro del prompt.
Cuándo sí tiene sentido
Un MCP gana cuando el agente necesita acceso a información que cambia en tiempo real o que no cabe razonablemente en el contexto. Algunos casos concretos donde la inversión se justifica:
Acceso a datos estructurados actualizados: bases de datos, APIs de inventario, calendarios. El agente consulta en lugar de recibir un dump estático en el prompt.
Herramientas con efectos secundarios controlados: ejecutar comandos de terminal, escribir archivos, publicar en sistemas externos. El MCP centraliza permisos y logs.
Reutilización entre agentes: si varios agentes distintos necesitan la misma capacidad, un servidor MCP compartido evita duplicar lógica.
Integración con sistemas que ya tienen una API: si la API existe y está bien documentada, el servidor MCP es relativamente barato de construir y el beneficio es inmediato.
Cuándo no vale la pena
La mayoría de los MCPs instalados en setups de desarrollo no cambian el resultado. Solo agregan latencia, una dependencia más para mantener, y un punto de falla adicional.
Si la información cabe en el prompt: un archivo de configuración, un schema de base de datos, una lista de endpoints — meter eso en contexto directamente es más simple y más rápido.
Si solo lo vas a usar una vez: construir y mantener un servidor MCP para un caso de uso puntual no escala. Un tool en el agente o un script externo son suficientes.
Si el MCP no está mantenido activamente: hay decenas de servidores MCP en GitHub con dos commits de hace seis meses. Depender de uno de esos para un flujo crítico es un riesgo que raramente se justifica.
Si lo instalas por completitud: tener el MCP de GitHub, el de Slack, el de Notion y el de tu base de datos activos sin un propósito concreto no tiene el mismo valor que usarlos con intención.
Cuando un MCP empeora a Codex, Claude Code y otros agentes
Aquí hay un detalle que casi no se menciona: cuando conectas demasiados MCPs a herramientas como Codex, Claude Code u otros agentes, parte de esa información termina viajando en el contexto de trabajo del modelo. Y eso no sale gratis.
Más herramientas disponibles no siempre significan más capacidad real. Muchas veces significan más descripciones de herramientas, más superficie de decisión, más contexto que evaluar en cada turno y, en consecuencia, más ruido. El resultado puede ser un agente más lento, más caro y menos preciso.
Por eso, si lo que necesitas ya existe como una CLI local clara y estable, muchas veces es mejor usar la herramienta de terminal directamente en lugar de envolverla detrás de un MCP. Una buena CLI reduce capas, evita sobrecargar el contexto innecesariamente y suele ser más fácil de depurar cuando algo falla.
La regla práctica aquí es simple: si el MCP no añade una capacidad nueva, sino solo otra forma de acceder a algo que ya puedes resolver bien con CLI, probablemente no vale la pena.
La prueba de los tres minutos
Antes de agregar un MCP a tu setup, responde estas preguntas:
¿Qué tarea concreta mejora con este servidor?
¿Puedo resolver esa tarea de otra forma en menos tiempo del que me cuesta configurar el MCP?
¿Quién mantiene este servidor y con qué frecuencia?
Si no tienes respuestas claras para las tres, probablemente puedes esperar.
El costo real de los MCPs mal elegidos
El tiempo de instalación es lo de menos. El costo está en la deuda de configuración — credenciales que rotan, versiones del protocolo que cambian, servidores que dejan de funcionar sin advertencia — y en la carga cognitiva de mantener un grafo de dependencias más amplio de lo necesario.
Un agente que funciona de forma confiable con tres herramientas bien elegidas es más útil que uno con veinte MCPs donde la mitad fallan silenciosamente.
Recomendación práctica
Empieza con el conjunto mínimo de herramientas que resuelven el problema. Agrega MCPs solo cuando tengas un caso de uso específico, medible y recurrente. Si después de una semana de uso real no puedes nombrar tres situaciones donde ese MCP mejoró el resultado, quítalo.
Tengo un curso donde creamos MCP Servers y puedes crearlos rápidamente con n8n, hay otras formas y dependen mucho de tus conocimientos, pero por ahora, puedes aprender con ese curso