Implementar WebMCP en un sitio web de reclutamiento

Pensar en cómo, exactamente, «se ve» un sitio web en la era agéntica es un reto complicado. Podría ser que, en la mayoría de casos, nuestros futuros espectadores/lectores/clientes puedan hacerlo todo desde su chatbot de preferencia sin visitar jamás tu sitio.

WebMCP es una pieza de este puzle. El protocolo dirige a un agente a dejar de adivinar qué hace un botón y a empezar a llamar a herramientas con entradas tipadas mediante un protocolo de registro de herramientas fundamentalmente sencillo.

Así que, ¿qué es WebMCP? WebMCP es «un estándar emergente del W3C desarrollado por Google y Microsoft que actúa como una API del navegador para convertir los sitios web en herramientas interactivas para agentes de IA».

En este artículo repasamos lo que aprendieron al construirlo, las decisiones de diseño que tomaron y que funcionaron, la traza de un agente que cazó una alucinación en un sistema de producción (ya corregida) y por qué un sitio de reclutamiento resultó ser un encaje inusualmente bueno para este protocolo.

YubHub en Chrome 146 con el Model Context Tool Inspector abierto.

---

¿Por qué un sitio de reclutamiento?

Porque los sitios web, nuevos y viejos, van a tener que cambiar bastante rápido (y un portal de empleo desde cero es, en sí mismo, buena prueba de un enfoque martech serio).

La mayoría de los explicadores de WebMCP que circulan mientras se investiga esto usan un flujo de checkout, una lista de tareas o un selector de color. Juguetes. Sirven para ilustrar la superficie de la API (¿qué puede hacer esta cosa nueva?), pero sin implementar y trastear con el protocolo uno mismo me temo que simplemente no se le cae la ficha.

WebMCP interesa porque, en las últimas dos décadas, hemos visto la emergencia de los datos estructurados desde los Microformats hasta el esquema JSON-LD. Cuando consideras los datos estructurados en la web, WebMCP se siente como un paso lógico hacia adelante.

El valor real de WebMCP emerge cuando un agente necesita razonar sobre muchos datos estructurados que ya están detrás de una estructura de URLs bonita, y los sitios de reclutamiento se construyen justo alrededor de esa forma: detalles del puesto, rangos salariales, habilidades requeridas o ubicaciones de empleo.

Vídeo 3

YubHub ya servía datos limpios en URLs predecibles (/jobs/skill/figma, /jobs/at/anthropic) y emite marcado schema.org JobPosting. Lo que no tenía era un «contrato». Cualquier agente que navecase por el sitio podría ver el HTML y el JSON-LD, seguro, pero conseguir que un agente navegue por tu sitio web para una respuesta a través de Chrome es la mayor pérdida de tiempo del mundo cuando ideas tan fundamentales como una API llevan décadas entre nosotros.

WebMCP lo arregla publicando la interfaz de forma explícita, con entradas tipadas y respuestas estructuradas. Prompt de entrada > «encuéntrame un X para un Y en Z». Así que, para un sitio cuyo único trabajo es «ser detectable», WebMCP es un cambio importante.

El flujo básico. La página registra herramientas en navigator.modelContext, el agente las descubre y las invoca, la página responde con datos estructurados. Sin screen-scraping por medio.

¿Qué es WebMCP?

WebMCP es un estándar web propuesto, coautoría de ingenieros de Google y Microsoft bajo el grupo de comunidad W3C Web Machine Learning, que permite a un sitio exponer un conjunto de herramientas invocables a un agente de IA que se ejecuta en el navegador. Hay dos APIs: imperativa (navigator.modelContext.registerTool() llamada desde JavaScript) y declarativa.

Piénsalo como un contrato que el sitio publica a cualquier agente que aterrice en él. En lugar de que el agente adivine que un div con class="btn-primary" significa «checkout», la página dice: aquí hay una herramienta checkout, aquí está lo que necesita, aquí está lo que vas a recibir de vuelta.

