MCP, WebMCP y A2A: qué protocolo elegir para tus agentes IA en 2026

Por el equipo de Kiwop · Agencia Digital especializada en Desarrollo de Software e Inteligencia Artificial aplicada · Publicado el 19 de abril de 2026 · Última actualización: 19 de abril de 2026

TL;DR — A abril de 2026 conviven tres protocolos clave para agentes IA. MCP (Model Context Protocol) conecta un agente con sus herramientas y datos; es el estándar de facto, donado a la Linux Foundation. WebMCP es la variante navegador para que los sitios expongan acciones a agentes; sigue emergente. A2A (Agent-to-Agent) conecta agentes entre sí; v1.0 en producción con 150+ organizaciones. Usa MCP para tools, A2A para orquestar y WebMCP para tu web.

Cada semana recibimos la misma pregunta desde comités de dirección y equipos de producto: "Estamos construyendo un agente IA, ¿qué protocolo usamos?". La respuesta correcta ya no es "MCP y punto" — lo era en 2025, pero 2026 ha traído una constelación de estándares que se complementan más de lo que compiten. Lo interesante no es cuál gana: es cuál resuelve cada problema.

Este artículo es la comparativa técnica que nos habría ahorrado semanas de investigación hace seis meses. Está basada en nuestra experiencia real construyendo asistentes personales con Claude Code y MCP, en el trabajo interno sobre Nexo (nuestro SaaS de workspace en desarrollo), y en las fuentes oficiales más recientes publicadas por Anthropic, Google, Cloudflare, Vercel, la Linux Foundation y el propio W3C. Si buscas una respuesta binaria, no la tendrás aquí. Si buscas criterio de decisión, sigue leyendo.

Por qué 2026 es el año de los protocolos agentes IA

2023 fue el año del prompt. 2024 fue el año de la herramienta (tool use). 2025 fue el año del agente. Y 2026 está siendo, sin duda, el año de los protocolos. La razón es simple: cuando hay un solo agente hablando con una sola API, cualquier contrato ad hoc funciona. Cuando tienes decenas de agentes, docenas de modelos de distintos proveedores, cientos de herramientas internas y externas, y clientes que quieren conectar sus propios agentes a los tuyos, el caos se come el producto.

La explosión ha sido brutal. Anthropic reporta más de 10.000 servidores MCP públicos activos y 97 millones de descargas mensuales de SDK entre Python y TypeScript según la nota oficial de donación de MCP a la Linux Foundation. A2A, por su parte, pasó de una propuesta de Google en abril de 2025 a contar con más de 150 organizaciones y estar bajo el paraguas de la Linux Foundation a principios de 2026. El 9 de diciembre de 2025 se formalizó la Agentic AI Foundation (AAIF) bajo la Linux Foundation, con Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare y Bloomberg como miembros platino — un movimiento cubierto por TechCrunch que marca el fin de la era de protocolos propietarios.

La foto a abril de 2026 es la siguiente. Hay tres protocolos que cualquier equipo técnico necesita entender: MCP, WebMCP y A2A. Hay un cuarto, ACP (Agent Communication Protocol) de IBM, que conceptualmente se solapa con A2A y cuya adopción a día de hoy es considerablemente menor. Y hay una pléyade de iniciativas adyacentes — AGENTS.md, Open Responses, ANP, LLMFeed — que orbitan sin todavía alcanzar la misma masa crítica. Nos centraremos en los tres que importan para decisiones de arquitectura reales.

La fragmentación es un problema real. Como se apunta en la encuesta académica de arXiv sobre protocolos de interoperabilidad de agentes, cada protocolo resuelve una capa distinta del stack: el problema no es elegir uno, es entender en qué capa opera cada cual y combinarlos sin crear acoplamientos innecesarios. Esa es la tesis que vamos a desarrollar.

MCP — Model Context Protocol (Anthropic, 2024)

