¿Qué es la «Web agencial»? WebMCP, MCP Fetch y el acceso nativo para agentes
Todas las entradas

¿Qué es la «Web agentiva»? WebMCP, MCP Fetch y el acceso nativo para agentes

Ryan Turner
Ryan Turner · Head of Growth

La red agencial es la tendencia a tratar a los agentes de IA como clientes web de primer orden. En lugar de que un agente tenga que adivinar cómo actuar a partir de código HTML sin procesar, un sitio web pone a su disposición herramientas estructuradas a las que el agente puede acceder directamente. El sitio web indica al agente cómo interactuar, en lugar de que este tenga que realizar ingeniería inversa del DOM y esperar que el diseño no haya cambiado de la noche a la mañana.

Esa es la idea en pocas palabras. La web que usted y yo navegamos se creó para los ojos humanos y los clics del ratón. La web «agente» añade una segunda interfaz, diseñada para máquinas que leen, deciden y actúan en su nombre. En la actualidad, dos estándares sustentan esa interfaz: WebMCP y el Protocolo de Contexto de Modelo (Model Context Protocol), junto con su servidor de referencia Fetch.

Puntos clave
  • La red de agentes trata a los agentes como clientes nativos, de modo que son los sitios web los que exponen herramientas invocables, en lugar de que los agentes rastreen el DOM.
  • WebMCP, presentado en Google I/O 2026, permite a un sitio web publicar funciones de JavaScript y formularios HTML como herramientas que un agente puede invocar.
  • MCP Fetch es un servidor estándar que recupera una URL y convierte el HTML a Markdown, lo que reduce considerablemente el coste de los tokens del agente.
  • La adopción es temprana y desigual. La mayoría de los sitios no pondrán a disposición las herramientas nativas del agente a corto plazo.
  • Mientras tanto, los agentes siguen necesitando navegadores, API de renderizado y búsqueda, así como una red de dispositivos reales para los casos menos habituales.

¿Qué significa realmente «acceso nativo del agente»?

Acceso nativo del agente Es un modelo en el que un sitio web da a conocer sus propias capacidades a los agentes, de modo que el agente invoca una función específica en lugar de analizar una página. Esto replantea el acceso a la web. El modelo antiguo se basa en la detección y la evasión: un agente carga una página, el sitio intenta detectar el bot y el agente intenta no parecer uno. El acceso nativo del agente, por el contrario, convierte eso en un problema de direccionamiento y protocolo, más parecido a llamar a una API que a extraer datos de una pantalla.

Esta distinción es importante porque el tráfico generado por bots ya no es un caso aislado. En 2024, los bots automatizados representaban el 51 % de todo el tráfico web, lo que supuso la primera vez en una década que las máquinas superaban a los humanos, según Imperva, Informe sobre bots maliciosos de 2025. Cuando la mayoría de sus visitantes son programas informáticos, crear una interfaz para ellos deja de ser algo opcional y se convierte en una cuestión de diseño.

También hay un motivo más sutil. Cuando un sitio web puede proporcionar a un rastreador una ruta clara y autorizada, controla lo que el rastreador ve y hace. En consecuencia, esto resulta más predecible para el propietario del sitio que dejar que miles de rastreadores actúen a su antojo en un diseño que nunca se concibió para ellos. El sitio establece las condiciones, el agente las sigue y ambas partes se encuentran con menos sorpresas.

Además, cambia el modo de fallo. El scraping del DOM falla de forma silenciosa cuando cambia el nombre de una clase o se desplaza un botón; una herramienta nativa del agente o bien existe o bien no existe, y un contrato versionado puede indicarlo de forma explícita. Por lo que observamos en las cargas de trabajo de los agentes, los ingenieros responsables de la capa de acceso suelen preferir el segundo tipo de fallo, ya que es evidente y comprobable, en lugar de silencioso e intermitente. Para conocer los antecedentes de por qué esto es importante en toda la pila, consulte proporcionar a los agentes de IA acceso en tiempo real a la web.

¿Cómo funciona WebMCP?

