AIPaths Academy
•
1 de julio de 2026
•
8 min de lectura

¿MCP está muerto? La decisión práctica para construir agentes de IA en 2026

agentes-iamcpautomatizacionclaude-codeopenaiai-security
Table of Contents(9 sections)

On This Page

Durante los últimos meses empezó a aparecer una frase incómoda en el mundo de agentes de IA: "MCP is dead".

La provocación tiene sentido. Muchos equipos probaron Model Context Protocol para conectar agentes con herramientas externas y se encontraron con lo mismo: más procesos corriendo, más autenticación, más fallos de inicialización, más permisos difíciles de auditar y, en algunos casos, más tokens gastados en describir herramientas que el agente ni siquiera iba a usar.

Pero convertir esa frustración en "MCP murió" es demasiado simple. Lo que probablemente murió es otra cosa: la idea de que toda integración de un agente debe empezar por MCP.

Para un emprendedor, founder técnico o equipo pequeño, esta distinción importa. No necesitas ganar una guerra de protocolos. Necesitas construir automatizaciones que funcionen, que sean mantenibles y que no se vuelvan frágiles cuando cambie la herramienta de moda.

Qué es MCP y por qué se volvió tan importante

MCP, o Model Context Protocol, es un estándar abierto para conectar aplicaciones de IA con sistemas externos: bases de datos, archivos, SaaS, herramientas internas, APIs y workflows. La promesa es atractiva: en vez de crear integraciones distintas para cada modelo o cliente, expones capacidades a través de un protocolo común.

Anthropic lo presentó en noviembre de 2024 como una forma de reemplazar integraciones fragmentadas por un estándar abierto. La documentación oficial lo compara con un puerto USB-C para aplicaciones de IA: una forma común de conectar modelos con datos, herramientas y contexto.

Ese framing explica el hype. Si los agentes van a trabajar con GitHub, Slack, Notion, Postgres, Google Drive, Figma, CRMs y herramientas internas, un estándar común suena inevitable.

Y la adopción real tampoco apunta a un protocolo muerto. Claude Code lo soporta. OpenAI permite usar conectores y servidores MCP remotos en la Responses API. Microsoft Copilot Studio permite extender agentes con herramientas y recursos publicados por servidores MCP. El proyecto MCP tiene especificación, SDKs, registry en preview y una conversación activa sobre servidores remotos.

Entonces, si MCP sigue apareciendo en los stacks grandes, ¿por qué hay tantos developers diciendo que está muriendo?

Porque una cosa es que MCP tenga soporte de plataforma. Otra muy distinta es que sea la mejor decisión para cada integración.

Lo que la crítica a MCP acierta

El artículo de Quandri y el post original de Eric Holmes no son solo quejas de internet. Capturan dolores reales de equipos que intentaron usar MCP en trabajo diario.

El primer dolor fue el contexto. Quandri midió que las definiciones de herramientas de sus servidores MCP ocupaban más de 20.000 tokens cuando cargaban cuatro servidores. Eso era un coste fuerte: antes de hacer trabajo útil, el modelo ya estaba cargando menús enteros de herramientas.

Ese punto ya cambió parcialmente. La documentación actual de Claude Code explica que Tool Search difiere las definiciones de herramientas y solo carga lo necesario cuando Claude lo necesita. Es decir: el argumento de "MCP come contexto" era válido en muchas configuraciones, pero no debe repetirse como si el ecosistema no hubiera reaccionado.

El segundo dolor sigue más vivo: la fiabilidad operacional. Un servidor MCP local es otro proceso. Tiene que iniciar, autenticarse, mantenerse vivo, manejar permisos y devolver resultados en un formato que el agente entienda. Cuando falla, no siempre puedes reproducirlo tan fácil como ejecutar un comando en terminal.

El tercer dolor es el solapamiento. Muchas tareas que hoy se están envolviendo en MCP ya tienen una interfaz mejor: CLI, API o workflow no-code. Si quiero consultar un issue de GitHub, el CLI de GitHub ya existe. Si quiero leer una base de datos, SQL ya existe. Si quiero disparar una automatización estable de negocio, n8n o una API directa pueden ser más predecibles.

