Durante décadas hemos diseñado sitios web bajo una premisa casi invisible: quien opera la página es una persona.
Por eso construimos menús, botones, buscadores, filtros, formularios, configuradores y carritos. Una persona observa la interfaz, interpreta sus opciones y decide dónde hacer clic.
Los agentes de inteligencia artificial introducen una segunda posibilidad. El cliente puede seguir siendo humano, pero parte del trabajo digital necesario para alcanzar su objetivo podría realizarlo su agente.
Eso plantea una pregunta empresarial más importante que simplemente “¿qué es WebMCP?”:
¿Cuándo existe suficiente valor entre expresar una intención y obtener un resultado válido como para justificar que una web exponga funciones directamente a agentes de IA?
La respuesta resulta especialmente interesante en comercio electrónico, productos personalizados y servicios configurables.
Y ya podemos observarla en una implementación real.
Zherpa.tech utiliza WebMCP para exponer capacidades de su aplicación a agentes: descubrir Capacidades Agentivas, formar un Crew, construir una hipótesis de ROI y preparar una solicitud de evaluación. El recorrido termina deliberadamente antes de producir un efecto externo: la persona debe revisar y confirmar el envío.
Ese caso permite estudiar algo que pronto podría ser relevante para muchas empresas: una web puede seguir teniendo interfaz para personas y, simultáneamente, desarrollar una superficie operativa para sus agentes.
¿Qué es WebMCP?
WebMCP es una API web que permite que una aplicación proporcione herramientas JavaScript a agentes de inteligencia artificial.
La especificación vigente al 17 de septiembre de 2026 describe estas herramientas como funciones de la aplicación con descripciones en lenguaje natural y esquemas estructurados que pueden ser invocados por agentes. También contempla que usuario y agente colaboren dentro de la misma interfaz web, reutilizando la lógica existente de la aplicación y compartiendo contexto.
Chrome lo explica de una manera particularmente sencilla: el sitio declara las acciones disponibles como herramientas; el navegador las presenta al agente; el agente proporciona argumentos estructurados y el código de la aplicación realiza el trabajo.
Esto introduce una diferencia importante frente a la automatización visual.
Supongamos que una tienda tiene un botón: Agregar al carrito.
Un agente que sólo observa la interfaz debe localizarlo, comprender qué representa, relacionarlo con determinado producto e interactuar correctamente con él.
Con WebMCP, la aplicación puede proporcionar directamente una herramienta estructurada equivalente.
El objetivo ya no es únicamente conseguir que el agente entienda la página. La propia aplicación puede explicarle qué puede hacer.
Web convencional frente a web preparada para agentes
Una web convencional expresa gran parte de sus posibilidades mediante elementos diseñados para personas. Una web con WebMCP puede conservar exactamente esa experiencia y añadir contratos estructurados para agentes.
| Web convencional | Web con WebMCP |
|---|---|
| La persona interpreta la interfaz | Persona y agente pueden participar |
| Las capacidades se manifiestan principalmente mediante UI | Determinadas capacidades también se declaran como tools |
| La automatización puede necesitar interpretar la interfaz | El agente recibe nombre, descripción y parámetros de la herramienta |
| La persona traduce su intención a filtros y formularios | El agente puede ayudar a convertir intención en parámetros |
| La UI conduce el recorrido | Tools y UI pueden compartir el mismo estado |
| Los clics expresan acciones | El agente puede invocar funciones estructuradas |
Esto no significa que WebMCP elimine la interfaz gráfica. La especificación habla precisamente de colaboración entre usuario y agente dentro de la misma experiencia. La diferencia es que la interfaz deja de ser necesariamente el único lenguaje operativo de la aplicación.
El caso más sencillo: comprar una playera
Consideremos una tienda convencional. El cliente quiere una playera negra talla M.
Puede buscar “playera”, seleccionar categoría, aplicar color, elegir talla, abrir una ficha y agregarla al carrito. El recorrido funciona razonablemente bien porque existen pocas variables.
Ahora cambiemos la solicitud:
“Quiero una playera negra talla M, de algodón, con este diseño centrado al frente, aproximadamente de 20 centímetros de ancho. No quiero gastar más de $500 y necesito recibirla antes del viernes.”
El problema ha cambiado. El cliente ya no busca únicamente un producto. Está intentando construir una configuración válida.
La tienda debe resolver modelos disponibles, tallas, colores, material, zona imprimible, dimensiones máximas, compatibilidad de la técnica de impresión, precio, inventario, producción y fecha de entrega.
El cliente conoce bastante bien lo que quiere conseguir. Pero no necesariamente conoce todos los parámetros que el sistema necesita para vendérselo.
Éste es precisamente el tipo de distancia donde una interfaz agentiva podría resultar valiosa.
¿Cómo sería una tienda WebMCP?
Una tienda podría mantener su e-commerce convencional y exponer adicionalmente herramientas para agentes. Conceptualmente podrían existir funciones como search_products, get_customization_options, validate_design, calculate_price, check_delivery, create_preview y add_to_cart.
Estos nombres son ilustrativos; no pertenecen al contrato de Zherpa.tech ni pretendemos presentarlos como herramientas obligatorias de WebMCP.
El agente podría convertir la petición humana en parámetros y consultar las reglas reales de la tienda. Quizá descubra que la playera elegida sólo admite un estampado frontal de 18 centímetros. En lugar de inventar una solución, podría comunicar que puede reducir el diseño o buscar otro modelo que permita 20 centímetros.
La IA interpreta la intención. El negocio conserva la autoridad sobre lo que realmente puede fabricar, entregar y vender.
Zherpa.tech: el mismo patrón, implementado realmente
La hipótesis de la playera puede parecer futurista. Pero el patrón ya puede observarse en Zherpa.tech.
La implementación WebMCP V16.2 dispone de herramientas reales que permiten a un agente recorrer progresivamente una experiencia comercial:
Necesidad → descubrir capacidades → formar Crew → calcular ROI → preparar evaluación → confirmación humana.
1. discover_agent_capabilities
La primera herramienta recibe una necesidad empresarial. Su inputSchema admite business_need, business_area, desired_outcome, constraints y max_results.
La herramienta busca exclusivamente dentro del catálogo público vigente de Zherpa y devuelve las Capacidades Agentivas potencialmente relacionadas. Cada coincidencia puede incluir nombre, área, trabajo, resumen, sistemas, lo que puede hacer, lo que no puede hacer, precio mensual, precio anual y relevancia.
No crea capacidades inexistentes ni promete resultados. Además, está marcada como lectura, no produce consecuencias externas y pertenece a Clase A.
El agente interpreta la necesidad, pero Zherpa.tech conserva la fuente de verdad sobre qué existe realmente en el catálogo.
De “tengo un problema” a una capacidad concreta
Imaginemos que un director comercial dice a su agente:
“Tenemos oportunidades que se enfrían porque los vendedores no mantienen actualizado el siguiente paso. Quiero saber si Zherpa tiene alguna capacidad que pueda ayudar y cuánto costaría.”
El agente puede expresar esa necesidad mediante discover_agent_capabilities. No tiene que inventar qué vende Zherpa. Tampoco tiene que limitarse a inferirlo leyendo páginas. La herramienta devuelve únicamente capacidades del catálogo real.
Supongamos que entre las coincidencias aparece seguimiento-comercial. El usuario podría entonces decir: “Agrégala a mi Crew.”
2. build_crew
build_crew permite consultar o modificar el Crew visible en la página. Admite las acciones get, set, add, remove y clear.
Sólo acepta IDs reales del catálogo y permite hasta 13 capacidades. Cuando modifica el Crew, el cambio también aparece en la interfaz para que la persona pueda verlo.
Además, la respuesta proporciona la composición del Crew y su información económica: inversión, descuentos y ahorros correspondientes a la configuración.
Aquí aparece una propiedad importante de WebMCP: agente e interfaz humana no necesitan vivir en mundos separados.
Ahora viene la pregunta empresarial: ¿vale lo que cuesta?
El director podría continuar: “Antes de solicitar una evaluación quiero saber si económicamente tiene sentido.”
3. calculate_roi
calculate_roi construye una hipótesis de costo-beneficio para una o hasta tres capacidades utilizando la misma lógica de la calculadora visible.
No basta con pedirle al modelo: “Invéntame un ROI.” La herramienta exige datos económicos correspondientes a las capacidades evaluadas.
Para seguimiento-comercial, por ejemplo, uno de los drivers admite conjuntamente variables como lost_deals_followup, recoverable_deal_pct, avg_deal_ticket y deal_margin_pct. Otro puede utilizar oportunidades sin siguiente paso, minutos necesarios para revisarlas y costo horario del responsable comercial.
Si falta información necesaria, la herramienta devuelve status: "needs_input" y especifica los datos faltantes.
Cuando existen suficientes variables, devuelve la hipótesis calculada, que puede incluir fuga económica mensual, valor recuperable, inversión equivalente, beneficio neto, ROI, relación beneficio/costo, break-even y otros resultados según el caso.
Y conserva una frontera esencial: la estimación es una hipótesis, no una garantía de retorno.
Aquí empieza a aparecer el caso de negocio de WebMCP
El usuario comenzó con lenguaje empresarial: “Mis vendedores dejan enfriar oportunidades.” El agente ayudó a traducir esa intención.
Pero no inventó el catálogo, la capacidad, sus restricciones, el precio, la configuración del Crew, las reglas económicas ni las variables necesarias para calcular ROI.
Humano expresa intención → agente interpreta → herramientas consultan reglas reales → aplicación calcula → humano evalúa.
Comparemos con la playera:
Humano expresa intención → agente interpreta → tienda consulta catálogo y restricciones → aplicación valida configuración y precio → humano evalúa.
La estructura es sorprendentemente similar.
Personalización: donde el valor potencial aumenta
Esto nos conduce a nuestra principal hipótesis empresarial.
WebMCP podría resultar especialmente valioso cuando existe una distancia considerable entre lo que el cliente sabe pedir y los parámetros necesarios para producir una transacción válida.
Un producto estándar tiene poca distancia: “Quiero este libro.”
Una configuración tiene más: “Quiero una laptop con suficiente memoria para estas cargas de trabajo, menos de cierto presupuesto y entrega esta semana.”
Una personalización puede tener todavía más: “Quiero esta playera con este diseño, estas dimensiones, este material y esta fecha de entrega.”
Y determinados servicios B2B presentan una distancia comparable: “Tengo este problema comercial, estas restricciones, estos sistemas y este objetivo. ¿Qué combinación necesito y económicamente tiene sentido?”
La hipótesis no es que WebMCP genere automáticamente más ventas. No encontramos evidencia suficiente para sostener esa afirmación.
La hipótesis es que puede reducir trabajo de traducción y configuración entre intención y resultado. Eso sí puede probarse.
Entonces, ¿cuándo se justifica implementar WebMCP?
Chrome recomienda comenzar por el recorrido del usuario: identificar qué objetivos quiere completar, dónde existe trabajo tedioso y en qué puntos una herramienta puede ayudar. No existe una lista universal de tools que todos los sitios deban implementar.
Desde una perspectiva empresarial proponemos evaluar cinco condiciones: que exista una tarea y no sólo información; que exista fricción entre intención y ejecución; que la empresa pueda definir una fuente de verdad; que las acciones puedan delimitarse por permisos, reversibilidad y consecuencias; y que exista algo que podamos medir.
Si no podemos demostrar que el recorrido mejora alguna métrica relevante, WebMCP corre el riesgo de convertirse en otra implementación tecnológica buscando un problema.
Qué medir
Una prueba empresarial debería comparar el recorrido convencional contra el recorrido asistido.
Tiempo hasta resultado válido: desde la intención inicial hasta una configuración que realmente pueda ejecutarse o comprarse.
Número de interacciones: cuántos pasos necesita el usuario.
Errores de configuración: cuántas combinaciones terminan siendo inválidas.
Correcciones humanas: con qué frecuencia el usuario debe corregir la interpretación del agente.
Abandono: dónde se interrumpe el proceso.
Conversión: cuando corresponda, cuántas configuraciones válidas terminan en una transacción.
Incidentes agentivos: intentos de ejecutar acciones incorrectas, fuera de alcance o sin autorización.
Sólo después de medir esas variables tendría sentido afirmar que existe retorno.
La autonomía no tiene por qué ser binaria
Uno de los aspectos más interesantes de Zherpa.tech V16.2 es precisamente lo que no permite hacer automáticamente.
4. request_evaluation
Esta herramienta prepara una solicitud de evaluación utilizando información de contacto, necesidad y, cuando corresponde, Crew, ROI y capacidad personalizada.
Pero no la envía.
Su resultado establece status: "awaiting_human_confirmation", submitted: false y review_required: true.
La solicitud queda preparada en la interfaz. Sólo después de una acción humana explícita se produce el envío hacia Zoho CRM. La implementación clasifica este punto como Clase B, Human-in-the-Loop, y prohíbe el envío automático.
Esto demuestra que preparar una web para agentes no obliga a escoger entre “la IA sólo recomienda” y “la IA puede hacer cualquier cosa”. Podemos diseñar diferentes grados de autonomía según las consecuencias.
Leer, configurar, calcular, preparar, confirmar
El recorrido de Zherpa.tech permite visualizarlo: descubrir una capacidad es lectura, Clase A; modificar el Crew cambia estado local y es reversible, Clase A; calcular ROI es simulación reversible, Clase A; preparar evaluación involucra datos y prepara una acción externa, Clase B; enviar requiere acción humana.
Esta separación es especialmente relevante para comercio electrónico.
Una tienda podría permitir que el agente busque → compare → personalice → valide → calcule → prepare carrito sin concederle automáticamente autoridad para comprar → pagar → aceptar condiciones.
La autonomía puede aumentar progresivamente con la reversibilidad y el riesgo de cada acción.
WebMCP no elimina los riesgos de los agentes
Convertir funciones de negocio en herramientas también crea superficie de riesgo.
Chrome advierte expresamente sobre la inyección indirecta de instrucciones: contenido malicioso que intenta alterar el comportamiento del agente. También recomienda utilizar anotaciones como untrustedContentHint, readOnlyHint y consequentialHint para ayudar a agentes y navegadores a interpretar las propiedades de una herramienta.
Zherpa.tech utiliza algunas de ellas en su contrato real. discover_agent_capabilities, por ejemplo, está marcado como lectura y no consecuencial. describe_custom_capability y request_evaluation identifican contenido no confiable porque procesan información proporcionada por el usuario.
Pero existe una distinción importante: la seguridad no se resuelve simplemente agregando annotations. Las herramientas deben diseñarse alrededor de permisos, validación, datos, consecuencias y fronteras operativas.
Un matiz técnico importante: WebMCP todavía está evolucionando
WebMCP no debe presentarse como una infraestructura universal y terminada.
La especificación del 17 de septiembre de 2026 es un Draft Community Group Report y señala explícitamente que no constituye un estándar W3C ni está actualmente en el Standards Track.
Chrome continúa presentando su implementación dentro de un Origin Trial / Intent to Experiment. Esto importa para cualquier decisión empresarial.
Existe suficiente tecnología para experimentar y construir. Todavía no existe suficiente madurez para asumir compatibilidad universal, adopción masiva o retorno comercial demostrado.
Zherpa.tech como implementación temprana
Zherpa.tech V16.2 utiliza document.modelContext como API WebMCP autoritativa y conserva navigator.modelContext como alias de compatibilidad heredada cuando corresponde. La implementación combina una herramienta declarativa con herramientas imperativas.
También publica mecanismos propios de descubrimiento y auditoría mediante /.well-known/webmcp, /webmcp-tools.json y /llms.txt.
Aquí es importante no confundir implementación propia con especificación: el registro de Zherpa declara expresamente que la forma de esos artefactos es una decisión de descubrimiento y auditoría de Zherpa y no se presenta como parte estandarizada de WebMCP.
Otro detalle técnico que conviene preservar: la implementación V16.2 declara inputSchema, annotations y funciones de ejecución para sus tools imperativas, pero no declara actualmente un outputSchema formal. Los resultados descritos son contratos efectivos producidos por los handlers.
De e-commerce a intent commerce
La tienda de playeras nos permite regresar a la pregunta original.
Durante años hemos optimizado: página → producto → clic → carrito → conversión.
Los agentes podrían añadir otro recorrido: intención → restricciones → configuración válida → autorización → transacción.
Podríamos llamarlo agent commerce. Pero quizá haya una descripción todavía más precisa: intent commerce.
El punto de partida ya no es necesariamente “quiero navegar este catálogo”. Puede ser: “Esto es lo que necesito conseguir.”
El agente ayuda a interpretar esa intención. Las herramientas del negocio determinan qué es realmente posible. La aplicación valida reglas y calcula consecuencias. La persona conserva la capacidad de revisar y decidir donde corresponde.
La pregunta empresarial correcta
Por eso, la pregunta para un director no debería ser: “¿Debemos poner WebMCP en nuestra página?”
Debería ser: “¿Cuánto trabajo existe entre lo que nuestro cliente quiere y una configuración válida que nuestro negocio puede entregar?”
Si la respuesta es “muy poco”, quizá una interfaz convencional sea suficiente.
Si la respuesta involucra múltiples variables, reglas, comparaciones, restricciones, cálculos y decisiones, puede existir un caso interesante para experimentar con agentes.
Y entonces aparece una segunda pregunta: “¿Qué partes de ese recorrido puede ejecutar un agente de forma reversible y cuáles deben permanecer bajo autorización humana?”
Zherpa.tech ofrece ya una respuesta concreta a esa arquitectura:
Necesidad → discover_agent_capabilities → build_crew → calculate_roi → request_evaluation → revisión humana → confirmación → efecto externo.
No demuestra todavía que WebMCP vaya a aumentar ventas. Tampoco demuestra que todas las webs deban implementarlo.
Demuestra algo más acotado y, por ahora, más útil: una aplicación web puede convertir funciones reales del negocio en herramientas estructuradas para agentes sin entregarles necesariamente la decisión final.
La siguiente etapa ya no consiste en demostrar que técnicamente se puede. Consiste en medir si hacerlo crea suficiente valor.
Fuentes
- WebMCP Specification, Web Machine Learning Community Group, Draft Community Group Report, 17 de septiembre de 2026.
- Chrome for Developers — WebMCP Imperative API.
- Chrome for Developers — WebMCP Tool Security.
- Chrome for Developers — Build your user’s agentic workflows with WebMCP tools.
- Zherpa.tech — Contrato real WebMCP V16.2, 22 de septiembre de 2026.