WebMCP es un estándar propuesto, presentado en Google I/O 2026, que permite a un sitio web exponer sus propias funciones JavaScript y formularios HTML como herramientas a las que puede recurrir un agente basado en el navegador. Según Chrome, Chrome en I/O 2026, el sitio web especifica lo que un agente puede hacer, el agente lee esas especificaciones y las invoca como si fueran llamadas a una API. En resumen, la página describe sus propias acciones en lugar de obligar al agente a deducirlas.

Imagínese el proceso de pago. Sin WebMCP, un agente tiene que localizar los campos de entrada correctos, rellenarlos, encontrar el botón de envío y confirmar el resultado, todo ello leyendo píxeles y nodos DOM que pueden cambiar de una versión a otra. Con WebMCP, en cambio, el sitio publica un submitOrder herramienta con parámetros tipificados. El agente la invoca. Sin tener que adivinar el selector, sin esperas inestables a elementos que se cargan tarde.

Hay dos características que hacen que esto resulte útil. En primer lugar, el contrato es explícito: el sitio web especifica sus herramientas, por lo que el agente no tiene que deducir sus intenciones. En segundo lugar, el agente se ejecuta en la propia sesión del navegador del usuario, lo que significa que actúa con los permisos y la identidad que el usuario ya posee. Esto evita una serie de problemas de acceso, aunque solo en los sitios que ofrecen compatibilidad con WebMCP, que actualmente son pocos.

¿Qué es MCP Fetch y por qué es importante?

MCP Fetch es el servidor Fetch de referencia en el ecosistema del Protocolo de Contexto de Modelos. Cumple a la perfección una única función: toma una URL, recupera la página y convierte el HTML en formato Markdown que un agente pueda leer. Según el Repositorio de servidores del Protocolo de Contexto de Modelos, se trata de una herramienta estándar y reutilizable a la que cualquier agente compatible con MCP puede conectarse para la recuperación básica de páginas.

La clave está en la conversión a Markdown. El HTML sin procesar está repleto de elementos de navegación, scripts, estilos y marcados de seguimiento que un agente no necesita y por los que paga con tokens. Reducir una página a un Markdown limpio reduce considerablemente el número de tokens, a menudo en más de la mitad, lo que disminuye el coste y deja más espacio en la ventana de contexto del modelo para el razonamiento propiamente dicho. Por ejemplo, un agente que carga una página de producto como HTML sin procesar puede gastar la mayor parte de su presupuesto en menús y etiquetas de script antes de llegar al único párrafo que necesita. El informe del profesional en dev.to, Herramientas de navegador para agentes de IA. Parte 4 analiza esa disyuntiva en detalle.

MCP Fetch y WebMCP abordan diferentes niveles. Fetch se encarga de la lectura: recupera una página y devuelve el texto limpio. WebMCP, por el contrario, se encarga de la acción: invoca las funciones declaradas de un sitio web para realizar una acción. La mayoría de los flujos de trabajo de agentes reales necesitan ambos, y observamos que los equipos construyen su propia capa de recuperación sobre estas primitivas, en lugar de considerar cualquiera de los estándares como el proceso completo.

Tenga claro hasta dónde llega Fetch. Recupera y convierte, pero no ejecuta JavaScript, no resuelve páginas complejas ni redirige el tráfico de salida cuando un sitio bloquea la solicitud. En un artículo estático funciona correctamente. Sin embargo, en una aplicación de una sola página o en un destino protegido, devuelve una página vacía o una página de bloqueo, por lo que los equipos lo combinan con un procesamiento más complejo para cualquier elemento que plantee dificultades. Si está creando ese proceso usted mismo, crear un servidor MCP para la extracción de datos web cubre el patrón de principio a fin.

¿En qué situación quedan los agentes de hoy en día?

Los agentes actuales siguen necesitando navegadores, API de renderizado y búsqueda, y una red de dispositivos reales, ya que los estándares nativos para agentes se encuentran en una fase inicial y su adopción es desigual. WebMCP es una propuesta. MCP Fetch, por su parte, solo gestiona páginas sencillas y recuperables. La gran mayoría de la web no expone herramientas nativas para agentes, y una gran parte bloquea activamente el acceso automatizado. En este caso, los estándares son complementarios, no sustitutivos.