Ese es un salto bienvenido desde el screen-scraping y el control del navegador basado en MCP. El quickstart de Chrome DevTools MCP medía una tarea sencilla de «poner el contador a 42» en 3.801 tokens usando capturas de pantalla y en 433 tokens usando WebMCP. ¡Eso es una reducción del 89 % en el uso de tokens!

La especificación actual vive en el sitio del grupo de comunidad del W3C (webmachinelearning.github.io/webmcp), con el anuncio de vista previa temprana de Chrome y posts detallados en developer.chrome.com/blog/webmcp-epp. Se publica tras un flag en Chrome Canary 146. Google Chrome Labs mantiene una extensión de referencia, el Model Context Tool Inspector, que lista las herramientas que cualquier página ha registrado y te deja llamarlas a mano. Si planeas construir algo con esto, vas a querer tener ambos instalados.

En qué se diferencia WebMCP de MCP

¡Los nombres no ayudan mucho, la verdad! Model Context Protocol (MCP) es del lado del servidor: despliegas un servidor MCP al que un agente se conecta, se ejecuta en su propio proceso, expone herramientas a tu asistente de IA por JSON-RPC. En Converly mantenemos una biblioteca creciente de conectores MCP propios, como Gemini MCP y Converly-LM.

Si necesitas repasar qué es el MCP antes de seguir, este vídeo lo explica con claridad:

Vídeo: qué es el MCP

WebMCP es el hermano del lado del navegador. Tu código de herramienta se ejecuta en el contexto JavaScript de la página, así que tiene las cookies del usuario, su sesión, sus permisos: todo a lo que el usuario ya tiene acceso. No hay despliegue, no hay puente de autenticación, no hay servidor que pagar. Bueno, principalmente; obviamente sigues teniendo que mantener la página, pero no hay nada extra. Si tu sitio ya autentica al usuario, tus herramientas WebMCP heredan esa autenticación gratis.

La consecuencia práctica: MCP es el encaje adecuado para agentes que necesitan datos de terceros (GitHub, Gmail, una base de datos). WebMCP es el encaje adecuado para agentes que necesitan interactuar con un sitio específico que el usuario ha solicitado.

Puesta a punto

Si tienes Chrome Canary 146 o superior, ya estás listo. Los canales estable, Beta y Dev de Chrome no incluyen el flag de WebMCP, así que tienes que activarlo:

Abre una pestaña nueva en chrome://flags/#enable-webmcp-testing y pon «WebMCP for testing» en Enabled. Haz clic en Relaunch.

Activa WebMCP for testing

Tercero, instala la extensión Model Context Tool Inspector desde la Chrome Web Store. Ahora mismo es la única forma de probar algo antes de cablear un agente. Lista todas las herramientas que la página actual ha registrado, te muestra sus esquemas JSON y te deja ejecutarlas a mano con la entrada que quieras. La extensión requiere una clave de API de Gemini porque usa Gemini como arnés de prueba en lenguaje natural, lo cual es útil para comprobar si tus descripciones de herramientas son lo suficientemente claras para que un LLM real elija la herramienta correcta. Es muy parecido al contexto de herramienta que se fija en las descripciones de herramientas del protocolo MCP.

La extensión WebMCP Inspector.

Para verificar que todo funciona, abre DevTools y ejecuta console.log(navigator.modelContext). Si ves que vuelve un objeto en lugar de undefined, estás en marcha. Si es undefined, o tu flag no está activado o estás en el canal de Chrome equivocado.

Configurar la API imperativa

Aquí está el registro de herramienta mínimo viable del scaffold en producción de YubHub:

if (!navigator.modelContext) return;

var pageController = new AbortController();
addEventListener('pagehide', () => pageController.abort(), { once: true });

