Del descubrimiento a la usabilidad: lo que el WebMCP cambia para quien hace sitios web

Durante treinta años la pregunta fue si el buscador lograba leer tu página. La pregunta que se abre ahora es si un agente logra usar tu sitio.

Qué es el WebMCP, en una frase

El WebMCP es una propuesta de API de navegador que permite a una página declarar sus propias funcionalidades como herramientas que un agente puede llamar. En lugar de simular clics y llenados en la interfaz, el agente ejecuta la tarea llamando funciones y formularios que la página expone con un esquema declarado. La propuesta está en desarrollo en un grupo comunitario y todavía no es un estándar implementado en los navegadores.

El desplazamiento que representa el WebMCP

La lectura más común sobre los agentes es que van a navegar solos por interfaces hechas para personas, haciendo clic y llenando campos por imitación. Ese enfoque funciona en una demo y falla a escala, porque depende de un diseño estable y de interpretación visual. Quien ya vio un rediseño romper todos los scripts de prueba de la empresa sabe cómo termina esa película. Estos agentes llegan al sitio como una categoría más de bot, y la decisión sobre cuáles dejar entrar está en la guía de bots de IA.

La propuesta del WebMCP invierte la responsabilidad. El sitio declara lo que sabe hacer, con un contrato explícito de entrada y salida, y el agente llama esa función. Para quien construye sitios, esto acerca el trabajo de front-end a la disciplina de diseñar una API pública. En el comercio, ese contrato explícito ya tiene protocolos propios, descritos en comercio agéntico en el e-commerce.

La diferencia entre WebMCP y MCP

El nombre parecido causa confusión con el Model Context Protocol, el MCP, que conecta asistentes con servidores de datos y de herramientas. En el MCP, alguien mantiene un servidor fuera del navegador, y el asistente se conecta a él para consultar un sistema, como una base de clientes o una plataforma de datos. En el WebMCP, la página abierta en el navegador declara sus propias herramientas, y el agente que opera en ese navegador las encuentra ahí, dentro de la sesión de quien está usando el sitio.

La consecuencia para quien hace sitios es de responsabilidad. Con MCP, la integración es un proyecto de back-end, con acceso y permisos definidos en el servidor. Con WebMCP, la herramienta vive en el front-end y hereda el contexto de la página, incluida la sesión de la persona logueada, lo que convierte la elección de qué exponer en una decisión de producto y de seguridad al mismo tiempo.

Lo que el WebMCP cambia en el trabajo de SEO técnico

• Inventario de capacidades. Antes de exponer cualquier cosa, hay que responder qué hace de verdad el sitio: consultar disponibilidad, calcular el envío, agendar, comparar planes, ubicar una sucursal. Ese inventario rara vez existe por escrito.
• Nombre y descripción. Cada herramienta necesita un nombre y una descripción en lenguaje natural que un modelo entienda sin ambigüedad. Es trabajo semántico aplicado a funciones, con el mismo rigor que hoy se aplica a títulos y encabezados.
• Frontera de seguridad. Exponer una función es distinto de exponer contenido. Alcance, autenticación y límites de acción tienen que decidirse antes de la implementación.
• Los formularios vuelven al centro. La propuesta trata los elementos de formulario como candidatos naturales a herramienta, lo que valoriza el marcado semántico correcto en un lugar donde muchos sitios acumularon deuda técnica durante años.

Lo que todavía no haría con el WebMCP

Reescribir la arquitectura de un sitio en función de una especificación en desarrollo es un riesgo sin retorno proporcional. Las cuestiones abiertas que lista el propio repositorio afectan decisiones estructurales, y una implementación hecha ahora probablemente tendrá que rehacerse.