MCP es, a abril de 2026, el estándar de facto para conectar un agente IA con herramientas externas. Fue publicado por Anthropic en noviembre de 2024 como protocolo abierto, y en su primer año recorrió el camino que otros estándares han tardado una década en recorrer: de propuesta individual a infraestructura compartida de la industria.

Qué es MCP conceptualmente

MCP define un contrato entre dos partes: un cliente MCP (generalmente el agente o el host del modelo) y un servidor MCP (generalmente un adaptador hacia un servicio externo: Gmail, GitHub, una base de datos, un sistema interno). El cliente descubre qué herramientas ofrece el servidor, lee su esquema, y las invoca con parámetros tipados. La comunicación usa JSON-RPC 2.0 sobre un transporte.

El protocolo no solo cubre herramientas (tools): define también resources (contenido leíble estáticamente, como archivos o registros), prompts (plantillas reusables) y — desde la especificación del 25 de noviembre de 2025 — operaciones asíncronas, stateless servers, server identity y extensiones oficiales según la especificación oficial. Esta evolución es la que permitió a MCP pasar de "conectar un cliente local" a "alimentar infraestructura de agentes en producción".

Transportes: stdio y Streamable HTTP

MCP soporta dos transportes oficiales según la documentación de transportes del spec:

• stdio: el cliente arranca el servidor como un subproceso local y se comunica por entrada/salida estándar. Ideal para ejecuciones locales, CLI y asistentes personales.
• Streamable HTTP: el servidor vive como proceso independiente y expone un único endpoint HTTP que acepta POST y GET. Puede usar Server-Sent Events para streaming. Es el estándar de facto para servidores remotos en 2026, y reemplaza al antiguo transporte HTTP+SSE.

La regla rápida: stdio para asistentes personales en una máquina, Streamable HTTP para servicios compartidos en producción.

Servidores disponibles y ecosistema

A abril de 2026, el ecosistema MCP cubre prácticamente cualquier servicio empresarial relevante: Gmail, Google Calendar, Google Drive, Slack, Linear, GitHub, Notion, Jira, Confluence, Salesforce, HubSpot, Stripe, PostgreSQL, Snowflake, BigQuery y decenas más. La adopción cruza fronteras de proveedor: OpenAI lo soportó nativamente en ChatGPT en marzo de 2025, Microsoft lo integró en Copilot, Google lo soporta en Gemini, y editores como Cursor, Windsurf y VS Code hablan MCP de forma nativa.

Casos de uso óptimos

MCP brilla cuando hay un agente que necesita acceso a muchas fuentes heterogéneas: un asistente personal que lee tu correo y tu calendario, un copiloto de desarrollo que consulta tu código y tus tickets, un agente de ventas que cruza datos de CRM y facturación. En todos esos casos, el patrón es el mismo: el agente invoca herramientas tipadas en servidores que hablan con sistemas concretos.

Limitaciones

MCP no es la herramienta correcta cuando el tráfico es agente↔agente (ahí entra A2A), cuando el consumidor es un navegador y no un proceso con credenciales OAuth preinstaladas (ahí entra WebMCP), ni cuando la operación requiere streams binarios masivos o latencias submilisegundo (ahí entran APIs específicas). Y aunque la adopción es enorme, la seguridad sigue siendo un área de trabajo activa: hay literatura creciente sobre tool poisoning, prompt injection a través de descripciones de herramientas, y permisos difíciles de auditar. Cualquier agente MCP en producción necesita una capa de sandboxing y confirmación que el protocolo no impone por sí mismo.

WebMCP — el MCP para la web (2025-2026)

WebMCP es la apuesta de Google y Microsoft para trasladar la filosofía MCP al navegador y a la propia web. No es una extensión de MCP: es un estándar paralelo, coordinado dentro del W3C Web Machine Learning Community Group, que adapta el contrato cliente-servidor al entorno específico del navegador. Ya cubrimos la propuesta inicial en WebMCP: tu web preparada para agentes IA; aquí nos centramos en cómo se posiciona frente a MCP y A2A.

