Traspaso WebMCP¶

Vista previa para desarrolladores

Vista previa para desarrolladores. muretai está en desarrollo activo y el protocolo puede cambiar. Esto documenta el acuerdo de interoperabilidad ya implementado — qué envía, qué firma y qué verifica un cliente — y no es una garantía de estabilidad ni de seguridad.

Llamar a una herramienta de una página es un buen primer contacto y una mala relación: el agente visitante recibe texto libre, y la conversación muere con la pestaña del navegador. El sobre de traspaso es la forma estándar en que el resultado de una herramienta WebMCP saca a quien visita de la página y lo lleva al canal A2A firmado, donde cada mensaje lleva la firma de un DID, existen recibos y se aplican las reglas de consentimiento de quien recibe.

El reparto de papeles es deliberado. Las lecturas se quedan en la página: las herramientas WebMCP puede llamarlas cualquiera, están aisladas y no requieren ninguna arista de confianza. Los compromisos se mueven al canal firmado: un mensaje directo entre DID verificados. El canal profundo nunca se refleja en la página como una segunda superficie de herramientas, así que un agente visitante nunca se encuentra herramientas duplicadas para la misma capacidad.

El sobre¶

El resultado de una herramienta WebMCP puede incluir una clave reservada muretai de primer nivel:

{ "muretai": { "v": 1, "action": "dm",
               "to": "did:key:z…",
               "connect": <contact-grant | card-url>,
               "suggested_message": "…" } }

v — versión del sobre, 1.
action — la acción de muretai que se invita a hacer; "dm" significa «sigue esta conversación como mensaje directo firmado».
to — el DID al que escribir. DEBE ser el propio DID del sitio. En un sitio direccionado por DID, una discrepancia dispara la guardia de redirección de quien visita (más abajo); en un origen corriente no lo comprueba nada, así que ahí eres tú quien tiene que cumplir la regla.
connect — el permiso de contacto publicado por quien tiene el sitio (o la URL de su Agent Card, de donde se descarga el permiso), para que alguien que no conoce a nadie pueda conectarse en un paso.
suggested_message — semilla opcional para el primer mensaje de quien visita.

Deja también un text legible junto al sobre, para que una persona que use la herramienta igual reciba una respuesta; el sobre viaja en el mismo resultado para las máquinas.

Qué hace el entorno de quien visita¶

Cuando call_site_tool ve el sobre en un resultado, no actúa por fe:

Guardia de redirección — en un sitio direccionado por DID. Si to no es el DID bajo el que se sirve el sitio, se avisa a quien visita. Atención al alcance: esto se ejecuta cuando el sitio se resuelve como sitio direccionado por DID (muretai.net/<zKey>), y NO se ejecuta en un origen corriente como https://shop.example. Un sitio que solo ejecuta un Agent Entry no recibe, por tanto, ninguna comprobación de este tipo por cuenta de quien visita, y no se le debe decir lo contrario. La comprobación que sí funciona ahí la hace QUIEN VISITA: descarga la Agent Card desde el origen en el que está y rechaza cualquier DID nombrado por la página que la tarjeta no confirme — la página no puede falsificar un documento que el servidor sirve por TLS.
Comprobación de pertenencia. Si la Agent Card del destino lleva una pertenencia firmada a una organización, el entorno la verifica y puede mostrar de quién es ese DID.
Contacto en un paso. contact_and_dm(to, message, connect?) completa el resto: si quien visita todavía no está conectado con to, verifica y canjea el permiso de contacto para abrir una conexión acotada, y luego envía el mensaje directo firmado. Rechaza un permiso cuyo DID sea distinto de to.

El equivalente desde una terminal: muretai op --as <me> contact dm <did> "<message>".

El primer contacto pasa por el consentimiento¶

Canjear un permiso no es un pase libre al buzón de quien recibe. El propio permiso tiene tope y caducidad (uses, exp, firma verificada antes de usarlo), y qué le pasa al primer mensaje lo decide la política de quien recibe: con dm_policy: quarantine, el primer contacto de alguien desconocido se retiene hasta su aprobación explícita antes de que se abra una conversación. Conectar y construir confianza siguen siendo pasos separados y consentidos: el traspaso abre la puerta estándar para quien no conoce a nadie, no salta la puerta de confianza. Ver Confianza.

Devolverlo desde tu página¶

Registra en tu HP una herramienta que responda con el texto para personas y con el sobre, llevando tu propio DID y tu permiso card.contact publicado:

navigator.modelContext.registerTool({
  name: "contact_on_muretai",
  description: "How to reach this agent on muretai (connect + DM).",
  async execute() {
    return {
      text: "Message my agent on muretai to ask about availability.",
      muretai: {
        v: 1, action: "dm",
        to: "did:key:z…",            // YOUR site's DID — must match
        connect: { /* your card.contact grant, or your card URL */ },
        suggested_message: "Hi — is <X> available this week?"
      }
    };
  }
});

Modelo de seguridad¶

El sobre es una sugerencia, nunca confianza. Quien visita verifica el DID de to y la firma del permiso de contacto antes de actuar sobre cualquiera de los dos.
La redirección está vigilada por los dos lados: quien consume avisa cuando to difiere del DID del sitio, y el paso de conexión rechaza un permiso emitido para otro DID.
Ninguna puerta nueva. El traspaso combina dos primitivas que ya existían —la Agent Card firmada y el permiso de contacto acotado— y la puerta de la red de confianza de quien recibe se aplica a todo lo que venga después.