Abrimos nuestras reservas de globo a los agentes de IA. Así lo hicimos.

Qué es WebMCP, sin tecnicismos

El Model Context Protocol, MCP para abreviar, es la convención que permite a un asistente de IA llamar a herramientas escritas por otra persona. WebMCP es su versión para el navegador. En lugar de un servidor que publica herramientas en algún punto de la red, es la página web la que se las ofrece al agente que corre en el navegador de quien la está leyendo.

La mecánica cabe en una frase. La página llama a document.modelContext.registerTool() y le pasa un nombre, una descripción, un esquema con los datos de entrada y una función que ejecutar. A partir de ahí, un agente en ese navegador ve la herramienta, la llama, y recibe datos estructurados a cambio.

Esto existe porque las alternativas son malas. Hoy, un agente que quiere algo de una web o lee el texto renderizado y deduce, o maneja la interfaz a base de clics. Lo primero produce respuestas seguras de sí mismas construidas sobre un párrafo caducado. Lo segundo se rompe la semana en que un botón cambia de sitio. Una herramienta registrada es la web diciendo en voz alta qué sabe responder y con qué forma, que es un problema bastante más pequeño de resolver bien.

El estado del estándar importa tanto como la mecánica. WebMCP es un informe en borrador del Web Machine Learning Community Group del W3C, en una versión fechada el 26 de agosto de 2026 y editada por ingenieros de Google y Microsoft. Chrome lo ofrece como prueba de origen (origin trial) en las versiones 149 a 156, es decir, activado para las webs que registren un token y durante un número limitado de versiones, mientras el diseño se pone a prueba en público. Un borrador en este punto no es ninguna promesa, así que lo tratamos como un experimento con fecha límite y no como una plataforma sobre la que edificar.

Por qué un operador de globos, precisamente

Hay dos rasgos de este producto que se lo ponen difícil a cualquier agente que solo sepa leer páginas. El primero es que el vuelo de mañana puede no existir. Los vuelos se cancelan por viento, y la autoridad autoriza o suspende cada sector esa misma mañana, unas horas antes del amanecer. Nada de lo escrito ayer en una página manda sobre eso, tampoco lo que escribimos nosotros.

El segundo es que el precio pertenece a una fecha. Una mañana de enero y una de finales de septiembre son productos distintos con precios distintos, definidos en una tabla de tarifas y no en el texto de una página. Una web que dice "desde 119 €" dice la verdad y responde a otra pregunta cuando el viajero pregunta por el 10 de septiembre.

Así que las dos preguntas que la gente hace de verdad, si volará y cuánto cuesta su fecha, son justo las dos que el texto estático contesta peor. Por eso fueron las dos primeras herramientas, antes que cualquier cosa relacionada con reservar.

Las cuatro herramientas

No es una demostración: están en funcionamiento. Probando en Chrome 151 con la marca de WebMCP activada el 2 de septiembre de 2026, un agente pidió el precio del 10 de septiembre de 2026 y recibió 249 euros por persona, que es lo que muestra la página de reserva para esa fecha, porque ambos leen la misma tabla de tarifas y no dos copias distintas.

Tres de las cuatro están marcadas como de solo lectura en su descriptor, que es la señal que permite a un agente, o a quien lo supervisa, distinguir mirar de actuar. Solo la cuarta cambia algo en pantalla, y lo que puede cambiar está muy acotado.

Lo que no abrimos

La cuarta herramienta es donde está la decisión de verdad. prefill_booking_form rellena el formulario. No puede enviarlo. No existe ninguna herramienta para cobrar, y no va a existir.

Los campos que un agente puede escribir están enumerados uno a uno en el código: nombre completo, correo, teléfono, país, hotel de recogida, peticiones especiales, además de la fecha y el número de pasajeros. Todo lo que quede fuera de esa lista se rechaza por su nombre. Probamos contra nosotros mismos el ataque evidente el 2 de septiembre de 2026: a un agente al que se le pidió escribir un número de tarjeta en el formulario le llegó de vuelta un rechazo que decía unknown_field. En la lista no hay ningún campo de tarjeta, así que en tiempo de ejecución no hay nada que negociar.

El pago transcurre donde siempre, en el banco del propio viajero y con 3D Secure. El número de tarjeta y el código que envía el banco viajan entre el viajero y su banco. Un agente capaz de leer la página no puede leerlos, porque nunca formaron parte de lo que la página ofrece a las herramientas.

Ese límite no es prudencia decorativa. Si una página de reserva puede permitirse ser útil a un agente es precisamente porque el paso irreversible sigue necesitando a una persona: alguien lee el resumen, ve el total y autoriza el pago en su banco. Automatizar los últimos treinta segundos eliminaría el único control que caza una fecha equivocada, y aquí una fecha equivocada significa un viajero esperando en la recepción de un hotel a las cuatro de la madrugada del día que no era.

Cómo está construido

No se añadió ninguna dependencia nueva. Todo el desarrollo son un hook de React, un archivo de funciones puras con la lógica y dos puntos de montaje, uno en la página de reserva y otro en la de estado de vuelo. En package.json no entró nada, que con una API tan joven era justamente la idea.