Por qué WebMCP y no simplemente MCP sobre HTTP

A priori suena redundante: si MCP ya tiene transporte Streamable HTTP, ¿para qué otro estándar? El ecosistema WebMCP está en early-preview a abril de 2026, pero la razón de existir va más allá de la inmadurez. La respuesta técnica es que el navegador es un entorno radicalmente distinto a un servidor. En el navegador:

• La autenticación la gestiona el usuario, no el agente (la cookie de sesión vive en el navegador, no viaja con el agente).
• Las acciones tienen que ser visibles y supervisables por el humano (no hay espacio para automatizaciones opacas).
• La superficie expuesta es la del sitio web visitado, no un endpoint dedicado.
• La descubribilidad ocurre cuando el usuario navega a la página, no a través de un registro global.

WebMCP resuelve exactamente esas diferencias. Según la documentación oficial de Cloudflare Browser Run sobre WebMCP, el sitio web expone un conjunto de tools — por ejemplo searchFlights() o bookTicket() — con parámetros tipados. Un agente que navega la página puede descubrir esas tools, leer sus esquemas y llamarlas directamente sin simular clicks ni hacer scraping del DOM.

Implementación: Cloudflare y Vercel

Los dos proveedores que más rápido han movido ficha son Cloudflare y Vercel, aunque con aproximaciones distintas.

• Cloudflare añadió soporte WebMCP a su producto Browser Run (antes Browser Rendering) el 15 de abril de 2026, según su changelog oficial. La integración permite que un agente IA conecte su cliente MCP contra Browser Run vía el endpoint CDP y descubra tools expuestas por cualquier sitio que implemente WebMCP — incluso cuando ese sitio no controla la infraestructura.
• Vercel ha orientado su producto al despliegue de servidores MCP sobre su plataforma Functions, aprovechando Fluid Compute para optimizar patrones de uso irregulares típicos de agentes. La documentación oficial de Vercel MCP describe cómo montar endpoints Streamable HTTP con OAuth built-in, y su AI SDK incluye cliente MCP experimental. Aunque Vercel es más MCP clásico que WebMCP puro, es el proveedor de referencia cuando tu backend ya vive en Next.js.

Casos de uso óptimos

WebMCP es la respuesta correcta cuando tu producto es un sitio web público y quieres que los agentes IA lo usen bien: e-commerce (búsqueda, filtros, carrito, checkout), SaaS con formularios complejos (configuradores, presupuestos), marketplaces, sistemas de reservas. Todo caso en que un usuario humano usaría botones y formularios y quieres que un agente haga lo mismo con menos fricción.

Estado de adopción a abril de 2026

Aquí hay que ser honestos: WebMCP es emergente, no maduro. Chrome lo soporta de forma experimental en Canary, Cloudflare tiene producción parcial, y la cobertura de AB Magency sobre la "guerra de formatos agentic" recoge que WebMCP compite simultáneamente con propuestas como Markdown for Agents de Cloudflare (lanzada el 12 de febrero de 2026). Ambas coexisten; ninguna ha ganado. Para un equipo que necesite decidir hoy, WebMCP es una apuesta de futuro razonable para sitios con tráfico agente previsible, pero no es un estándar sobre el que apostar toda la arquitectura.

A2A — Agent-to-Agent protocol (2026)

Si MCP conecta un agente con sus herramientas, A2A conecta agentes entre sí y, a abril de 2026, es el estándar horizontal de referencia. Es la diferencia entre "un trabajador usa sus herramientas" y "un trabajador delega tarea a otro trabajador". No es una distinción académica: resuelve problemas reales que MCP no puede resolver.

Origen y estado actual