Y hay un cuarto punto que no conviene suavizar: seguridad. La NSA publicó en mayo de 2026 una guía específica sobre MCP y advierte que, aunque MCP simplifica integraciones de agentes, su postura de seguridad todavía depende mucho de la disciplina de implementación. Entre los riesgos: invocación dinámica de herramientas, relaciones de confianza implícitas, contexto compartido, access control incompleto, logs insuficientes y servidores desplegados sin suficiente gobierno.

Para un negocio pequeño, esto se traduce en algo concreto: si conectas un agente a muchas herramientas con permisos amplios, MCP no te salva mágicamente. Puede darte una interfaz estándar, pero sigues necesitando límites, logs, permisos mínimos y aprobación humana para acciones sensibles.

Lo que la crítica exagera

Decir que MCP está muerto confunde dos niveles.

A nivel protocolo, MCP está más vivo que hace un año. Hay soporte de grandes plataformas, transportes remotos, registry, conectores y documentación activa. OpenAI incluso recomienda conectar servidores oficiales del proveedor cuando sea posible, y advierte tener cuidado con agregadores o servidores de terceros. Microsoft lo está incorporando en Copilot Studio como forma de añadir herramientas y recursos a agentes empresariales.

A nivel diseño de sistemas, la crítica sí pega: MCP no debería ser el default automático.

La pregunta correcta no es "¿MCP sí o no?". La pregunta correcta es: "¿Esta tarea necesita un servidor MCP o existe una interfaz más simple, auditable y estable?".

Un protocolo puede estar vivo y aun así ser una mala decisión para tu caso.

El framework práctico: MCP, CLI, API, n8n o skills

Si estás construyendo agentes o automatizaciones para tu negocio, usa esta regla base: elige la interfaz que reduzca fricción total, no la que suene más agentic.

Usa API directa cuando el flujo es estable y crítico

Si el workflow es repetible, vive en producción y tiene reglas claras, una API directa suele ser mejor que MCP.

Ejemplos: crear leads en un CRM, consultar inventario, enviar eventos a un backend, generar facturas, registrar pagos, sincronizar usuarios o actualizar estados internos.

¿Por qué? Porque puedes controlar errores, retries, validaciones, logs, idempotencia y permisos desde código. El agente no necesita improvisar una tool call; tu sistema ya sabe qué acción está permitida.

Para negocio, esta suele ser la opción más robusta.

Usa n8n cuando el proceso es operativo y necesita visibilidad

Para equipos pequeños, n8n encaja muy bien cuando el flujo combina herramientas de negocio: Gmail, Airtable, WhatsApp, HubSpot, Slack, formularios, webhooks y pasos humanos.

Ahí MCP puede ser excesivo. Si el proceso es "cuando llegue este formulario, clasifica el lead, crea una tarea y avisa por WhatsApp", n8n te da algo valioso: un diagrama visible, nodos determinísticos, retries y puntos de control.

El LLM puede participar en una parte del flujo, pero no tiene que controlar todo el sistema.

Usa CLI cuando el trabajo es técnico y debe ser depurable

Para tareas de desarrollo, infraestructura y debugging, la CLI tiene una ventaja enorme: humanos y agentes usan la misma interfaz.

Si el agente ejecuta gh, psql, git, docker, npm, kubectl o terraform, tú puedes reproducir lo que hizo. Puedes copiar el comando, mirar el output, ajustar flags y revisar logs.

Esta es la tesis fuerte del post de Eric Holmes: las mejores herramientas son útiles para humanos y máquinas. En desarrollo, esa idea pesa mucho. Si ya existe un CLI bueno y autenticado, envolverlo en MCP puede añadir una capa sin aportar suficiente valor.

Usa skills cuando el problema es enseñar contexto repetible

Muchas veces no necesitas una herramienta nueva. Necesitas que el agente recuerde cómo trabajar en tu sistema.

