MCP Apps: cómo añadir interfaces interactivas a tools MCP sin abrir un agujero de seguridad

MCP Apps permite que una tool devuelva una interfaz interactiva dentro del chat. Es útil para aprobar, explorar y decidir; no para saltarse permisos ni convertir el agente en una web embebida sin controles.

MCP Apps es una extensión de Model Context Protocol para que un servidor devuelva una interfaz interactiva —un dashboard, formulario, tabla o flujo de aprobación— dentro de un host de chat compatible. La UI vive en un iframe sandboxed y habla con el host mediante mensajes controlados; no obtiene acceso directo al DOM, cookies o almacenamiento del host.

Tampoco es una autorización implícita. Que la vista muestre un botón no significa que pueda ejecutar una operación. El servidor debe validar usuario, tenant, argumentos y política igual que lo haría si la llamada viniera de un cliente HTTP ordinario.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const server = new McpServer({ name: "release-dashboard", version: "1.0.0" });

server.registerResource(
  "release-view",
  "ui://release-dashboard/view.html",
  {},
  async () => ({
    contents: [{
      uri: "ui://release-dashboard/view.html",
      mimeType: "text/html;profile=mcp-app",
      text: await loadBundledHtml()
    }]
  })
);

server.registerTool(
  "list_release_risks",
  {
    title: "Riesgos de despliegue",
    inputSchema: { service: "string" },
    _meta: { ui: { resourceUri: "ui://release-dashboard/view.html" } }
  },
  async ({ service }, extra) => {
    const user = await requireAuthorizedUser(extra);
    const risks = await readRisksForTenant(user.tenantId, service);
    return {
      content: [{ type: "text", text: `Hay ${risks.length} riesgos abiertos para ${service}.` }],
      structuredContent: { service, risks: risks.map(toSafeViewModel) }
    };
  }
);

La vista: trata el iframe como un cliente no confiable

La vista debe inicializarse con el bridge, esperar los eventos del host y renderizar solo datos validados. Su trabajo es presentar y recoger intención del usuario, no decidir permisos. Cuando el usuario pulsa aprobar, la vista llama a una tool estrecha con un ID; el servidor vuelve a comprobar que la persona puede aprobar ese recurso y que el estado sigue siendo válido.

Evita pasar secretos, tokens de larga vida o documentos completos en el HTML de la resource. El iframe aislado reduce privilegios, pero no convierte datos sensibles en inocuos. Envía el mínimo necesario, aplica redacción por tenant y considera que cualquier dato mostrado puede ser copiado por el usuario autorizado.

Para acciones de escritura, modela una transición explícita: `preview` → `confirm` → `execute`. La UI puede enseñar el impacto y pedir confirmación; el servidor debe usar un idempotency key y rechazar operaciones repetidas o estados caducados. Es el mismo patrón que usarías en una API de pagos, solo que aquí el disparador nació dentro de un chat.

Mide utilidad, no solo clicks: cuántos turnos evita la UI, cuántas aprobaciones se revierten, qué operaciones se cancelan, cuánto tarda en aparecer el resultado y cuántas veces se usa el fallback textual. Si no reduce error o tiempo de decisión, una respuesta bien diseñada probablemente era mejor.

Checklist de producción

• La tool devuelve una respuesta textual completa aunque el host no soporte UI.
• La resource usa un URI `ui://` registrado y MIME type específico para MCP Apps.
• La vista recibe `structuredContent` mínimo y no secretos ni datos de otros tenants.
• Cada tool de lectura o escritura revalida usuario, tenant, scopes y estado en servidor.
• Las acciones mutantes tienen preview, confirmación, idempotencia y auditoría.
• La CSP declara solo dominios imprescindibles; sin comodines ni scripts remotos no revisados.
• La UI trata todo contenido externo como datos y lo sanitiza antes de mostrarlo.
• Se prueba el fallback textual y la degradación en cada host objetivo.
• Logs guardan IDs, acción, resultado y denegaciones; no el contenido sensible por defecto.