A2A fue anunciado por Google en Google Cloud Next 2025 el 9 de abril de 2025, con más de 50 socios de lanzamiento (Accenture, Atlassian, Box, Cohere, Deloitte, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UiPath, entre otros). En junio de 2025 Google lo donó a la Linux Foundation. En marzo de 2026 se publicó A2A v1.0, la versión que la comunidad considera apta para producción. La documentación oficial en a2a-protocol.org describe el modelo en detalle; el anuncio de upgrade del Google Cloud Blog documenta las mejoras de v1.0.

Arquitectura: Agent Cards y descubrimiento

El concepto central de A2A es la Agent Card: un documento JSON que describe qué sabe hacer un agente, qué skills expone, qué autenticación requiere y dónde contactarlo. Los agentes se descubren leyendo las Agent Cards de otros agentes, igual que los servicios web se descubren por OpenAPI. En v1.0 las Agent Cards llevan firma criptográfica (Signed Agent Cards), lo que permite verificar que una card fue emitida por el dominio propietario del agente — una mejora importante contra impersonación.

El transporte es JSON-RPC 2.0 sobre HTTP, Server-Sent Events, o gRPC, con autenticación vía API keys, HTTP auth, OAuth 2.0/OIDC y mutual TLS. Es decir: las mismas piezas que cualquier backend empresarial usa desde hace una década, sin reinventar nada.

Casos de uso óptimos

A2A es la respuesta correcta cuando hay varios agentes especializados que necesitan colaborar: un agente orquestador que delega "buscar un vuelo" a un agente de viajes, "reservar un hotel" a un agente de hoteles, y "pagar" a un agente de pagos. Cada agente especializado tiene sus propias herramientas (MCP internamente) y ofrece su Agent Card al exterior para ser orquestado. Escenarios típicos: purchasing concierges multi-proveedor, workflows multi-departamento en grandes empresas, marketplaces de agentes.

Diferencia fundamental con MCP

La clave, bien resumida por IBM en su artículo sobre A2A, es que MCP es vertical (agente↔tool) y A2A es horizontal (agente↔agente). Ambos son complementarios. Un agente A2A puede internamente usar MCP para acceder a sus datos. Un agente MCP puede no necesitar A2A nunca si es un solo agente. La decisión no es "MCP o A2A"; es "necesito uno, el otro, o ambos".

Limitaciones y madurez

A2A v1.0 es reciente. Aunque hay despliegues de producción en Microsoft, AWS, Salesforce, SAP y ServiceNow según la cobertura de Stellagent, el ecosistema de agentes interoperables es todavía pequeño comparado con el de herramientas MCP. Construir con A2A hoy implica construir muchas de las piezas que MCP ya tiene maduras: librerías, gateways, debuggers, observabilidad. Si tu problema es "un agente con muchas tools", A2A añade complejidad sin resolver nada nuevo.

Tabla comparativa: MCP vs WebMCP vs A2A

La tabla es densa a propósito. Si tuviéramos que resumirla en una frase: MCP manda dentro del agente, A2A manda entre agentes, WebMCP manda en el navegador. Cualquier decisión arquitectónica empieza por identificar dónde estás y trabajar desde ahí.

Ejemplo real 1: PA de Kiwop usa MCP stdio

Nuestro PA (Personal Assistant) — el asistente personal IA que construimos en Kiwop tras el corte OAuth de Anthropic del 4 de abril de 2026, documentado al detalle en de OpenClaw a PA con Claude Code y MCP — es un caso de escuela del uso óptimo de MCP stdio.

La arquitectura en una frase

Claude Code corre en una máquina local (macOS, con launchd como gestor de procesos). Necesita acceso a Gmail, Google Calendar, Google Drive y Slack. Para cada uno de esos cuatro servicios, tenemos un servidor MCP local arrancado como subproceso de la sesión. El cliente MCP embebido en Claude Code lanza los servidores por stdio, descubre sus tools, y las invoca cuando hace falta.

Por qué stdio y no Streamable HTTP

