LLMs en el navegador + WebMCP + MCP UI: el stack frontend que viene

Tres iniciativas de estandarización independientes llegaron con pocos meses de diferencia y, juntas, están redibujando el mapa del frontend:

1. El navegador adquirió un cerebro. Chrome 148 estabilizó la Prompt API: ahora cualquier sitio web puede enviar prompts a un modelo Gemini Nano que se ejecuta en el dispositivo, con entradas de texto, imagen y audio, salida estructurada según JSON schema y streaming.
2. Las páginas aprendieron a ofrecer manos. WebMCP entró en origin trial en Chrome 149 y permite que una página web registre herramientas tipadas (checkout, filter_results, submit_application) que los agentes del navegador pueden descubrir e invocar en lugar de hacer clics a ciegas por el DOM.
3. Los resultados de las herramientas adquirieron un rostro. MCP Apps (SEP-1865, Final) estandarizó cómo una herramienta MCP distribuye un recurso de interfaz interactiva que se renderiza dentro de un sandbox en los hosts de agentes.

Razonamiento, ejecución de acciones, presentación: las tres capas están llegando a la plataforma web al mismo tiempo. Mi opinión: la aplicación frontend de los próximos años es una página que piensa localmente, expone herramientas de forma declarativa y renderiza los resultados del agente como superficies estructuradas en lugar de párrafos de chat.

Escrito con base en el estado de la plataforma en septiembre de 2026. Las afirmaciones vinculadas a versiones específicas lo indican en el texto; ante la duda, consulta Chrome Status antes de construir.

En resumen

• La IA integrada de Chrome ya tiene forma de producto listo para producción: Summarizer, Translator y Language Detector son estables desde Chrome 138, y la Prompt API se estabilizó en Chrome 148 con entrada multimodal y salida restringida por JSON schema.
• WebMCP (origin trial en Chrome 149–156, con el objetivo de estabilizarse en 157) permite que las páginas registren herramientas invocables por agentes mediante una API imperativa de JS o anotaciones declarativas en formularios HTML, sujetas al aislamiento de origen y a una Permissions Policy de tools.
• MCP Apps vincula herramientas con recursos HTML ui:// aislados mediante _meta.ui.resourceUri; A2UI v0.9.1 cubre el caso complementario de JSON declarativo para agentes no confiables o multiplataforma.
• La inferencia en el navegador es lo suficientemente rápida para una UX real en equipos de escritorio: las cifras publicadas de WebLLM muestran ~41–71 tok/s en un M3 Max (aproximadamente el 80% del rendimiento nativo), ~62 tok/s en una RTX 3060 y ~15 tok/s en una Intel Iris Xe, frente a ~4–9 tok/s en teléfonos de gama alta. La variación entre dispositivos es grande, así que mide en las máquinas de tus usuarios, no en la del autor del blog.
• El patrón práctico hoy: detecta la disponibilidad de la IA integrada, registra 3–5 herramientas WebMCP de alto valor, renderiza los resultados como tarjetas estructuradas y conserva un LLM de servidor como alternativa. Pruébalo con un conjunto de evals de tareas de referencia, no por intuición.
• Este artículo es el complemento centrado en el navegador de Del chat a la interfaz de agentes e Infraestructura preparada para agentes: aquellos cubrieron el lado del servidor; este cubre lo que ocurre dentro de la pestaña del navegador.

Qué aprenderás aquí

• Qué pueden y qué no pueden hacer hoy las APIs de IA integrada de Chrome, y qué hardware requieren
• Qué es WebMCP, cómo funcionan las APIs imperativa y declarativa, y cómo registrar tu primera herramienta
• Cómo MCP Apps y A2UI abordan el problema de la «interfaz para resultados de herramientas», y cuál elegir
• Cómo se combinan las tres capas en un entorno de ejecución de agentes nativo del navegador
• Cómo construir un copiloto integrado: un panel de chat en tiempo de ejecución respaldado por el LLM del navegador y las herramientas de la página
• Qué dicen los benchmarks sobre la inferencia en el navegador tanto en escritorio como en dispositivos móviles, y cómo evaluar modelos con tus tareas
• Una guía para decidir qué construir ahora y qué conviene esperar

Por qué el navegador se está convirtiendo en un entorno de ejecución de agentes

Tomemos distancia y observemos lo que llegó:

Cada capa es útil por sí sola. Juntas cierran un ciclo que antes requería una ida y vuelta al servidor, una clave de API y un frontend hecho a medida: la página proporciona contexto y herramientas, el navegador proporciona el modelo y el resultado se renderiza como una interfaz con la que el usuario puede interactuar.

WebMCP reemplaza la ejecución de acciones mediante la simulación de clics y pulsaciones de teclas como si el agente fuera una persona. En vez de revisar cada elemento para adivinar su propósito, el agente lee el propósito que tu sitio declara. Menos pasos, menos interpretación, más confiabilidad. Y como las herramientas se ejecutan de forma visible en la página, los usuarios conservan la confianza y las marcas conservan su diseño.

También es una cuestión de privacidad y costos. La generación de resúmenes, la clasificación, la reescritura y la asistencia para llenar formularios ahora pueden ejecutarse por completo en el dispositivo: sin facturación por tokens, sin que el texto salga de la máquina y sin viajes de ida y vuelta por la red después del calentamiento. El LLM del servidor pasa a ser la alternativa para el razonamiento complejo, no la opción predeterminada para todo.

