[skill-update] webmcp-skill-update: clarify inputSchema optionality, callback signatures, and AbortSignal-based tool lifecycle

[github-actions]

Reconciled skills/webmcp/references/webmcp-reference.md against the current WebMCP Community Group Draft (9 March 2026) fetched from (webmachinelearning.github.io/redacted), and updated all three skill files to reflect the Chrome 148 tool lifecycle change.

Material Deltas

1. inputSchema marked optional

Before: inputSchema: JSON Schema-like object describing the expected input.
After: inputSchema: optional JSON Schema object describing the expected input; omit when the tool takes no structured input.

Source: (webmachinelearning.github.io/redacted) — IDL shows object inputSchema; without the required keyword, and the registerTool() algorithm (§4.2) explicitly branches on "If tool's inputSchema exists" before attempting serialization.

2. required/optional labels added to ModelContextTool fields

Added explicit (required) / (optional) markers for name, description, execute, and annotations.readOnlyHint.

Source: (webmachinelearning.github.io/redacted) — name, description, and execute carry the required keyword; inputSchema and annotations do not.

3. ToolExecuteCallback signature documented

Before: "The ToolExecuteCallback can be asynchronous."
After: "The ToolExecuteCallback signature is (input: object, client: ModelContextClient) => Promise<any> and may be asynchronous."

Source: (webmachinelearning.github.io/redacted) — callback ToolExecuteCallback = Promise<any> (object input, ModelContextClient client);

4. UserInteractionCallback zero-argument contract documented

Before: requestUserInteraction described without callback signature.
After: "The callback argument is a zero-argument async function () => Promise<any> that performs the user-facing step and resolves with the interaction result."

Source: (webmachinelearning.github.io/redacted) — callback UserInteractionCallback = Promise<any> ();

5. unregisterTool() removal and AbortSignal-based tool lifecycle (Chrome 148)

Before: registerTool(tool) with no lifecycle option; unregisterTool(name) used for removal.
After: registerTool(tool, { signal }) accepts an optional AbortSignal; aborting the signal unregisters the tool. unregisterTool() is removed starting Chrome 148.0.7757.0. A transition-window pattern calls unregisterTool?.(name) (optional chaining) then controller.abort() to support both old and new browsers.

Source: Chrome 148.0.7757.0 / webmachinelearning/webmcp PR #147.

assets/model-context-registry.template.ts updated: registerWebMcpTools() now creates a single AbortController, passes { signal: controller.signal } to every registerTool() call, and dispose() calls both unregisterTool?.() and controller.abort() for cross-version compatibility.

Files Changed

• skills/webmcp/references/webmcp-reference.md
• skills/webmcp/references/compatibility.md
• skills/webmcp/assets/model-context-registry.template.ts

Validation

• Metadata validator: python .github/skills/skill-creator/scripts/validate-metadata.py → SUCCESS
• Checklist reviewed: all criteria pass (no structural changes, SKILL.md unchanged, file layout unchanged)
• CodeQL security scan: 0 alerts

Remaining Risks

• The spec's declarative API section (§4.3) remains entirely TODO and refers to an explainer draft. The skill's declarative-api.md reflects preview/implementation behavior; this divergence is expected and noted in the skill's precedence rules.
• Chrome version/flag details in compatibility.md come from preview materials, not the spec. These could not be validated from the spec alone and are left unchanged except for the Chrome 148 AbortSignal addition.

Generated by Skill Update Worker · ◷

---

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.

[webmaxru]

@copilot implement this input too:

---

A tool should require the same level of ownership as unregistering an event listener. To prevent scripts from inadvertently or maliciously unregistering tools they did not create, unregisterTool() is now removed.

Starting from Chrome 148.0.7757.0, the registerTool() API has been updated to support an optional AbortSignal. Aborting this signal will now trigger the tool's unregistration. Full technical details are available in PR #147.

To ensure a smooth transition and maintain compatibility over the next few releases, we recommend implementing a wrapper similar to the one provided below. You can also refer to PR #104 to see how we've updated some WebMCP demos.

const controller = new AbortController();

navigator.modelContext.registerTool(myTool, { signal: controller.signal });

// Unregister tool later...

navigator.modelContext.unregisterTool?.(myTool.name);

controller.abort();

[Copilot]

@copilot implement this input too:

---

...

Implemented in a7c492d across three files:

• webmcp-reference.md — Imperative API item 1 notes the new { signal: AbortSignal } option on registerTool() (Chrome 148+). Item 2 replaces the old unregisterTool() entry with the recommended transition pattern: call unregisterTool?.(name) first (for older browsers), then controller.abort(). Registration Semantics item 6 documents that unregisterTool() is removed in Chrome 148 and explains the transition-window approach with optional chaining.

• model-context-registry.template.ts — registerWebMcpTools() now creates a single AbortController and passes { signal: controller.signal } to every registerTool() call. The dispose() method calls unregisterTool?.() (optional chaining for backward compat) then controller.abort(), matching the wrapper pattern from the PR.

• compatibility.md — Availability Snapshot records Chrome 148.0.7757.0 as the version where unregisterTool() is removed and the signal option is added. Removed Or Obsolete Preview Surfaces lists unregisterTool() alongside the other removed APIs.