El bloqueo es una realidad y va en aumento. En 2025, Cloudflare comenzó a bloquear de forma predeterminada los rastreadores de IA en aproximadamente el 20 % de la web a partir del 1 de julio, según Cloudflare, Cloudflare acaba de cambiar la forma en que los rastreadores de IA recopilan información de Internet en general. Los editores de noticias fueron más allá: en 2025, aproximadamente el 79 % de los principales sitios web de noticias bloquearon los bots de entrenamiento de IA, según Press Gazette, Ocho de cada diez de los principales sitios web de noticias del mundo bloquean ahora los bots de entrenamiento de IA. Por lo tanto, una herramienta WebMCP «limpia» no sirve de nada para los millones de sitios web que nunca la implementarán.

Así pues, ambos mundos coexisten. Cuando un sitio web adopta WebMCP o se sirve directamente a MCP Fetch, el acceso se simplifica y el modelo de direccionamiento sale ganando. En el caso de la «long tail», por el contrario, los agentes necesitan una representación real y orígenes de dispositivos de usuarios reales para acceder al contenido tal y como lo haría un visitante normal. La salida es más importante de lo que la gente espera en los objetivos protegidos. En nuestras pruebas comparativas de proveedores, las solicitudes con IP residenciales suelen tener éxito en sitios protegidos en proporciones mucho mayores que las IP de centros de datos, a menudo en el rango del 85 al 99 % frente a aproximadamente el 20 al 40 % para los centros de datos, razón por la cual los equipos redirigen los casos difíciles a través de orígenes de dispositivos reales. Esto es lo que cubren la red de acceso a dispositivos y la API Web Render de la capa Massive: HTML limpio o Markdown de cualquier fuente pública, en cualquier ubicación, incluidos los sitios que nunca expondrán una herramienta. Los estándares facilitan los casos sencillos; no eliminan los difíciles. En cuanto al aspecto de razonamiento de este proceso, Entrenamiento de modelos de lenguaje grandes (LLM) con datos web en tiempo real relaciona la recuperación con el resultado del modelo.

Fuentes

Preguntas frecuentes

¿Es la «web agencial» un estándar real o solo una moda pasajera?+

Se trata de una línea de actuación respaldada por propuestas concretas. WebMCP se presentó en Google I/O 2026 y MCP Fetch ya está disponible en el repositorio de servidores del Model Context Protocol. Los componentes ya existen. Sin embargo, aún no se ha generalizado su adopción, por lo que debe considerarse una infraestructura en desarrollo, y no una plataforma consolidada en la que se pueda confiar en toda la web abierta.

¿Sustituye WebMCP al web scraping?+

No, no a corto plazo. WebMCP solo funciona en los sitios web que lo implementan, lo cual, a día de hoy, es un grupo reducido. En el resto de casos, los agentes siguen analizando las páginas, ejecutando JavaScript y enrutando a través de redes de dispositivos reales para acceder al contenido. Es recomendable planificar ambas vías en el entorno de producción, en lugar de apostar por una compatibilidad universal nativa con los agentes.

¿Cuál es la diferencia entre WebMCP y MCP Fetch?+

MCP Fetch lee: recupera una URL y convierte el HTML a Markdown para que el agente pueda utilizarlo. WebMCP actúa: permite que un sitio web exponga funciones y formularios a los que se puede acceder, de modo que un agente pueda realizar tareas. Leer frente a actuar. La mayoría de los flujos de trabajo utilizan ambos juntos.

¿Por qué convertir HTML a Markdown para los agentes?+

El HTML sin procesar incluye elementos de navegación, scripts y estilos que desperdician tokens y saturan la ventana de contexto. Markdown reduce todo eso a contenido legible, reduciendo considerablemente el número de tokens, a menudo en más de la mitad. Menor coste, entrada más limpia y más espacio para que el modelo pueda centrarse en lo que realmente importa.