navigator.modelContext.registerTool({
  name: 'yubhub_fetch_job',
  description: 'Fetch a single YubHub job as clean markdown (company, location, salary, work arrangement, full description, apply URL, skills). More token-efficient than the HTML page.',
  inputSchema: {
    type: 'object',
    properties: {
      id: { type: 'string', pattern: '^job_[a-z0-9_-]+$' },
    },
    required: ['id'],
  },
  execute: async (params) => {
    const r = await fetch('/jobs/' + params.id + '.md',
      { headers: { Accept: 'text/markdown' } });
    return { id: params.id, markdown: await r.text() };
  },
}, { signal: pageController.signal });

Aquí hay 4 cosas que mirar: primero, el guard de detección de funcionalidad. navigator.modelContext solo existe en Chrome 146 con el flag activado, así que todo scaffold orientado al público necesita cortocircuitar de forma elegante en el resto de sitios o lanzará una excepción en cualquier otro navegador desde el que tus usuarios visiten.

La restricción de patrón en id: la especificación trata JSON Schema de forma laxa en el navegador, así que validar en código caza los casos que el esquema no caza. Y el valor de retorno es un objeto estructurado, no una cadena: el agente lo lee como datos en lugar de intentar parsear text/html.

El Inspector mostrando el esquema de la herramienta (caja verde) y el prompt del agente (caja roja). Puedes manejarlo todo a mano durante el desarrollo, que es la forma más rápida de cazar malas descripciones de herramientas.

La API declarativa es ingeniería gratis

Esta es, según las pruebas en YubHub, la parte más lista de la especificación de WebMCP. Si tienes un formulario HTML —y por supuesto que lo tienes— puedes anotarlo y obtener un registro de herramienta gratis.

La navegación de YubHub ya tenía un formulario GET que enviaba a /jobs/search. En las pruebas, solo hicieron falta tres atributos más:

<form action="/jobs/search" method="GET"
      toolname="yubhub_search"
      tooldescription="Search YubHub's enriched job board by free-text query - title, company, or keyword. Submits a GET to /jobs/search and renders the results page."
      toolautosubmit>
  <input type="search" name="q"
         toolparamdescription="Job title, company name, or any keyword (2-100 chars)"
         minlength="2" maxlength="100" />
</form>

El navegador lee el formulario, construye un JSON Schema a partir de los campos de entrada y lo registra como herramienta. Cuando un agente la llama con {q: "python"}, el navegador enfoca el formulario, rellena la entrada y, debido a toolautosubmit, lo envía automáticamente. Cero JavaScript. Tu formulario ya funciona para humanos; ahora funciona para agentes.

Algo que vale la pena destacar: toolautosubmit solo es realmente seguro en operaciones de solo lectura. Consultas de búsqueda, comprobaciones de disponibilidad, comprobaciones de estado: bien, deja que el agente envíe. Cualquier cosa que cree, modifique o borre datos debería dejar el flag desactivado, de modo que el humano tenga que hacer clic en Submit después de que el agente rellene el formulario.

Y eso, calculan quienes lo probaron, es como probablemente empezará a emerger la adopción de WebMCP: añadiéndolo a los formularios de búsqueda internos del sitio y a las páginas de resultados. Pero se espera ver que la gente coincide en que esta idea se queda corta respecto a lo que WebMCP puede hacer a largo plazo.

Registro de herramientas con ámbito de contexto

En YubHub registraron una herramienta llamada yubhub_current_job. No toma argumentos y simplemente devuelve el markdown del puesto actual. Obviamente, eso solo tiene sentido en las páginas de listado de puestos, así que en cualquier otro lugar del sitio carecería de significado (peor, sería confuso). El scaffold hace pattern-matching de la URL y registra de forma condicional:

const jobMatch = location.pathname.match(/^\/jobs\/(job_[a-z0-9_-]+)$/i);
if (jobMatch) {
  const currentJobId = jobMatch[1];
  navigator.modelContext.registerTool({
    name: 'yubhub_current_job',
    description: 'Return clean markdown for the job the user is currently viewing ('
      + currentJobId + '). Zero-arg shortcut.',
    inputSchema: { type: 'object', properties: {} },
    execute: async () => {
      const r = await fetch('/jobs/' + currentJobId + '.md');
      return { id: currentJobId, markdown: await r.text() };
    },
  }, { signal: pageController.signal });
}

