Servidores Guías
En esta página
Básico Lección 16 de 17 ≈ 30 min de lectura
Especificación 2026-07-28
WebMCP: tu web como herramienta
Especificación MCP 2026-07-28 · revisada el 2 de octubre de 2026
WebMCP deja que una página registre herramientas para el agente del navegador. Qué exponer de tu web y qué no, cómo describirlo, cómo se prueba y en qué navegadores funciona hoy.
Qué aprenderás
- Distinguir WebMCP de un servidor MCP remoto por dónde corre, quién es el agente y qué sesión usa, y decidir cuándo conviene cada uno
- Decidir qué partes de una web se exponen como herramientas, cuáles no y cuáles dejan el último paso a la persona
- Escribir una herramienta WebMCP con nombre, descripción y esquema que el agente entienda, y retirarla cuando cambia el estado de la página
- Probarla con el soporte real de los navegadores sin romper la página donde la API no existe
Contenido de la lección
- 01 El problema
- 02 Dos maneras de abrir tu producto a un agente
- 03 Qué exponer y qué no
- 04 Una herramienta bien descrita
- 05 Probarlo hoy
- 06 Lo que hicimos en desarrollomcp.com
- 07 En producción
Además: quiz de comprobación y desafío práctico.
Extracto
Nortia tiene un portal de clientes en portal.nortia.example. Las empresas que le contratan envíos entran allí para seguir sus pedidos, descargar facturas y abrir incidencias de entrega. Cada vez más responsables de compras lo hacen con un agente del navegador al lado. Le preguntan dónde está el PED-2026-004812, y el agente busca el botón, lo pulsa y lee la pantalla.
La ingeniera de plataforma quiere que esos agentes dejen de adivinar. Le pide a un asistente de código que exponga el portal con WebMCP y, en una tarde, tiene una herramienta por cada botón. Son veintitrés, entre ellas pagar_factura, cambiar_contrasena y exportar_envios, que devuelve todos los envíos del año con el nombre y el teléfono de cada destinatario.
Fin del extracto · la lección sigue con 6 secciones más
Artículos relacionados
Preguntas frecuentes
¿En qué se diferencia WebMCP de un servidor MCP remoto?
Un servidor MCP remoto vive en tu infraestructura, lo conecta cualquier cliente MCP (un chat, un editor o un proceso) y cada petición llega con un token emitido para ese cliente. Con WebMCP es la propia página la que registra sus herramientas en document.modelContext, que solo existen mientras la pestaña está abierta; las usa el agente del navegador y se ejecutan con la sesión de la persona que tiene la página delante. WebMCP comparte el vocabulario de MCP (nombre, descripción, esquema, anotaciones), pero no tiene JSON-RPC, resources ni prompts. Si el agente trabaja con la persona dentro de tu web, encaja WebMCP; si trabaja fuera del navegador, hace falta un servidor remoto, y una web puede tener los dos.
¿Qué partes de una web no conviene exponer como herramientas WebMCP?
Todo lo que la persona no pueda hacer ya desde la interfaz, y además lo que toca credenciales, pagos o permisos de otras personas: iniciar o cerrar sesión, cambiar la contraseña, pagar, gestionar usuarios de la cuenta o exportar datos personales de terceros. La herramienta hereda la sesión de quien tiene la pestaña abierta, así que un agente engañado por un texto de la página podría usarla. Lo que tiene efecto y no se deshace se prepara (por ejemplo, rellenar un formulario) y lo confirma la persona. Las anotaciones como consequentialHint son pistas: no obligan a ningún agente a pedir confirmación.
¿Cómo se prueba WebMCP si casi ningún navegador lo trae activado?
En local, con el flag de Chrome #enable-webmcp-testing, y en las pruebas automáticas lanzando Chrome con --enable-features=WebMCP desde Playwright y simulando al agente con el dominio WebMCP del protocolo de DevTools, que lista, invoca y cancela herramientas. Conviene fijar la versión de Chrome, porque la API ha cambiado entre versiones. Para usuarios reales de Chrome y Edge hace falta registrar el origen en el origin trial. Y donde la API no existe, como en Firefox o Safari, la página debe funcionar igual: se detecta el soporte y, si no lo hay, no se registra nada.