Ahí entran las skills o instrucciones versionadas: procedimientos, checklists, comandos comunes, criterios de revisión, convenciones del repo y pasos de despliegue. Claude Code documenta que una skill carga su cuerpo solo cuando se usa, lo cual la vuelve útil para procesos repetibles sin pagar contexto todo el tiempo.

Ejemplos: "cómo revisar un PR en este repo", "cómo validar un contenido antes de publicar", "cómo correr este stack local", "cómo auditar una automatización de n8n".

Esto no reemplaza una API ni un servidor MCP. Reemplaza el hábito de pegar las mismas instrucciones cada semana.

Usa MCP cuando necesitas una capa estándar de herramientas compartidas

MCP sí tiene casos fuertes.

Úsalo cuando el servicio no tiene buen CLI, cuando quieres exponer la misma integración a varios clientes de IA, cuando necesitas recursos y herramientas dinámicas, cuando el proveedor oficial mantiene un servidor remoto, o cuando un equipo necesita gestión centralizada de conectores.

También puede tener sentido para usuarios no técnicos. Un equipo de operaciones no va a ejecutar curl, jq o gh en terminal. Un conector MCP dentro de Claude, ChatGPT o Copilot puede darles acceso a capacidades sin exponerles una CLI.

El punto es que MCP debe ganarse su lugar. No por moda. Por reducción real de coste operativo.

La matriz de decisión rápida

Antes de invertir semanas en una integración MCP, responde esto:

  • ¿Ya existe una API estable para esta acción?
  • ¿Ya existe un CLI oficial que el agente puede usar y que un humano puede depurar?
  • ¿El flujo necesita una interfaz visual y pasos humanos? Si sí, mira n8n.
  • ¿El problema es más de instrucciones repetibles que de herramientas? Si sí, crea una skill.
  • ¿El servidor MCP es oficial del proveedor o un proxy de terceros?
  • ¿Qué permisos reales tendrá el agente?
  • ¿Qué datos salen hacia el servidor MCP?
  • ¿Hay logs por tool call?
  • ¿Puedes exigir aprobación para acciones sensibles?
  • ¿Qué pasa si el servidor cambia herramientas, outputs o scopes sin avisar?

Si no puedes contestar esas preguntas, todavía no tienes una arquitectura. Tienes hype con credenciales.

Qué debería hacer un emprendedor ahora

Mi recomendación para AIPaths es simple: no apuestes tu operación a un protocolo. Diseña tus agentes por capas.

Para automatizaciones estables de negocio, usa APIs y n8n. Para trabajo técnico, favorece CLI y repos con instrucciones claras. Para conocimiento operativo repetible, crea skills. Para conectores compartidos, herramientas sin CLI, recursos dinámicos o integraciones oficiales, evalúa MCP.

Esta combinación evita dos errores comunes.

El primer error es rechazar MCP por completo porque algunos developers tuvieron malas experiencias. Eso te puede dejar fuera de un estándar que probablemente seguirá creciendo en herramientas enterprise.

El segundo error es usar MCP en todo porque suena moderno. Eso puede darte agentes más lentos, más opacos y más difíciles de auditar.

La ventaja está en elegir con criterio.

Conclusión

MCP no está muerto. Lo que está muriendo es el MCP como reflejo automático.

La nueva etapa de agentes no va a premiar a quien conecte más herramientas. Va a premiar a quien construya sistemas que sepan cuándo usar una API, cuándo usar n8n, cuándo usar CLI, cuándo cargar una skill y cuándo MCP realmente aporta una capa estándar útil.

Para founders y equipos pequeños, esa es la decisión práctica: no construyas alrededor del protocolo. Construye alrededor del resultado, la mantenibilidad y el control.

Si MCP reduce fricción real, úsalo. Si añade una capa que nadie puede depurar, no lo uses. Y si la única razón para elegirlo es que aparece en el landing page de todas las herramientas, probablemente ya tienes tu respuesta.

Contenido relacionado

Fuentes consultadas

Was this helpful?
Share this content
0comments