¿MCP nació muerto? El debate arde en internet tras las declaraciones del CTO de Perplexity, Denis Yarats, quien dijo que la empresaestaba abandonando MCP en favor de APIs y CLIsGarry Tan, presidente de Y Combinator, se sumó a la postura enun tweet recienteAhora los desarrolladores están tomando partido: ¿MCP es excesivo o es indispensable para construir agentes de AI en equipos enterprise?

Las críticas tienen mérito; algo está roto hoy. El overhead de contexto y la fricción en auth son problemas reales para los devs, pero la causa raíz está en el tooling y la implementación. Los detractores de MCP dirán lo contrario, pero muchos evalúan este estándar por la calidad de los servidores open source que existen hoy, servidores que todavía no han alcanzado el estado actual de MCP.

Si analizas la adopción del protocolo, la calidad de sus contribuidores y el momentum del ecosistema, los datos cuentan otra historia: MCP ya ganó.

El problema correcto, el blanco equivocado

La frustración que sienten los devs es real: definiciones de herramientas vagas, esquemas faltantes, manejo de errores roto. La mayoría de los servidores MCP son envoltorios delgados de API que vuelcan respuestas crudas al contexto sin importar lo que el agente necesita… todo eso genera experiencias genuinamente malas. Pero son síntomas de implementaciones específicas, no del protocolo.

Parte del problema es que las críticas más ruidosas apuntan a versiones de MCP que ya no existen. El protocolo ha evolucionado bastante, y en un espacio que se mueve tan rápido, la especificación del año pasado ya es obsoleta. El blanco se movió.

Juzgar MCP por malas experiencias con servidores open source es como juzgar el USB-C por el cable genérico más barato de Amazon. El protocolo fija el estándar; el ecosistema decide qué tan bien se cumple. El ecosistema siempre va detrás del protocolo: es lo normal en cualquier curva de adopción de estándares.

Sí, MCP es más pesado de lo necesario en algunos puntos, y hay cosas que maneja bien mientras que otras las resuelve con menos elegancia. La calidad de los servidores open source es muy variable y muchos clientes MCP siguen al día. Pero son problemas de ingeniería que se pueden resolver. Si el tooling mejora, el overhead desaparece.

Lo que muestran los datos

Anthropic donó MCP a la Agentic AI Foundation(bajo la Linux Foundation), una señal deliberada de lo que MCP es y no es. El protocolo fue diseñado como un estándar neutral, no como una apuesta propietaria, y está abierto para toda la comunidad de desarrollo. Plataformas importantes comoFigma y Linearya están lanzando servidores MCP propios de alta calidad. Estas empresas facilitan que los agentes de AI trabajen con sus plataformas: sin permisos especiales ni aros propietarios por los que saltar. Stripe fue un paso más allá. El mes pasado presentó elMachines Payments Protocol, un nuevo estándar abierto que permite a los agentes de AI transaccionar de forma autónoma. MCP es solo uno de los muchos endpoints con los que puede trabajar el protocolo de Stripe, y la forma en que estos nuevos estándares open source coexisten nos muestra hacia dónde va la industria.

Hablo con decenas de empresas enterprise cada mes, y las conversaciones recientes reflejan la misma apuesta por MCP. En un evento reciente para CIOs, no encontré a nadie alejándose de MCP. Nadie debate si necesitan un estándar de conectividad. El debate ya superó la selección del protocolo. Lo que los equipos de seguridad y plataforma enterprise están resolviendo ahora es la operacionalización: cómo aplicar scoping de mínimo privilegio en cientos de conexiones agente-a-sistema, cómo mantener audit trails que satisfagan a sus equipos de compliance, y cómo hacerlo sin reconstruir la infraestructura de auth desde cero para cada nueva herramienta. La pregunta del protocolo está resuelta. La pregunta de implementación está completamente abierta. Esa brecha es exactamente la razón por la que construimos Arcade.dev.

No todos ven eso como una oportunidad. Los que se resisten a MCP también ayudan a contar la historia. Empresas como Slack (Salesforce), plataformas de talento como Workday y LinkedIn, y gigantes sociales como Meta y Discord están dificultando (a veces deliberadamente) que los agentes de AI trabajen con sus plataformas. Recientemente hablé con Laura Bratton en The Information sobrepor qué estas empresas se resisten a los agentes de AI de sus clientes. Dicen que el bloqueo a los agentes es para proteger la seguridad y la privacidad, pero el elefante en la sala es que los agentes abiertos podrían dañar la capacidad de las empresas SaaS para mantener a los usuarios cautivos y pagando por sus funciones y productos propietarios.

Pero la resistencia de los incumbentes no es evidencia de debilidad del protocolo. Es evidencia de su poder. Es difícil imaginar que los grandes darlings del SaaS reaccionarían así ante un protocolo que está perdiendo. Los estándares no ganan por perfección técnica inmediata. TCP/IP no era perfecto, ni tampoco HTTP. Ganaron porque cruzaron el umbral donde los costos de cambio superaron los beneficios de cualquier alternativa. A nivel de protocolo, así es como MCP está tomando la delantera. Otros estándares, como el A2A de Google, han tenido dificultades para ganar tracción mientras la especificación de MCP se ha expandido para cubrir gran parte del mismo terreno. Hasta hoy, ningún competidor creíble ha surgido con uso real, contribuidores de peso y momentum de ecosistema comparable al de MCP.

El protocolo no es la implementación

El debate sobre si MCP es el estándar correcto pierde el bosque por los árboles. La fricción central que impulsa la conversación es que la mayoría de las implementaciones de MCP simplemente no son buenas (todavía).

El nuevo benchmark de MCP de Arcade.dev, ToolBench, lo deja claro. Evalúa servidores MCP en definición, preparación para el protocolo y soporte en el mundo real, yla varianza que ToolBench revela es enorme. Muchos servidores open source no corren sobre el estado actual del protocolo. Suma este rezago al pobre soporte MCP open source de herramientas enterprise populares, y puedes ver por qué los críticos de MCP se vuelven más ruidosos. Sin embargo, su queja real es contra los builders que aún no han implementado MCP bien.

Una confusión similar aparece en cómo la gente habla de estándares competidores. Agent Skills y MCP resuelven problemas distintos y funcionan mejor juntos que separados. MCP es cómo un agente se conecta a Gmail; las skills son la capa de conocimiento que le dice al agente cómo redactar ese correo una vez que está ahí. Son ortogonales y se complementan bien, por eso mezclarlos lleva exactamente al tipo de decisiones arquitectónicas equivocadas que hacen que las malas implementaciones de MCP rindan por debajo de lo esperado.

Poniendo el estándar

Seguirán surgiendo nuevos estándares, pero resolverán problemas distintos. Incluso los llamados al CLI, impulsados por Perplexity y Garry Tan, tienen sentido. Los devs quieren escribir un comando, pero ese comando igual tiene que llegar a Salesforce, GitHub o un sistema de salud, donde algo tiene que gestionar auth, scoping de permisos y registrar la acción.

De hecho, nuestro Director de Ingeniería, Evan Tahler, se cansó exactamente de ese tipo de problema y construyóMCPX, curl para MCP. Con MCPX, el desarrollador escribe un comando y la infraestructura se encarga del resto. Herramientas como esta demuestran que los agentes de larga duración con llamadas a herramientas que acceden y actúan en sistemas de negocio hoy corren sobre MCP. Ningún otro estándar puede hacer esto ahora mismo.

Si quieres ver cómo se ve MCP listo para producción en la práctica, para eso construimos Arcade.dev.Empieza a construir aquí.