Spec the executeTool() API - #226
Conversation
This CL introduces the `executeTool()` method to the `ModelContext` interface in the WebMCP specification. This aligns the spec with the C++ implementation in Blink. Key changes: - Adds `executeTool()` and `ExecuteToolOptions` IDL definitions. - Specifies the `executeTool()` algorithm, detailing cross-document tool lookup, origin visibility checks, and asynchronous invocation in the target document`s realm. - Clarifies the execution callback arguments and JSON serialization. - Incorporates `AbortSignal` handling for tool cancellation, dispatching a `toolcancel` event in the target document. - Fires `toolactivated` event in the target document. - Updates IDL member access syntax to use idiomatic Bikeshed style. Small things Fix some things Don't serialize Object argument enforcement Add AbortSignal issue Small things
| </div> | ||
|
|
||
| <div algorithm> | ||
| The <dfn method for=ModelContext>executeTool(<var>tool</var>, <var>inputArguments</var>, |
There was a problem hiding this comment.
A JS example of how to execute a tool from a cross-origin iframe may come handy in this spec. See previous comment at #223 (comment)
beaufortfrancois
left a comment
There was a problem hiding this comment.
We should update README as well: https://github.com/webmachinelearning/webmcp#discovering-and-running-tools
See https://crrev.com/c/8121241/comment/a263bec5_46b078a4/ and webmachinelearning/webmcp#226 (comment). With both Mason *and* François in agreement about this, we should migrate from DataError => NotSupportedError. R=masonf Bug: 489045948,536063275 Change-Id: I9e5fc78b082de179c016f8a16dc052744ee28513
See https://crrev.com/c/8121241/comment/a263bec5_46b078a4/ and webmachinelearning/webmcp#226 (comment). With both Mason *and* François in agreement about this, we should migrate from DataError => NotSupportedError. R=masonf Bug: 489045948,536063275 Change-Id: I9e5fc78b082de179c016f8a16dc052744ee28513 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8155899 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1669154}
See https://crrev.com/c/8121241/comment/a263bec5_46b078a4/ and webmachinelearning/webmcp#226 (comment). With both Mason *and* François in agreement about this, we should migrate from DataError => NotSupportedError. R=masonf Bug: 489045948,536063275 Change-Id: I9e5fc78b082de179c016f8a16dc052744ee28513 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8155899 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1669154}
See https://crrev.com/c/8121241/comment/a263bec5_46b078a4/ and webmachinelearning/webmcp#226 (comment). With both Mason *and* François in agreement about this, we should migrate from DataError => NotSupportedError. R=masonf Bug: 489045948,536063275 Change-Id: I9e5fc78b082de179c016f8a16dc052744ee28513 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8155899 Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1669154}
|
|
||
| 1. Let |execution| be a new [=pending tool execution=], with the following [=struct/items=]: | ||
|
|
||
| : [=pending tool execution/caller document=] |
There was a problem hiding this comment.
Instead of caller document, should we use invoking document to make it easier to follow along when reading different algorithms?
| }, {signal: ac.signal}); | ||
| </xmp> | ||
|
|
||
| <p>In this case, tool unregistration happens after a tool Promise is resolved, but before |
There was a problem hiding this comment.
Do we have wpt for this case?
| Note: This removes |execution| from the [=traversable navigable/pending tool executions | ||
| map=]. | ||
|
|
||
| 1. [=Notify documents of a tool change=] given |targetDocument| and |exposed origins|. |
There was a problem hiding this comment.
Chromium implementation fires toolchange event before rejecting execution when aborted.
const ac = new AbortController();
await document.modelContext.registerTool(
{ name: "tool", description: "A tool", execute: () => {} },
{ signal: ac.signal },
);
document.modelContext.ontoolchange = console.log("toolchange");
const [tool] = await document.modelContext.getTools();
document.modelContext
.executeTool(tool, "{}")
.catch(() => console.log("execution rejected"));
ac.abort();
// > toolchange
// > execution rejectedBoth algorithms queue a global task on the webmcp task source. Are there things we can do implementation wise or in the spec to make sure ordering will stay the same across different implementations of WebMCP?
This PR specifies the
executeTool()API onModelContext.Closes #57.
Closes #117.
Closes #159.
Closes #160.
Preview | Diff