La tentación era desplegar los servidores MCP en un endpoint HTTP y que Claude Code se conectara por red. Lo descartamos por tres razones:

1. Credenciales: las OAuth tokens de Gmail, Calendar, Drive y Slack viven en el Keychain de macOS. Exponer esos tokens por red implicaría tunneling, rotación, y un modelo de secretos que no queríamos.
2. Latencia: stdio es proceso local con pipe UNIX. Cada invocación es submilisegundo. Un endpoint HTTP añade tiempo de red sin ganancia funcional.
3. Simplicidad operativa: el día que algo se rompe, inspeccionar un proceso local es infinitamente más fácil que depurar un servicio remoto.

La decisión encaja con la lógica general que describimos en LLMOps: gestionar modelos de lenguaje en producción — mantener cerca lo que puede estar cerca reduce superficie de fallo. Esa es la filosofía que vamos a reflejar también en el próximo post sobre patrones y antipatrones de agentes IA en producción.

Qué NO hemos tocado

Ni WebMCP ni A2A. El PA es un solo agente (Claude Code) con muchas herramientas, operado por una sola persona. Introducir A2A sería sobre-ingeniería pura: no hay otro agente con quien coordinarse. Introducir WebMCP no aplica: no hay un navegador de por medio, y los servicios MCP ya cubren todo lo que necesitamos.

Esto es importante: un buen diseño es tan valioso por lo que deja fuera como por lo que incluye. Cada protocolo añadido es código a mantener, superficie de ataque, y dependencia de políticas de proveedor.

Ejemplo real 2: Nexo (nuestro SaaS) planea WebMCP para clientes

Nexo es el SaaS interno que estamos construyendo en Kiwop — un workspace colaborativo con capacidades de agentes integrados. Sin entrar en detalles de producto (lanzará oficialmente más adelante), sí podemos contar la decisión arquitectónica sobre protocolos, porque ilustra perfectamente el dilema que enfrentarán la mayoría de SaaS en los próximos 12-18 meses.

El problema: clientes que quieren conectar sus propios agentes

Los clientes beta nos pedían dos cosas muy distintas:

1. "Queremos que nuestros propios agentes (Claude, GPT, agentes internos del cliente) accedan a los datos de su workspace en Nexo."
2. "Queremos que vuestros agentes internos en Nexo puedan colaborar con los agentes que ya tiene mi empresa."

Son dos problemas de protocolos completamente distintos.

Decisión: WebMCP (y MCP remoto) para el primero, A2A para el segundo

Para el primer problema (clientes conectando agentes externos a sus datos en Nexo) decidimos exponer un servidor MCP Streamable HTTP por tenant y, en paralelo, preparar endpoints WebMCP para que cuando los usuarios naveguen la UI de Nexo desde un navegador con agente, ese agente pueda descubrir las acciones disponibles sin scrapear el DOM. Las tools expuestas son las mismas en ambos transportes; cambia quién las consume y cómo se autentican. Encaja con lo que ya recomendamos a clientes en nuestro servicio de integración de LLMs.

Para el segundo problema (orquestación de agentes de cliente con nuestros agentes) apostamos por A2A. Publicaremos Agent Cards firmadas para cada capability interna (classify-document, summarize-meeting, draft-email), el cliente podrá descubrirlas desde su agente orquestador, y el tráfico será JSON-RPC sobre HTTP con OAuth 2.0. La ventaja clave de A2A frente a "hago otra API REST" es que el cliente no tiene que aprender nuestra API: su agente descubre, lee la card, y opera.

Qué NO hemos elegido y por qué

Descartamos montar todo sobre MCP puro aunque técnicamente es posible. La razón es que MCP está optimizado para agente↔tool: si un cliente quiere delegar a Nexo con un agente propio y obtener resultados complejos (multi-step, con estados intermedios, con razonamientos expuestos), A2A encaja mejor. MCP no está pensado para conversaciones agente↔agente con memoria compartida.