Capa 1: LLMs en el navegador — el modelo dentro de la pestaña

La IA integrada de Chrome: dos tipos de API

Chrome ofrece dos variantes, y elegir la adecuada importa:

Las APIs de tareas son específicas, tienen un comportamiento predefinido y son estables. Summarizer, Translator y Language Detector son estables desde Chrome 138 (anunciadas en Google I/O 2025). Writer, Rewriter y Proofreader siguen en developer trial. Úsalas cuando tu tarea coincida exactamente con su propósito: están ajustadas para ese trabajo y ofrecen la integración más sencilla:

// Summarizer API — stable since Chrome 138
// Requires HTTPS + transient user activation (a click) for create()
const availability = await Summarizer.availability();
if (availability === "available") {
  const summarizer = await Summarizer.create({
    type: "tldr",
    length: "short",
    format: "markdown",
    outputLanguage: "en-US",
  });
  const summary = await summarizer.summarize(longArticleText);
}

La Prompt API es la alternativa de propósito general: acceso directo al modelo Gemini Nano en el dispositivo con tu propio system prompt, entrada multimodal (texto, imagen, audio), salida estructurada mediante JSON schema o expresiones regulares, streaming y controles de muestreo (temperature/topK en extensiones; un enum samplingMode en el origin trial para la web). Se estabilizó para la web en Chrome 148 después de un origin trial que abarcó Chrome 139–147.

// Prompt API — stable since Chrome 148
// The model downloads on first use; LanguageModel.availability() tells you the state
const availability = await LanguageModel.availability();
if (availability === "available") {
  const session = await LanguageModel.create({
    initialPrompts: [
      { role: "system", content: "You extract action items as JSON." },
    ],
  });
  const schema = {
    type: "object",
    properties: { items: { type: "array", items: { type: "string" } } },
    required: ["items"],
  };
  for await (const chunk of session.promptStreaming(notes, {
    responseConstraint: schema,
  })) {
    renderPartial(chunk); // stream into your UI
  }
}

Algunos requisitos estrictos que debes tener en cuenta al diseñar (de la documentación de Summarizer, aplicables a todas las APIs de modelos fundacionales):

• Sistema operativo: Windows 10/11, macOS 13+, Linux o Chromebook Plus. No Android, no iOS ni Chromebooks que no sean Plus.
• Disco: al menos 22 GB libres en el volumen del perfil de Chrome.
• Memoria: estrictamente más de 4 GB de VRAM para GPU, o 16 GB de RAM + 4 núcleos de CPU para CPU. (La entrada de audio en la Prompt API requiere una GPU).
• Contexto: contexto seguro (HTTPS), ventana de nivel superior o iframe del mismo origen salvo que se delegue el permiso, y activación transitoria del usuario para create().
• El modelo se descarga por separado en el primer uso: contempla una descarga inicial grande y muestra el progreso.

Fíjate en la claridad de la entrada de Chrome Status: el modelo en el dispositivo «nunca se entrena con datos locales específicos del usuario ni tiene acceso a ellos». El contexto de tu página solo llega al modelo a través de lo que incluyes en el prompt. Eso es una ventaja para las revisiones de privacidad.

La alternativa portable: WebLLM y Transformers.js

Las APIs de Chrome solo funcionan en Chrome. Si necesitas Firefox, Safari o un modelo que Chrome no incluye, la alternativa abierta es WebLLM (mlc-ai/web-llm): un motor JavaScript de código abierto que ejecuta modelos abiertos cuantizados a 4 bits (familias Llama, Phi, Qwen, Mistral) en WebGPU, con una API de chat compatible con OpenAI. Su alternativa hermana Transformers.js (Hugging Face) cubre el mismo terreno con un catálogo de modelos más amplio y backends WebGPU/WebAssembly.

La disyuntiva es clara:

• IA integrada: no necesitas alojar modelos, el navegador gestiona las descargas y actualizaciones, y el rendimiento está optimizado de forma nativa; pero solo funciona en Chrome, ofrece una sola familia de modelos y exige hardware compatible.
• WebLLM / Transformers.js: cualquier navegador Chromium o, próximamente, Firefox con WebGPU, y cualquier modelo abierto compatible; pero debes distribuir desde megabytes hasta gigabytes de pesos, administrar la caché y asumir el costo de compilación de shaders en la primera ejecución.

Cobertura de WebGPU en septiembre de 2026: Chrome/Edge 113+ en escritorio, Chrome para Android 121+ en Android 12+ (primero GPUs Qualcomm/ARM, con más fabricantes incorporándose durante 2026), Safari 26+ en macOS Tahoe e iOS 26 con WebGPU activado por defecto, y soporte en Firefox en camino, aunque más lento (estado de implementación). La brecha ya no es de soporte, sino de capacidad: las GPUs móviles ejecutan modelos pequeños lentamente y a veces fallan con los grandes. Trata la inferencia en el navegador como universal, pero por niveles: el mismo camino de código, con límites muy distintos.

Qué dicen realmente los benchmarks

Estas cifras vienen con una advertencia: la velocidad de inferencia en el navegador depende de la GPU, el controlador, el estado térmico y la cuantización. Úsalas como orientación aproximada y después mide en tu propio hardware:

Esta tabla esconde tres lecciones:

1. El navegador conserva ~70–80% del rendimiento nativo. El costo de WebGPU es real, pero moderado: ejecutar modelos en el navegador es viable, no solo una demostración llamativa.

2. Lo que importa es el límite inferior. 15 tok/s en gráficos integrados de Intel son suficientes para resumir en segundo plano, pero inutilizables para un asistente de escritura en tiempo real. Diseña una UX de streaming que se degrade de forma gradual.

3. El escalamiento no es lineal y a veces se invierte. Que una 4090 obtenga un resultado inferior al de una 4050 con el mismo modelo y la misma versión del navegador es la mejor razón para hacer benchmarks en hardware representativo en vez de confiar en las especificaciones. Posibles causas: estado de la caché de shaders, política de energía y madurez del backend de WebGPU. Lee el hilo del issue antes de construir una página de benchmarks.

4. Un dispositivo móvil es una computadora distinta, no una versión más lenta de una de escritorio. Los teléfonos de gama alta decodifican a ~4–9 tok/s: sirven para resumir en segundo plano, no para asistentes en tiempo real. Los modos de falla son propios de los dispositivos móviles: WebLLM restringe estrictamente los modelos grandes en Android mediante una heurística basada en maxStorageBufferBindingSize porque las pestañas fallan al superar ese límite; un iPhone 11 Pro Max puede informar webgpu: true con soporte f16 y aun así no completar ninguna ejecución de inferencia; y un prompt de 1200 tokens puede tardar 76 segundos en producir el primer token, mientras que uno de 52 tokens tarda menos de 4. En dispositivos móviles, haz benchmarks: nunca te limites a detectar funcionalidades.

También contempla el arranque en frío: cargar el modelo desde la caché tarda 2–6 segundos según el hardware, y la primera inferencia después de la carga tarda 2–3× más mientras WebGPU compila los shaders. Carga el modelo en un Web Worker, inicia la carga de forma anticipada y ejecuta una inferencia de calentamiento descartable detrás de la pantalla de carga.

Capa 2: WebMCP — páginas que exponen herramientas

Qué es y en qué estado se encuentra

WebMCP es una propuesta de estándar web (incubada en el W3C Web Machine Learning Community Group; todavía no forma parte del proceso formal de estandarización) que permite que una página registre herramientas invocables por agentes de IA basados en el navegador. El cronograma de Chrome: dev trial en 146, origin trial 149–156 (escritorio, Android y WebView), con el objetivo de estabilizarse en 157. Para desarrollo local, activa chrome://flags/#enable-webmcp-testing.

Un detalle importante que destaca el documento explicativo: pese a su nombre, WebMCP no exige el formato de comunicación de MCP. El navegador puede presentar las herramientas de la página a su agente mediante MCP, function calling propietario o cualquier otro mecanismo. WebMCP es el contrato entre la página y el navegador; lo que ocurre detrás es asunto del navegador.

Dos APIs: imperativa y declarativa

La API imperativa es JavaScript convencional sobre navigator.modelContext. Registras herramientas con un nombre, una descripción comprensible para personas y agentes, una entrada definida con JSON schema y un handler execute que reutiliza tu lógica frontend existente. Una advertencia: la forma de la API todavía estaba cambiando a principios de 2026. Las operaciones por lote provideContext/clearContext se eliminaron alrededor de marzo de 2026 en favor del registro individual, así que verifica el documento explicativo antes de lanzar.

// Illustrative — verify the exact shape against the current explainer
if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "searchProducts",
    description:
      "Search the product catalog by keyword. Returns matching products with name, price, and availability.",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string", description: "Search keywords" },
        category: {
          type: "string",
          enum: ["all", "clothing", "electronics", "books"],
        },
      },
      required: ["query"],
    },
    execute: async (input) => {
      // Reuse the same store your UI already uses
      const results = await productStore.search(input.query, input.category);
      return { products: results, total: results.length };
    },
    annotations: { readOnlyHint: true },
  });
} else {
  console.debug("[webmcp] not supported — page still works for humans");
}

La API declarativa agrega anotaciones a formularios HTML normales para que los agentes sepan cómo llenarlos y enviarlos, sin necesidad de JavaScript. Prueba la demo de Le Petit Bistro para esta opción, o las demos imperativas (zaMaker, un ejemplo de reservas de viajes con React), cuyo código fuente está enlazado desde la documentación. Angular también tiene soporte experimental.

El modelo de seguridad, en un párrafo

WebMCP tiene dos controles de acceso: aislamiento de origen (no está disponible en documentos que flexibilizan document.domain / Origin-Agent-Cluster: ?0) y la Permissions Policy de tools (por defecto es self; los iframes de otros orígenes necesitan allow="tools"). Las acciones sensibles deben solicitar confirmación al usuario, y toda la API está diseñada para flujos locales con una persona en el ciclo, no para scraping headless: puede que funcione en modo headless, pero ese no es el objetivo principal del diseño. Lee las recomendaciones de seguridad para herramientas enlazadas desde la documentación antes de exponer cualquier acción que gaste dinero o modifique el estado.

Las limitaciones reales

La documentación de Chrome menciona tres, y las tres influyen en tu arquitectura:

1. El descubrimiento requiere una visita. Los navegadores deben navegar a tu página y ejecutar JS para conocer tus herramientas. El descubrimiento basado en el manifiesto (declarar herramientas en el manifiesto de la aplicación web para que los agentes puedan evaluar su relevancia con una sola solicitud HTTP GET) es una posibilidad futura en discusión, no una funcionalidad actual. Para la parte del descubrimiento que corresponde al servidor —llms.txt, MCP Server Cards— consulta Infraestructura preparada para agentes.
2. Las páginas complejas necesitan refactorización. Si el estado de tu aplicación vive en cinco stores sin coordinación, tus handlers execute serán una capa de pegamento sobre el caos. Las herramientas te obligan a encontrar —o construir— una capa de acciones coherente.
3. Las personas siguen en el ciclo. Los diálogos de confirmación para herramientas sensibles son una funcionalidad, no una fricción que debas intentar evitar.

Capa 3: MCP UI — resultados de herramientas que se renderizan

Un LLM del navegador que invoca tu herramienta WebMCP recibe JSON como respuesta. JSON es para los modelos; las personas quieren ordenar, filtrar, previsualizar y aprobar. Esa última etapa es la capa MCP UI, que ahora tiene dos respuestas estandarizadas:

MCP Apps (SEP-1865, estado Final) es la respuesta «expresiva». Una herramienta enlaza a un recurso HTML declarado previamente mediante _meta.ui.resourceUri (el esquema ui://). El host lo obtiene con resources/read, lo renderiza en un iframe aislado con una CSP que deniega por defecto y se comunica con él mediante JSON-RPC 2.0 a través de postMessage. El paquete ext-apps proporciona ambos lados: registerAppTool / registerAppResource en el servidor y la clase App en la vista. (La arquitectura completa del host se cubre en Del chat a la interfaz de agentes; aquí solo necesitas la regla de combinación que aparece más abajo).

A2UI (v0.9.1 en producción, v1.0 candidata a lanzamiento) es la respuesta «segura y portable»: el agente envía JSON declarativo (superficies, componentes, enlaces de datos) y el cliente renderiza con sus propios componentes nativos confiables, sin iframes ni código ejecutable del agente. Lo cubrí en profundidad en Cómo construir interfaces dirigidas por agentes con A2UI; desde ese artículo, v0.9.x reforzó los transportes (incluido A2UI sobre MCP) y v1.0 (especificación actualizada el 8 de junio de 2026) agrega RPC de cliente a servidor.

¿Cuál deberías elegir?

Para este stack, la combinación natural es: herramientas WebMCP cuyos resultados se renderizan como vistas de MCP Apps cuando la herramienta distribuye su propia interfaz, o como componentes de tu página cuando la propia página se encarga de renderizar (más sobre esto en el patrón de copiloto de abajo). A2UI entra en juego cuando el agente es remoto o no confiable: sigue aplicando la misma regla sobre límites de confianza del artículo anterior.

Cómo encajan las tres capas

Este es el ciclo completo, desde la intención del usuario hasta el resultado confirmado, ejecutándose (en su mayor parte) dentro de una pestaña del navegador:

flowchart TD
    subgraph Page["Tu página web"]
        Tools["Herramientas WebMCP\n(búsqueda, compra, diagnósticos)"]
        Surfaces["Superficies estructuradas\n(tarjetas, tablas, diálogos de aprobación)"]
        State["Estado de la app + stores"]
    end
    subgraph Browser["Entorno de ejecución del navegador"]
        Model["LLM en el dispositivo\n(Prompt API / Gemini Nano)"]
        Agent["Agente del navegador\n(enrutamiento de herramientas + políticas)"]
    end
    subgraph Host["Host de interfaz (pestaña o cliente de agente)"]
        View["Vista de MCP Apps / componentes nativos\n(iframe aislado o renderizado de A2UI)"]
    end

    User["Intención del usuario\n(chat, clic o selección en línea)"] --> Model
    Model --> Agent
    Agent -->|"descubrir + invocar"| Tools
    Tools <--> State
    Tools -->|"resultado JSON"| Agent
    Agent -->|"renderizar recurso de interfaz"| View
    View -->|"el usuario actúa (ordena, aprueba, edita)"| Surfaces
    Surfaces --> State
    Surfaces -->|"contexto actualizado"| Model

Compáralo con la versión anterior a 2026 del mismo flujo. El prompt iba a tu servidor, el servidor llamaba a un modelo de frontera, el modelo invocaba herramientas en tu servidor MCP, regresaba JSON y tu frontend lo renderizaba manualmente. Cuatro saltos de red y una factura de API para lo que ahora es, en gran parte, una operación local.

Cada capa se degrada de forma independiente. ¿No hay modelo en el dispositivo? Usa como alternativa un LLM de servidor que invoque las mismas herramientas WebMCP a través del agente del navegador. ¿No hay WebMCP? La página sigue funcionando para las personas (mejora progresiva, no una dependencia). ¿No hay host de MCP Apps? Renderiza el JSON con tus propios componentes. Diseña los puntos de integración, no solo el camino ideal.

Escritorio frente a móviles: estado de cada capa

Hasta aquí, el artículo parece priorizar el escritorio. Esta es la situación real en septiembre de 2026: las tres capas no están igual de preparadas para dispositivos móviles, y esa asimetría influye en tu arquitectura:

De esa tabla se desprenden tres consecuencias:

1. En móviles, el stack se invierte: primero las herramientas, después el modelo. WebMCP funciona en Android mientras que la IA integrada no, así que el patrón móvil es un LLM de servidor que invoca herramientas de la página a través del agente del navegador: las mismas herramientas WebMCP que registraste para escritorio, con otro cerebro detrás. Registra las herramientas una vez; cambia el componente de razonamiento según la plataforma.
2. La detección de funcionalidades miente en los teléfonos: haz benchmarks. Una prueba entre dispositivos de 2026 encontró un iPhone 11 Pro Max que informaba webgpu: true con soporte f16 pero no completaba ninguna ejecución de inferencia, y un Pixel 8a en un navegador integrado en una app que informaba un límite completo de 4 GB mientras fallaba en ejecuciones que sí funcionaban en Chrome (Ludion). El propio WebLLM renunció a la detección para modelos grandes en Android y los restringe mediante una heurística de tamaño de buffer (#209). Tu comprobación de disponibilidad debe ser ejecutar una pequeña inferencia de calentamiento y medir su duración, no leer un límite del adaptador.
3. El contexto largo es lo que mata la experiencia móvil, no la velocidad de decodificación. Esa misma prueba midió ~9 tok/s de decodificación sostenidos en un teléfono —utilizable—, pero un TTFT de 76–77 segundos con un prompt de 1200 tokens frente a ~3.8s con uno de 52 tokens. Las instantáneas compactas del estado (la regla del patrón de copiloto) dejan de ser una simple recomendación en móviles y se convierten en la diferencia entre funcionar y agotar el tiempo de espera.

Ventajas y desventajas, en pocas palabras:

• Ventajas de escritorio: IA integrada estable, amplios recursos de memoria y disco, descargas de modelos sin cargos por consumo de datos y herramientas maduras (inspector, chrome://on-device-internals). Desventajas: el rendimiento mínimo (como el de Iris Xe) sigue siendo lento; los requisitos de 22 GB de disco libre y 16 GB de RAM excluyen a los clientes ligeros.
• Ventajas de móviles: WebMCP + WebGPU ya están presentes en dispositivos modernos; la privacidad tiene especial relevancia en teléfonos personales; y el alcance es enorme. Desventajas: no hay IA integrada; tok/s de un solo dígito; modelos de 1–3B con un contexto cercano a 1k; fallas de pestañas al superar los límites de memoria; reducción de rendimiento por temperatura durante inferencias sostenidas; las conexiones medidas hacen que las descargas de pesos de varios GB sean poco amigables: usa la caché de forma agresiva y avisa antes de descargar.

La conclusión práctica: construye una capa de herramientas, dos rutas de razonamiento y una interfaz habilitada según los resultados del benchmark. Detecta la disponibilidad de la IA integrada en escritorio, usa una inferencia de calentamiento con WebGPU como condición en móviles y recurre al servidor para todo lo demás; deja que el TTFT medido, no el user agent, decida qué funcionalidades se habilitan.

El patrón de copiloto integrado: chat en tiempo de ejecución en tu app

Lo más concreto que puedes construir hoy con este stack es un panel de chat en tiempo de ejecución: un panel de copiloto integrado en tu app, respaldado por el LLM del navegador, basado en el estado de la página y capaz de actuar mediante herramientas WebMCP. Piensa en «Cmd+K que puede ver la página y hacer cosas», no en «un chatbot de soporte en una esquina».

La estructura

1. Una superficie de chat integrada en tu app (panel lateral, paleta de comandos o barra de herramientas de selección en línea). Recibe tokens por streaming desde la sesión de la Prompt API.
2. Un system prompt con contexto de la página (una entrada system en initialPrompts): ruta actual, elemento seleccionado, filtros visibles, rol del usuario; se actualiza a medida que cambia la página. Mantenlo pequeño: el contexto disponible en el dispositivo es valioso, así que pasa una instantánea compacta del estado, no el DOM.
3. Acceso a herramientas mediante WebMCP. Registra las 3–5 acciones que los usuarios realmente solicitan («vuelve a filtrar esta lista», «redacta la respuesta», «ejecuta diagnósticos», «llena este formulario con los datos del ticket»). El agente del navegador enruta las llamadas del modelo a herramientas hacia tus handlers execute.
4. Renderizado estructurado de resultados. Cuando una herramienta devuelve datos, renderiza una tarjeta, tabla o solicitud de aprobación directamente en el chat y refleja el cambio en la página. El chat narra; la superficie hace el trabajo.
5. Confirmación humana para las modificaciones. Las herramientas de solo lectura se ejecutan libremente; cualquier acción que escriba, envíe o gaste requiere una aprobación o un rechazo en línea. Esto refleja el diseño de WebMCP con una persona en el ciclo y preserva la confianza.

Esquema mínimo de integración

// 1. Register page tools (WebMCP) — the copilot's hands
// 2. Open a grounded Prompt API session — the copilot's brain
async function createCopilot(pageSnapshot) {
  if ((await LanguageModel.availability()) !== "available") {
    return createServerCopilot(pageSnapshot); // fallback path
  }
  return LanguageModel.create({
    initialPrompts: [
      {
        role: "system",
        content: [
          "You are the inline assistant for this page.",
          "Answer from the page snapshot. Prefer calling a page tool over guessing.",
          "Never invent IDs, prices, or statuses — read them from tool results.",
          `Page snapshot: ${JSON.stringify(pageSnapshot)}`,
        ].join("\n"),
      },
    ],
  });
}

// 3. Streaming only (deliberately simplified: the browser agent mediates real tool calls, not this loop)
async function askCopilot(session, userText, onToken) {
  // In the full WebMCP flow, the browser agent discovers registered tools
  // and invokes them; here we show the page-side contract:
  // prompt -> (tool calls handled by agent) -> streamed answer + structured results
  const stream = session.promptStreaming(userText);
  for await (const chunk of stream) onToken(chunk);
}

Dos aclaraciones importantes sobre ese esquema. Primero, el origin trial todavía está definiendo la orquestación exacta del lado de la página entre una sesión de la Prompt API y la invocación de herramientas WebMCP. Hoy, el agente del navegador (o un harness similar a un inspector) media el descubrimiento y las llamadas, no tu JS directamente. Segundo, esa brecha es precisamente la razón por la que existe la extensión Model Context Tool Inspector. Instálala, interactúa con tus herramientas registradas en lenguaje natural (usa gemini-3-flash-preview por defecto), verifica los schemas y observa los resultados estructurados antes de integrar la interfaz real del copiloto.

Qué registrar primero

Parte de tickets de soporte y grabaciones de sesiones, no de la imaginación. Los propios ejemplos de la documentación de Chrome se pueden generalizar:

• Ayuda con la navegación: find_form, go_to_section: los agentes (y los usuarios) se pierden en arquitecturas de información complejas.
• Interacción con formularios: submit_application, date_pick: transforma datos conversacionales para usarlos en widgets exigentes diseñados para personas.
• Acciones del dominio: filter_results, checkout, run_diagnostics: los 3–5 verbos que definen tu app.

Una herramienta bien hecha vale más que diez registradas con la esperanza de que funcionen. Cada herramienta necesita una descripción clara (el modelo la lee), un schema preciso (los schemas permisivos generan alucinaciones) y mensajes de error redactados para que el modelo los entienda («No se encontró ningún viaje para el ID T-1042» es mejor que «Error 400»).

Benchmarks y evals propias: confía, pero mide

Los benchmarks publicados te muestran el límite superior. Solo tus propias evals te dicen si tus tareas alcanzan el nivel necesario en el hardware de tus usuarios. Aquí tienes un harness que puedes preparar en una tarde.

Paso 1: construye un conjunto de tareas de referencia (15–30 casos)

Cubre la carga de trabajo real del copiloto, no un chat genérico:

• Resumir: 5 documentos reales de tu dominio (hilos de tickets, reseñas, notas de reuniones) con puntos clave de referencia redactados por personas.
• Extraer a un schema: 5 entradas con el JSON esperado (entidades, fechas, acciones pendientes). Evalúa la coincidencia exacta de los campos, no por intuición.
• Reescribir/clasificar: 5–10 casos con etiquetas (reescritura de tono, clasificación de prioridad, detección de idioma).
• Enrutamiento de herramientas: 5 solicitudes asociadas a la herramienta WebMCP correcta y sus argumentos. Esta es la eval de mayor valor. Una llamada a la herramienta equivocada es peor que una respuesta cautelosa.

Paso 2: evalúa con rúbricas y usa un juez para el texto

• Comprobaciones deterministas para tareas con schemas: el JSON se puede parsear, los campos requeridos están presentes y los valores coinciden con lo esperado.
• Comprobaciones con rúbricas para texto: 3–5 criterios binarios por tarea («menciona el monto del reembolso», «no inventa fechas», «menos de 80 palabras»). Los criterios binarios son más consistentes que las escalas de 1-5.
• LLM como juez solo donde las rúbricas no llegan (fluidez, tono). Primero calibra el juez frente a tus propias calificaciones en 10 muestras. La metodología completa de la serie sobre evals de este devlog (De la intuición a las puntuaciones, Sesgos y soluciones para LLMs como jueces) se aplica sin cambios. La única diferencia: el sistema bajo prueba se ejecuta en una pestaña.

Paso 3: mide lo que perciben los usuarios

Para cada tarea, registra el tiempo hasta el primer token, la latencia total y los tokens de salida. En WebLLM, lee el objeto usage del último chunk. Eso te da el rendimiento de prefill y decodificación para esa máquina. Ejecuta la matriz que importa:

• Modelos: integrado (Prompt API) frente a candidatos de WebLLM (por ejemplo, Qwen2.5-1.5B frente a Llama-3.2-3B frente a Phi-3.5-mini).
• Niveles de hardware: GPU discreta, Apple Silicon, gráficos integrados de gama baja (como Iris Xe).
• Estados de caché: fría (primera visita) frente a caliente (pesos en caché, shaders compilados).
• Nivel móvil: al menos un Android de gama alta (Pixel/Samsung, Chrome) y, si gran parte de tu audiencia usa iOS, un iPhone con iOS 26+. Espera tok/s de un solo dígito y un TTFT de decenas de segundos con contexto largo; registra el TTFT con 50 y 1200 tokens de entrada por separado.

Este fragmento ejecuta los pasos 1-3 en DevTools. Pégalo en una página HTTPS después de hacer clic:

// Requires: await LanguageModel.availability() === "available".
const goldenTasks = [
  { name: "extract-date", prompt: "Meeting moved to 2026-09-20, confirm the date.", check: (o) => o.date === "2026-09-20" },
  // ... add your 15-30 cases from Step 1, each with a check() from Step 2
];
const schema = { type: "object", properties: { date: { type: "string" } } };
const base = await LanguageModel.create({
  initialPrompts: [
    { role: "system", content: "Answer with JSON only: { date: string }." },
  ],
});
let passed = 0;
for (const task of goldenTasks) {
  const s = await base.clone(); // fresh context per task — sessions accumulate history
  const t0 = performance.now();
  let ttft = 0, text = "";
  for await (const chunk of s.promptStreaming(task.prompt, { responseConstraint: schema })) {
    ttft ||= performance.now() - t0;
    text += chunk;
  }
  const total = performance.now() - t0;
  const ok = task.check(JSON.parse(text));
  passed += ok ? 1 : 0;
  console.log(`${ok ? "PASS" : "FAIL"} ${task.name} | TTFT ${Math.round(ttft)}ms | total ${Math.round(total)}ms | ~${Math.round(text.length / (total / 1000))} chars/s`);
  s.destroy();
}
console.log(`Pass rate: ${passed}/${goldenTasks.length}`);
base.destroy();

Cada tarea se ejecuta en una sesión clonada (base.clone()), de modo que la tarea N nunca ve las tareas 1..N-1: las sesiones conservan todo el historial de la conversación. La Prompt API no informa el número de tokens, así que caracteres/segundo es la medida indirecta más honesta. Para obtener tok/s reales, ejecuta las mismas tareas con WebLLM y lee el objeto usage. Cambia check() según el tipo de tarea: coincidencia exacta para tareas con schemas y predicados de rúbrica para texto.

Paso 4: decide con una tabla de ventajas y desventajas, no con un solo número

Vuelve a ejecutar el conjunto de referencia cada vez que Chrome actualice el modelo integrado (consulta chrome://on-device-internals para conocer la versión actual) o cambies los pesos de WebLLM. Los modelos en el dispositivo cambian sin que los controles. Las evals son la única forma de darte cuenta.

Construir o adoptar: una guía práctica para decidir

Construye ahora:

• Funcionalidades basadas en APIs de tareas (resumir, traducir, detectar) con detección de disponibilidad y una alternativa en el servidor. Estables desde 138, bien documentadas y con valor inmediato para el usuario.
• Copilotos con la Prompt API para tareas acotadas y basadas en contexto, con salida restringida a JSON. Estable desde 148; mantén pequeños los prompts y rigurosas las evals.
• 3–5 herramientas WebMCP en tus flujos con mayor fricción, probadas con la extensión de inspección (únete al origin trial para ponerlas a disposición de usuarios reales). Sujetas al origin trial, pero es poco probable que la estructura (nombre + descripción + schema + handler) te sorprenda.
• Vistas de MCP Apps para herramientas propias cuando controlas ambos extremos. La especificación está en estado Final y existe el SDK ext-apps.

Haz prototipos, pero no hagas promesas:

• Flujos completos de agentes basados en WebMCP en producción. El origin trial hasta Chrome 156 implica cambios frecuentes en la API y alcance limitado. Recuerda: el descubrimiento requiere una visita.
• Funcionalidades de A2UI v1.0 (RPC de cliente a servidor, nuevas reglas de catálogo). Construye sobre las estructuras de v0.9.1 y aísla el manejo de versiones en un adaptador.
• Inferencia en el dispositivo entre navegadores. WebGPU está llegando a Firefox y Safari, pero hoy sigue siendo principalmente una opción de Chromium con degradación gradual en los demás; sigue el estado de Baseline antes de prometer más.

Espera (y sigue Chrome Status):

• La versión estable de WebMCP (objetivo 157) y cualquier avance posterior en el descubrimiento basado en manifiestos.
• Los parámetros de muestreo de la Prompt API en la web (enum samplingMode en origin trial; temperature/topK directos solo en extensiones).
• La IA integrada en móviles. Las APIs de modelos fundacionales de Chrome siguen siendo exclusivas de escritorio (implementación para Android en prototipo, sin fecha de lanzamiento). Pero la inferencia con WebGPU en móviles funciona hoy dentro de límites estrechos —consulta la tabla de escritorio frente a móviles—, así que «móviles» es un nivel que debes medir, no una fecha que debas esperar.

Advertencias de producción que merecen su propia lista

• La variación del hardware es el principal riesgo. Tus cifras en un M3 Max no significan nada para un usuario de Iris Xe. Habilita las funcionalidades exigentes según el rendimiento medido, no mediante la identificación del user agent.
• Las actualizaciones del modelo llegan en silencio. Chrome actualiza Gemini Nano por separado. Tus evals de referencia son la suite de regresión. Prográmalas.
• La fatiga por permisos es real. Cada confirmación de una herramienta sensible puede resultar molesta. Agrupa las aprobaciones, explica las consecuencias en el mismo lugar y mantén las herramientas de solo lectura libres de fricción.
• Las descripciones de herramientas son a la vez superficie de ataque y texto de UX. Orientan al modelo. Redáctalas con cuidado, revísalas como si fueran prompts y nunca confíes en las entradas de las herramientas sin validarlas en execute.
• La accesibilidad y las alternativas sin IA no son negociables. Cada acción del copiloto necesita una opción equivalente accesible mediante clic. Cada resumen generado por IA necesita una opción para «mostrar la fuente». La mejora progresiva es la propuesta central de este stack. Respétala.
• Mide los costos con honestidad. Ejecutar en el dispositivo no es gratis: implica gigabytes de descargas, consumo de batería y carga de soporte cuando el dispositivo de un usuario no puede ejecutar el modelo. Registra en las métricas los resultados de disponibilidad (available / downloadable / unavailable).

El verdadero cambio

Los últimos tres años enseñaron a los desarrolladores frontend a llamar modelos por HTTP y renderizar el texto. Los próximos tres enseñarán otro reflejo: considera primero la pestaña. El modelo se está convirtiendo en una capacidad del navegador como la geolocalización o WebGL: se detecta, se controla mediante permisos y se incorpora con mejora progresiva. Las páginas dejan de ser documentos que los agentes examinan con dificultad. Se convierten en proveedores de herramientas con interfaces declaradas, tipadas y verificables. El historial de chat deja de ser la superficie del producto. Se convierte en la narración de un trabajo estructurado.

Eso invierte una parte sorprendente de la arquitectura frontend. Las instantáneas de estado se convierten en contexto para prompts. Las capas de acciones se convierten en manifiestos de herramientas. Los harnesses de evals se suman a la suite de pruebas de componentes. Los equipos que empiecen ahora a registrar herramientas y ejecutar evals de tareas de referencia —mientras WebMCP sigue en pruebas y los hosts de MCP Apps siguen multiplicándose— tendrán listas las capas de acciones, las mediciones y la intuición cuando se activen las versiones estables.

Empieza con algo pequeño: un generador de resúmenes, tres herramientas, quince casos de eval. El stack frontend del futuro cabe en un prototipo de una tarde. Y esta vez se ejecuta por completo en la pestaña.

Fuentes

• La Prompt API — Chrome for Developers (estable en la web en Chrome 148; entrada multimodal, salida estructurada, streaming)
• Notas de lanzamiento de Chrome 148 (Prompt API estable; parámetros de muestreo en origin trial)
• Prompt API — Chrome Platform Status (origin trial 139–147)
• Descripción general de las APIs de IA integrada — Chrome for Developers (tabla de estado por API)
• Generar resúmenes con IA integrada — Chrome for Developers (estable desde 138; requisitos de hardware)
• Anuncio de APIs de IA estables y en origin trial, Google I/O 2025 (Translator, Language Detector y Summarizer estables en 138)
• Summarizer API — MDN (estructura de la API, requisitos de activación y Permissions Policy)
• WebMCP — Chrome for Developers (APIs imperativa y declarativa, demos, extensión de inspección, seguridad)
• Únete al origin trial de WebMCP — Chrome for Developers (9 de junio de 2026; registro en el trial)
• WebMCP — Chrome Platform Status (origin trial 149–156; objetivo estable 157)
• Especificación de WebMCP (WebML Community Group) (semántica de registerTool, consideraciones de seguridad)
• Documento explicativo de la propuesta de API de WebMCP (13 de agosto de 2025; discusión sobre descubrimiento mediante manifiestos)
• SEP-1865: MCP Apps — interfaces de usuario interactivas para MCP (Final; esquema ui://, modelo de sandbox)
• Construye una MCP App (SDK ext-apps, empaquetado en un solo archivo, CSP)
• A2UI — protocolo para interfaces dirigidas por agentes (v0.9.1 en producción, v1.0 candidata)
• Anuncio de A2UI v0.9 — Google Developers Blog (transportes incluido MCP, middleware AG-UI)
• Motor WebLLM — GitHub (inferencia con WebGPU de código abierto, API compatible con OpenAI)
• WebLLM: motor de inferencia de LLMs de alto rendimiento en el navegador (arXiv 2412.15803) (tabla de rendimiento, ~80% del rendimiento nativo)
• Ejecuta modelos de IA directamente en el navegador con WebLLM y WebGPU (benchmarks independientes de principios de 2026, cobertura de WebGPU)
• Escalamiento no lineal de GPU — issue #773 de web-llm (inversión entre RTX 4050 y 4090; advertencia sobre benchmarks)
• Estado de implementación de WebGPU — wiki de gpuweb (despliegue por plataforma, incluidos Android 121+ y Safari 26)
• WebGPU — web-features-explorer (seguimiento del estado de Baseline)
• Protección contra fallas por buffers de almacenamiento en Android — web-llm #209 (Pixel 7 RedPajama 3B: 4.4 tok/s de decodificación; límite de 128MB)
• Rendimiento lento en Chrome para Android — web-llm #759 (Pixel 8 Pro Llama 3.2 3B: ~5 tok/s, enero de 2026)
• Notas de campo sobre inferencia en el navegador — informe de Ludion (la detección de funcionalidades miente en teléfonos; 76s de TTFT con prompts largos)
• Intención de lanzamiento: Prompt API — blink-dev (lanzamiento inicial en escritorio; prototipo para Android, lanzamiento posterior)
• Del chat a la interfaz de agentes — este devlog (artículo complementario sobre ChatKit/A2UI/MCP Apps del lado del servidor)
• Cómo construir interfaces dirigidas por agentes con A2UI — este devlog (artículo complementario sobre implementación de A2UI)
• Infraestructura preparada para agentes — este devlog (artículo complementario sobre llms.txt y MCP Server Cards)
• De la intuición a las puntuaciones — este devlog (metodología de evals de agentes)
• Sesgos y soluciones para LLMs como jueces — este devlog (calibración de jueces)