Un agente del navegador ve un botón y estima su posición. Eso puede funcionar. Pero una aplicación web también puede comunicar su significado de forma más explícita: esta acción busca citas disponibles, espera una fecha y devuelve una lista. Es precisamente este paso de la posición del clic a la herramienta descrita lo que hace interesante a WebMCP.
Según el estado documentado, WebMCP es una propuesta experimental. El documento explicativo actual trata el registro imperativo mediante JavaScript y document.modelContext. Las herramientas declarativas de formulario HTML se están explorando por separado y actualmente no forman parte de esta especificación. Por tanto, la página de resumen de Chrome con fecha del 18 de mayo de 2026 no es motivo para anunciar una nueva función universal del navegador en octubre.
Una herramienta empieza con una acción limitada
Nuestro propio ejemplo se llama «buscar citas disponibles». Su tarea termina con información. No crea ninguna reserva. La propia descripción ya debería dejarlo claro, para que un agente no convierta un resultado de búsqueda en una cita confirmada.
La entrada contiene una fecha y un servicio ofrecido. El resultado indica la misma referencia junto con las franjas horarias disponibles. Un valor aislado como «10:30» sería más débil: podría pertenecer a otro día o a otro servicio. Un resultado estructurado resulta especialmente útil cuando sus entradas pueden interpretarse sin ambigüedad.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Este es nuestro esquema didáctico, no un registro de WebMCP listo para copiar. La fecha futura y el servicio son inventados. Muestra el contrato que una implementación real tendría que especificar. Para la sintaxis concreta de la API, la referencia es la documentación experimental actual.
Los errores también necesitan un significado comprensible
Una fecha no válida, la ausencia de citas disponibles y un servicio al que no se puede acceder por motivos técnicos son tres resultados distintos. Si todos ellos simplemente producen una lista vacía, el agente tendría que adivinar la causa. Por eso, la respuesta de la herramienta debería incluir un estado comprensible y la información necesaria para la siguiente decisión.
Lo mismo se aplica a la información parcial. ¿Está completa la búsqueda o todavía faltan datos? ¿Corresponde la respuesta a la solicitud más reciente? ¿Ha cambiado la persona la fecha mientras tanto? Estas preguntas existen independientemente de si se accede a la interfaz mediante una captura de pantalla o a través de una herramienta.
Una descripción no es un permiso
Un esquema de entrada correcto indica qué forma debe tener una solicitud. No decide si quien llama puede leer esta información. La aplicación sigue teniendo que hacer cumplir sus propias reglas. Un nombre de herramienta que suene bien no es ni un inicio de sesión ni un control de acceso.
El paso a la reserva también necesita un significado propio. «Buscar horarios disponibles» y «resérvame este horario» tienen consecuencias distintas. No deberían fusionarse discretamente en una única función. Una reserva real tendría que tener en cuenta el elemento confirmado y la instrucción prevista.
Por tanto, para un primer ejercicio de diseño inofensivo, bastan unos datos de ejemplo fijos. Describe tres estados de respuesta y determina qué siguiente acción sería razonable en cada caso. Así puedes comprobar lo comprensible que es el contrato sin simular una reserva real ni un entorno de ejecución de WebMCP existente.
WebMCP no es automáticamente un servidor MCP remoto existente
La palabra MCP aparece en diversos contextos técnicos. Una acción descrita en el lado del navegador no es, solo por eso, el mismo tipo de conexión que un servidor de herramientas remoto accesible a través de HTTP. Para una conexión concreta, lo que cuenta es el cliente, el transporte, el inicio de sesión y las herramientas que realmente se ofrecen.
Por tanto, un acceso MCP remoto existente no demuestra que un sitio web admita WebMCP. Del mismo modo, una propuesta experimental de navegador no garantiza que cualquier agente pueda usarla ya. Esta distinción es práctica: evita que un nombre parecido conduzca a un plan de integración equivocado.
La pregunta trasladable sigue siendo clara. ¿Puede una aplicación expresar qué acción, con qué entradas, tiene qué resultado y qué efecto? Cuanto más precisa sea esta respuesta, menos tendrá que adivinar un agente a partir de una posición en la pantalla. Los buenos contratos de herramientas hacen más comprensible el margen de maniobra; no obstante, las reglas de la aplicación siguen siendo responsabilidad suya.
Fuentes y estado
Investigación y documentación a fecha de 25 de octubre de 2026. WebMCP · Documento explicativo de WebMCP.