El AbortController lo ata al ciclo de vida de la página: cuando el usuario navega a otra parte, se dispara pagehide, el controller aborta y todas las herramientas registradas con su señal desaparecen del radar del agente. Lo importante es que esto no deja closures sueltas con referencias al estado de la página anterior.

Mismo sitio, tres páginas, tres menús de herramientas distintos. El agente ve solo las herramientas que tienen sentido contextual.

Herramientas de navegación frente a herramientas de obtención de datos

Hay dos tipos de herramientas que puedes darle a un agente, y crean experiencias de usuario completamente distintas.

Las herramientas de navegación cambian la URL en nombre del usuario. Son la decisión correcta cuando el usuario de verdad quiere acabar en otro sitio: ver un puesto concreto, navegar por una faceta, lanzar una búsqueda. Así que el agente llama a yubhub_browse_jobs({type: 'skill', slug: 'figma'}), la pestaña navega, el usuario ve la página de archivo. El valor de retorno es básicamente un recibo («te he llevado aquí, aquí está lo que hay en la página»).

El poder real, según las pruebas, es este: las herramientas de obtención de datos devuelven datos parseados y dejan la URL intacta. El agente las llama para razonar, comparar, filtrar, resumir, y el usuario se queda en la página en la que ya estuviese, sin percatarse de que el agente acaba de leer cien puestos para responder a una pregunta. yubhub_fetch_facet devuelve hasta 100 entradas schema.org JobPosting; yubhub_shortlist las filtra por suelo salarial, estado remoto, palabra clave del título y devuelve una lista ordenada.

La obtención de datos es por lo que apostaron en YubHub: es una solución increíblemente potente para el estado actual del webcrawl basado en IA y las acciones para los usuarios y demás.

yubhub_shortlist devolviendo una lista ordenada de puestos de product manager.

Enviar solo herramientas de navegación es el error que las pruebas dejaron claro. Simplemente convierte al agente en un reescritor de URLs elegante: puede responder a «llévame a X», pero no puede responder a «resume las opciones y recomienda una» sin arrastrar a todo el usuario por delante.

Lo que WebMCP (todavía) no puede hacer

Hace falta un contexto de navegación. No hay modo headless: si no hay una pestaña abierta, las herramientas no existen. Eso descarta, por ahora, el trabajo agéntico por lotes o programado contra un sitio WebMCP.

La detectabilidad es escasa. Un agente tiene que visitar tu página para ver tus herramientas. No hay un registro global, ningún índice de «eh, agente, aquí tienes una lista de sitios con herramientas WebMCP útiles». Se ha propuesto un manifiesto .well-known/webmcp —y parece que será necesario tarde o temprano— pero todavía no ha salido nada. Alguien va a sacar un directorio de autoridad de marcas que soportan WebMCP de un momento a otro.

La especificación se mueve cada semana. Entre el primer contacto con la documentación y el despliegue en producción, la implementación de YubHub vio cómo provideContext y clearContext se eliminaron por completo, unregisterTool volvió tras estar brevemente deprecado y el manejo del AbortSignal en el segundo argumento de registerTool se asentó en la forma de arriba. Sigue el repo de la especificación y espera tener que reescribir cosas. El grupo de preview del estándar es muy fácil de unirse.

Si mantienes un sitio que tiene datos estructurados detrás de URLs predecibles —un catálogo de productos, un portal de empleo, un sitio de documentación, una biblioteca de medios— WebMCP merece la pena publicarlo ya, aunque la adopción del navegador sea casi cero. Es barato de añadir, te obliga a pensar en tus contratos de herramientas antes de que los agentes intenten adivinarlos y posiciona al sitio para cuando Chrome quite el flag y Edge siga. Cuando eso pase, habrá bastante revuelo.

El trabajo de consultoría de Converly alrededor de servidores MCP se mapea al mismo conjunto de decisiones. Los protocolos difieren; el pensamiento de diseño de herramientas, no.