Cada acceso se comprueba antes de usarse. El hook busca document.modelContext, prueba después con navigator.modelContext y, si no encuentra ninguno, se retira y la página se muestra como siempre. El registro va envuelto, de modo que un cambio en la forma de la API no puede lanzar un error dentro de la página. Quien entre desde Safari, o desde un Chrome sin la prueba activada, verá una web idéntica byte a byte a la del mes pasado.

Esa desconfianza no es adorno. Mientras se construía esto, el punto de entrada ya se había movido dos veces: de window.agent a navigator.modelContext y de ahí a document.modelContext. Algo tan joven se volverá a mover. Tenerlo todo en un archivo significa que el día que se mueva editaremos una función y volveremos a desplegar.

La lógica que hay detrás de las herramientas, la consulta de precios, el listado de fechas y la lista blanca de campos, vive en funciones puras con pruebas unitarias, así que las reglas se verifican sin abrir un navegador. También significa que las reglas que protegen el formulario frente a un agente son las mismas para cualquier otra cosa que las llame.

Qué pasa a partir de ahora

La prueba de origen va de Chrome 149 a Chrome 156. Una web se apunta con un token ligado a su dominio y servido como cabecera HTTP, que es lo que hacemos: nuestro registro llega hasta el final de la prueba, en noviembre de 2026. Cuando la prueba termine ocurrirá una de tres cosas: que la API se publique, que cambie o que desaparezca. Si desaparece, borramos una cabecera y un hook, y ningún visitante nota nada.

La otra mitad del asunto está en el lado del agente, y esa no la controlamos. Las herramientas existen y responden bien cuando alguien las llama. Lo que sigue moviéndose es qué asistentes llaman: Gemini en Chrome todavía no recurre a herramientas de páginas ajenas en el canal estable. Hoy el cuello de botella es el agente, no el estándar.

Publicamos esto sin esperar a que se asiente, por dos motivos. Los detalles de una implementación que funciona le sirven más a otro operador que un anuncio, y nuestros propios viajeros ya le preguntan a su navegador por la mañana siguiente, esté la página lista para responder o no. Si llevas una web cuya respuesta correcta cambia cada día, esto merece una tarde de trabajo.

Consulta los mismos datos que devuelve una herramienta

Preguntas frecuentes

¿Qué es WebMCP?

WebMCP permite que una página web ofrezca herramientas con nombre propio a un agente de IA que funciona en el navegador del visitante, en lugar de obligarlo a adivinar a partir del texto de la página. La página registra cada herramienta mediante document.modelContext con un nombre, una descripción y un esquema de entrada. Es un informe en borrador del Web Machine Learning Community Group del W3C, en una versión fechada el 26 de agosto de 2026 y editada por ingenieros de Google y Microsoft, y Chrome lo ofrece como prueba de origen en las versiones 149 a 156.

¿Qué agentes de IA pueden usar estas herramientas?

Cualquier agente que funcione dentro de un navegador compatible, mientras el visitante esté en la página. En la práctica, eso significa las versiones 149 a 156 de Chrome a través de la prueba de origen, o cualquier Chrome con la marca de pruebas de WebMCP activada. No se expone nada a los rastreadores de buscadores, y las herramientas no envían datos personales a ninguna parte: la herramienta de estado de vuelo hace la misma consulta que la página ya hace por su cuenta, y fijar la fecha o el número de pasajeros activa la misma actualización de página que provocaría una persona al elegir una fecha. Nada más sale del navegador.

¿Puede un agente de IA pagar mi vuelo en globo?

No. La herramienta de prellenado rellena campos visibles y no puede enviar el formulario. No existe ninguna herramienta de pago. Los datos de la tarjeta y el código 3D Secure van del viajero a su propio banco, y los campos de tarjeta están excluidos de la lista blanca en el código, así que un agente que pida escribir un número de tarjeta recibe un rechazo en lugar de un campo.

¿Cambia algo si nunca uso un asistente de IA?

No. Todos los accesos a la API se comprueban antes de usarse. Un navegador que no la tenga muestra la web exactamente igual que antes, sin scripts adicionales, sin dependencias y sin ningún cambio en el proceso de reserva. Para quien no usa un agente, esta función no añade nada a la página.

¿Qué devuelve la herramienta de estado de vuelo?

Los mismos datos oficiales que muestra nuestra página de estado de vuelo: la situación de los sectores A, B y C según la autoridad de aviación civil, la hora en que se emitió esa situación y el amanecer y el atardecer del día. El agente los recibe como datos estructurados en lugar de leerlos de la página.

¿Lo está haciendo algún otro operador de globos?

Hasta el 10 de septiembre de 2026 no tenemos constancia de ningún otro operador de globos, ni en Capadocia ni fuera de ella, que exponga herramientas WebMCP. El estándar es un borrador publicado en agosto de 2026, así que el terreno es pequeño por definición, y preferimos que nos corrijan antes que exagerar.

¿Qué pasará con estas herramientas cuando termine la prueba de origen de Chrome?

Puede pasar una de tres cosas: que la API se publique, que cambie o que desaparezca. La prueba va de Chrome 149 a Chrome 156, y una web se apunta con un token ligado a su dominio. Si desaparece, borramos una cabecera y un hook, y ningún visitante nota nada distinto.