Descartamos también empezar con A2A para todo, ya que para el caso "cliente que quiere leer/escribir datos de su workspace con Claude" un servidor MCP es la ruta corta y estándar, con el mayor ecosistema de clientes detrás.

La lección más amplia, para cualquier SaaS que esté pensando cómo abrirse a agentes: no es una decisión binaria, es una decisión por caso de uso. Exponer datos a un único agente cliente → MCP remoto. Exponer una web pública a agentes que la visitan → WebMCP. Interoperar con agentes de clientes como iguales → A2A.

Cuándo NO usar MCP (ni WebMCP ni A2A)

Un capítulo que falta en muchos artículos. Los protocolos de agentes son muy buenos para su dominio y muy malos fuera de él. Algunas señales de que NO deberías meter MCP, WebMCP ni A2A en tu arquitectura:

• Latencia extrema. Si la operación requiere respuesta submilisegundo (trading de alta frecuencia, control industrial, videojuegos), la sobrecarga de JSON-RPC, el handshake, la descripción de tools y el round-trip del modelo matan cualquier protocolo de agentes. Usa APIs binarias específicas.
• Streams binarios masivos. Transcodificación de vídeo, procesamiento de imágenes en volumen, streaming de audio en tiempo real. MCP puede invocar el job, pero no es el canal por el que viajan los bytes. Conserva tus pipelines específicos.
• Procesos batch largos sin agente. Si tu caso es "cron job procesa un CSV todas las noches", un agente IA con MCP es artillería contra pardales. Un script y un scheduler siguen siendo la respuesta correcta.
• Determinismo estricto. Operaciones bancarias, transacciones críticas, logs de auditoría. Un agente con tools puede quedar en el loop, pero el motor transaccional debe ser determinista, con reintentos documentados y sin margen a "el modelo eligió otra tool".
• Compliance regulado con auditoría exhaustiva. Si cada llamada debe dejar traza legalmente reproducible, necesitas una capa por debajo de los protocolos de agentes — no por encima — que garantice ese registro. Se puede hacer, pero añadir un agente IA no simplifica el compliance; lo complica.

Relacionado: en sectores regulados (sanitario, legal, financiero), cualquier arquitectura de agentes IA requiere pasar por una fase de consultoría de inteligencia artificial para entender qué está permitido antes de elegir protocolo. Elegir protocolo sin pasar por ahí es el antipatrón clásico.

Interoperabilidad: ¿puedes combinar los tres?

Sí, y de hecho es probable que lo hagas. El patrón más limpio en abril de 2026 combina los tres protocolos en un stack coherente.

El diagrama conceptual:

1. Un agente orquestador (nivel más alto, habla A2A hacia afuera).
2. Cuando necesita usar una herramienta interna (leer una base de datos, llamar a una API empresarial) → MCP.
3. Cuando necesita delegar una subtarea compleja a otro agente especializado → A2A hacia ese agente.
4. Cuando necesita actuar sobre un sitio web externo que no expone API propia pero sí WebMCP → cliente WebMCP vía navegador.

El agente receptor en A2A, a su vez, internamente usa MCP para sus propias tools. Y si el agente receptor es un SaaS público con frontend, probablemente exponga también una superficie WebMCP para usuarios humanos con agentes. El sistema es recursivo y componible: cada agente es un cliente de los tres protocolos y (potencialmente) un servidor de dos (MCP y A2A).

Esta composición es precisamente lo que describen fuentes como el mapa de protocolos de Digital Applied o la guía de WorkOS sobre MCP/ACP/A2A: los protocolos no compiten porque resuelven capas distintas. Compiten con sus alternativas en la misma capa (WebMCP vs Markdown for Agents; A2A vs ACP), no entre ellos.

Un matiz: evita la sobre-orquestación

