Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Surface callerOrigin on ModelContextClient passed to ToolExecuteCallback

Aperta
  • Qualcosa non va?
#191 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
html
Ambito
api

Direzione di ricerca

Start with the ModelContextClient interface and the tool execution steps in the current WebMCP spec, then trace how the existing exposedTo allowlist check computes the invoking origin. Update the IDL and execute algorithm together, ensuring native-agent invocations produce null. The issue identifies the relevant spec sections and related issues, but implementation may require coordination around the unresolved native-agent exposure question.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Background

PR #179 adds the toolchange event and establishes the cross-origin tool discovery model: a tool registered with exposedTo: ["https://agent.example"] becomes visible to agent.example via toolchange, and that document can subsequently invoke it. This closes the consumer side of the cross-origin relationship the permitted origin learns when tools become available.

The gap

The registrant side has no equivalent signal. When agent.example invokes the tool, the current ToolExecuteCallback fires:

webidlcallback ToolExecuteCallback = Promise (object input, ModelContextClient client);
The client object carries no information about which origin triggered the call. This is consequential when exposedTo lists multiple origins:
jsdocument.modelContext.registerTool({
name: "get-record",
description: "Fetches a record by ID",
inputSchema: { type: "object", properties: { id: { type: "string" } } },
execute(input, client) {
// client.callerOrigin does not exist
// both callers below receive identical behavior
return getFullRecord(input.id);
}
}, {
exposedTo: [
"https://internal-agent.example",
"https://partner-agent.example"
]
});

The browser already enforces that only listed origins may invoke the tool the exposedTo allowlist check happens during IPC routing before execute() fires. But the result of that check which specific listed origin passed is not forwarded to the callback. The registrant cannot observe it from any other available surface.

The exposedTo declaration creates a named, multi-party relationship at registration time. Without caller identity at invocation time, the registrant cannot implement differentiated behavior within that relationship serving different response shapes to different permitted callers, or making dynamic decisions based on which party in an established relationship is acting.

Proposal

Add callerOrigin as a USVString? attribute on ModelContextClient:
webidlinterface ModelContextClient {
// ... existing members ...
readonly attribute USVString? callerOrigin;
};
callerOrigin is the serialization of the invoking document's origin, produced by running the serialize an origin algorithm. It is null when the invoking agent is a browser's agent.

The browser already computes this value during the exposedTo allowlist check it is the target origin in the tool is visible to an origin algorithm. This proposal forwards it to the callback rather than discarding it.

Usage:

jsexecute(input, client) {
if (client.callerOrigin === "https://partner-agent.example") {
return { summary: getSummary(input.id) };
}
return { full: getFullRecord(input.id) };
}

Precedent

MessageEvent.origin (HTML §9.4.3) is the closest parallel. In postMessage, the browser enforces origin-based routing; MessageEvent.origin lets the receiver differentiate among already-permitted senders rather than gate access. The motivation here is identical: exposedTo is the allowlist, the browser enforces it, and callerOrigin lets the registrant distinguish which permitted party acted.

Spec delta

The change touches two places in the current spec:

§4.2.3 ModelContextClient interface add the callerOrigin attribute to the IDL and define its value as the serialized origin of the invoking document, set by the browser when constructing the ModelContextClient instance passed to execute.

§3 tool definition / execute steps the execute steps for imperatively-registered tools (currently "steps that invoke the supplied ToolExecuteCallback") need to specify that the ModelContextClient passed to the callback is constructed with callerOrigin set to the serialized origin of the invoking document at the point the allowlist check passes.

The native-agent case

For tools invoked by a browser's agent (no explicit exposedTo, or invoked natively), callerOrigin should be null.

Rationale: a browser's agent has no document origin in the sense the web platform uses that term. Using null (rather than a sentinel string like "browser") is the correct type-safe choice it avoids introducing an unstructured magic string into an otherwise origin-typed field, it is consistent with how the platform handles absent origins elsewhere (e.g. opaque origins serializing to "null" is already a known footgun, so we should not add another string consumers need to guard against), and it gives registrants a clean boolean branch: if (client.callerOrigin === null) means native agent. This does intersect with the open question in the explainer about native-agent exposure and should be resolved in coordination with that discussion.

Related issues
  1. #179 adds toolchange and the cross-origin discovery model this proposal's registrant-side signal completes
  2. #178 ModelContextClient interface definition; callerOrigin is an addition to this interface
  3. #180 cross-origin invocation mechanics; the IPC routing path that already computes the value being proposed here
  4. #159 / #160 multi-origin exposedTo use cases that motivated tiered tool access and are the primary driver for needing caller identity at invocation time
Lingua principale
Bikeshed
Stelle
4.7k
Fork
328
Merge medio
2g 15h
PR unite (30g)
16

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webmcp

Tutte le issue di webmachinelearning/webmcp

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.