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

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

Ryan Turner
Ryan Turner · Head of Innovation

La red agencial consiste en el cambio hacia el tratamiento de los agentes de IA como clientes web de primera clase. 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 su totalidad, resumida en una sola frase. La web que usted y yo navegamos se creó para los ojos humanos y los clics del ratón. La «web agentiva» 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 constituyen la base de esa interfaz: WebMCP y el Protocolo de Contexto de Modelo (Model Context Protocol), junto con su servidor de referencia Fetch.

Puntos clave
  • La «web agencial» trata a los agentes como clientes nativos, de modo que son los sitios web los que ponen a disposición herramientas a las que se puede llamar, en lugar de que sean los agentes los que extraigan datos del 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 código HTML a Markdown, lo que reduce considerablemente el coste de los tokens del agente.
  • La adopción es precoz y desigual. La mayoría de las plataformas no pondrán a disposición las herramientas nativas de los agentes a corto plazo.
  • Hasta que eso ocurra, los agentes seguirán necesitando navegadores, API de renderizado y de búsqueda, así como una red de dispositivos reales para la «cola larga».

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

Acceso nativo del agente Se trata de 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 web 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 dichos programas deja de ser algo opcional y pasa a ser una cuestión de diseño.

También existe un motivo más sutil. Cuando un sitio web puede proporcionar a un agente una ruta clara y autorizada, controla lo que el agente ve y hace. En consecuencia, esto resulta más predecible para el propietario del sitio web que permitir 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 cumple 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 Se trata de un estándar propuesto, presentado en Google I/O 2026, que permite a un sitio web exponer sus propias funciones de JavaScript y formularios HTML como herramientas a las que puede recurrir un agente basado en el navegador. Según Chrome, Chrome en la I/O 2026, el sitio web especifica lo que un agente puede hacer; el agente lee dichas 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 web publica un submitOrder herramienta con parámetros tipificados. El agente la invoca. No hay que adivinar el selector ni esperar de forma inestable a que se carguen los elementos que tardan en mostrarse.

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 la intención mediante ingeniería inversa. 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 de los que ya dispone el usuario. Esto evita una serie de problemas de acceso, aunque solo en los sitios web 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 Modelo. Realiza una tarea a la perfección: toma una URL, recupera la página y convierte el código 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 realizar consultas básicas de páginas.

La clave está en la conversión a Markdown. El HTML sin procesar está sobrecargado con elementos de navegación, scripts, estilos y marcados de seguimiento que un agente no necesita y por los que paga en tokens. Reducir una página a 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 cargue una página de producto en formato 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. 4.ª parte analiza esa disyuntiva con detalle.

MCP Fetch y WebMCP se ocupan de capas diferentes. 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 alguna acción. La mayoría de los flujos de trabajo de los agentes reales necesitan ambos, y observamos que los equipos crean su propia capa de recuperación sobre la base de estos elementos básicos, en lugar de considerar cualquiera de los dos estándares como el proceso completo.

Tenga claro hasta dónde llega Fetch. Recupera y convierte, pero no ejecuta JavaScript, no resuelve páginas con retos 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 error, razón por la cual los equipos lo combinan con un procesamiento más complejo para cualquier caso en el que se presente resistencia. Si está creando ese flujo de trabajo por su cuenta, crear un MCP Server 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, así como 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. Por su parte, MCP Fetch solo gestiona páginas sencillas que se pueden recuperar. La gran mayoría de la web no ofrece herramientas nativas para los agentes, y una gran parte bloquea activamente el acceso automatizado. En este ámbito, 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 ofrece un servicio limpio a MCP Fetch, el acceso se simplifica y el modelo de direccionamiento sale ganando. En el caso de la «cola larga», 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 destinos protegidos. En nuestras pruebas comparativas de proveedores, las solicitudes con direcciones IP residenciales suelen tener éxito en sitios protegidos con tasas mucho más elevadas que las direcciones IP de centros de datos, a menudo en un rango del 85 al 99 %, frente a aproximadamente el 20 al 40 % en el caso de los centros de datos, razón por la cual los equipos redirigen los casos más difíciles a través de orígenes de dispositivos reales. Esta es la capa que cubren la red de acceso a dispositivos de Massive y Web Render API: HTML limpio o Markdown procedente 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 razonamiento que subyace a este proceso, Entrenamiento de modelos de lenguaje a gran escala (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 se incluye 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 emergente y no una plataforma acabada en la que pueda confiar en toda la web abierta.

¿Sustituye WebMCP al «web scraping»?+

No, no será pronto. WebMCP solo resulta útil en los sitios web que lo implementan, lo cual, a día de hoy, supone un número 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. Le recomendamos que tenga en cuenta 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 código HTML a Markdown para que el agente pueda procesarlo. WebMCP actúa: permite que un sitio web exponga funciones y formularios que se pueden invocar, de modo que un agente pueda realizar tareas. Leer frente a actuar. La mayoría de los flujos de trabajo utilizan ambos de forma conjunta.

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

El código HTML sin procesar incluye elementos de navegación, scripts y estilos que desperdician tokens y saturan la ventana de contexto. Markdown lo reduce 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 margen para que el modelo analice lo que realmente importa.