Antes de meter los tres protocolos en un sistema, pregúntate si los necesitas. La mayoría de aplicaciones IA en producción a día de hoy necesitan solo MCP. Una minoría grande necesita MCP + WebMCP (SaaS con frontend público). Una minoría pequeña pero creciente necesita MCP + A2A (ecosistemas multi-agente). El caso triple es real pero raro. Si no puedes justificar por qué cada capa resuelve un problema distinto, probablemente sobra alguna.

Tabla: cuándo usar cada uno

Tabla: madurez de adopción a abril de 2026

Roadmap y adopción en 2026

Qué está en cada etapa según fuentes oficiales a abril de 2026:

• MCP: especificación estable del 25 de noviembre de 2025 con operaciones asíncronas y servers stateless; próximo hito relevante, el MCP Dev Summit Europe anunciado para el 17-18 de septiembre de 2026 en Amsterdam. Señales a observar: consolidación del transporte Streamable HTTP como default remoto, retirada progresiva del SSE legacy, estandarización de patrones de seguridad para tool poisoning.
• A2A: v1.0 publicada en marzo de 2026 con Signed Agent Cards y extensión formal AP2. Señales a observar: crecimiento del registro público de Agent Cards, aparición de gateways A2A (equivalentes a API gateways tradicionales), integración nativa con los grandes orquestadores (LangGraph, CrewAI, AutoGen).
• WebMCP: programa early preview abierto, implementación parcial en Cloudflare, soporte limitado en Chrome Canary. Señales a observar: aceptación del borrador en el W3C, decisión de Chromium Stable sobre soporte por defecto, posicionamiento definitivo frente a Markdown for Agents.
• Estándares adyacentes: AGENTS.md (propuesto por OpenAI, bajo AAIF), Open Responses (especificación abierta de OpenAI para loops agentes interoperables, reportada por InfoQ en febrero de 2026), y Skills (contribuidos por Block/Anthropic). Ninguno compite con MCP/WebMCP/A2A directamente, sino que resuelven piezas complementarias: descripción de repos, interoperabilidad de loops, bundling de prompts.

La predicción menos arriesgada para los próximos 6-12 meses es que MCP se consolide como commodity, A2A alcance su primera gran ola de despliegues B2B, y WebMCP siga siendo un terreno en disputa hasta que Chrome Stable decida soportarlo o no. En el caso de decidir no soportarlo, la propuesta puede morir o migrar a una solución alternativa (Markdown for Agents u otra).

Preguntas frecuentes

¿MCP es solo de Anthropic?

No desde diciembre de 2025. Anthropic donó MCP a la recién creada Agentic AI Foundation bajo la Linux Foundation, con Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare y Bloomberg como miembros platino. Hoy MCP es gobernanza comunitaria. Anthropic sigue contribuyendo fuertemente al desarrollo pero ya no es el único decisor.

¿WebMCP sustituye a mi REST API?

No. WebMCP expone una superficie pensada para agentes que operan desde navegadores. Tu REST API sigue siendo la vía correcta para integraciones backend-backend, apps móviles, y clientes autenticados con credenciales propias. WebMCP añade una capa orientada al agente del usuario, no la reemplaza.

¿A2A está listo para producción a abril de 2026?

Sí para casos estándar. La v1.0 publicada en marzo de 2026 incluye Signed Agent Cards y se considera apta para producción. Hay despliegues en Microsoft, AWS, Salesforce, SAP y ServiceNow. Sin embargo, el ecosistema de librerías y tooling está menos maduro que el de MCP — espera dedicar más ingeniería propia a gateways, observabilidad y gestión de Agent Cards.

¿Qué SDK usar para empezar con MCP?

Los SDKs oficiales en Python y TypeScript cubren la mayoría de casos. Para construir servidores en el ecosistema Anthropic, el SDK TypeScript oficial es la ruta recomendada. Para scripting y servidores locales, el SDK Python es el estándar. Ambos están mantenidos por Anthropic con soporte oficial.

¿Puedo usar MCP con modelos que no son de Anthropic?

