Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Surface callerOrigin on ModelContextClient passed to ToolExecuteCallback

Đang mở
  • Có gì không ổn?
#191 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
html
Lĩnh vực
api

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Bikeshed
Star
4.7k
Fork
328
Merge trung bình
2 ngày 15 giờ
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của webmachinelearning/webmcp

Tất cả issue của webmachinelearning/webmcp

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.