Sí. Desde marzo de 2025, ChatGPT soporta MCP nativamente; Copilot y Gemini también. Los servidores MCP son agnósticos al modelo: cualquier cliente que hable el protocolo puede consumirlos. Esto es la razón principal por la que MCP ganó — la portabilidad entre proveedores es real, no marketing.

¿WebMCP es lo mismo que Markdown for Agents de Cloudflare?

No. Son dos propuestas competidoras con filosofías distintas. WebMCP expone acciones tipadas que el agente invoca; Markdown for Agents expone una representación markdown estructurada del sitio para que el agente la interprete. A abril de 2026 ambas coexisten y ninguna ha ganado. Si quieres cubrir ambos flancos, Cloudflare documenta cómo implementar soporte paralelo.

¿Cuál es la diferencia real entre A2A y ACP?

Conceptualmente resuelven el mismo problema: comunicación horizontal entre agentes. A2A es impulsado por Google y tiene mucha más tracción (150+ organizaciones, Linux Foundation, v1.0 producción). ACP es impulsado por IBM (BeeAI) con adopción más limitada. Técnicamente ACP usa convenciones HTTP más directas; A2A usa JSON-RPC con Agent Cards firmadas. Si hoy empiezas de cero, A2A tiene mejor relación valor/riesgo por ecosistema.

¿Necesito los tres protocolos en mi proyecto?

Casi nunca. La mayoría de proyectos IA empiezan con solo MCP. Un SaaS con frontend público añade WebMCP cuando el tráfico agente justifica la inversión. Un ecosistema con múltiples agentes interoperando añade A2A. El error común es meter los tres desde el día uno sin caso de negocio claro; el patrón sano es empezar con MCP y añadir el resto solo cuando hay problema real que resolver.

Conclusión: elige por capa, no por marca

La pregunta correcta en 2026 no es "¿qué protocolo es mejor?" sino "¿qué capa estoy resolviendo?". MCP manda dentro del agente, en el vínculo agente↔tool. A2A manda entre agentes, en el vínculo horizontal. WebMCP manda en la frontera entre tu web pública y los agentes que la visitan. Son tres capas distintas; no compiten, se componen.

La lección operativa, tras construir el PA sobre MCP stdio y diseñar Nexo sobre MCP remoto + A2A + WebMCP, es que el coste de elegir mal un protocolo es enorme. Cada protocolo trae consigo un modelo mental, un conjunto de librerías, una curva de adopción de clientes y un compromiso de mantenimiento a largo plazo. Pero también es cierto — y esto es quizás lo más importante — que la portabilidad entre capas ha nunca sido mayor. Un servidor MCP bien diseñado se consume desde Claude, ChatGPT, Copilot, Gemini y Cursor sin cambios. Un agente A2A bien diseñado es visible desde cualquier orquestador que hable el protocolo. Un sitio con WebMCP responde a cualquier agente que lo visite. La inversión en protocolos abiertos se amortiza rápido.

En Kiwop — Agencia Digital especializada en Desarrollo de Software e Inteligencia Artificial aplicada para clientes globales en Europa y USA — llevamos dos años construyendo sobre LLMs en producción y desde principios de 2025 sobre MCP. Si tu equipo está decidiendo hoy cómo abrir vuestra plataforma a agentes IA o cómo orquestar un sistema multi-agente, podemos ayudaros a elegir la arquitectura correcta sin sobre-ingeniería. Echa un vistazo a nuestros servicios de desarrollo de agentes IA, consultoría de inteligencia artificial e integración de LLMs — o escríbenos y nos sentamos.

Y si te ha interesado el recorrido técnico, sigue el hilo con los otros posts del cluster: de OpenClaw a PA con Claude Code y MCP, construye tu PA con Claude Code y MCP, agentes IA en producción: patrones y antipatrones 2026 y WebMCP: tu web preparada para agentes IA.