fix: accommodate WebMCP consequential tool annotation - #102

…bugging

The weekly upstream watcher failed again on 2026-09-28 (run 36394033999):
upstream moved past f5645e9a after this branch pinned it.

Review of f5645e9a..433a1948 (4 commits touching index.bs):
- #311: non-normative note that unregistration doesn't cancel in-flight
  executions; the adapter already preserves them (#90).
- #279: executeTool() input clarification and example; agent-side API the
  SDK never calls.
- #301: navigable-lookup and completion-step parallelism fixes; UA-internal.
- #315: MCP reference made non-normative.
None changes registerTool, its options, ToolAnnotations or the callback
shape the adapter relies on.

ToolAnnotations gained consequentialHint (#217) and debugging (#253) earlier
in the reviewed range. WebMCPToolAnnotations now declares both (absorbing
#102), and the contract guards their IDL lines so a removal upstream
surfaces here. No SDK tool is marked consequential: vcp_chat, the one
non-read-only tool, sends a chat query and changes nothing irreversible.
#302 (name validated before description) needs no change: neither the
adapter nor the polyfill re-implements registerTool validation.

Checker: matched 4a88ed6ff14a against live upstream (exit 0); checker
tests 3 passed; validate_repo passed; API snapshot regenerated and
verified; webmcp tsc clean, vitest 266 passed.

Co-Authored-By: Claude <[email protected]>

…int and debugging (#112)

* chore(webmcp): re-pin the upstream contract after reviewing 15 spec commits

The weekly watcher has failed since 2026-09-07 with one missing required
fragment: upstream changed executeTool's inputObject from `optional object
inputObject = {}` to `optional any inputObject` (webmachinelearning/webmcp#251).
The watcher was working correctly; the contract was stale.

Reviewed webmachinelearning/webmcp 41d12f05..f5645e9a (15 commits) against the
surface this adapter implements:

- executeTool signature change is agent-side API. This SDK registers tools and
  never calls executeTool (it appears nowhere outside the contract file), so
  the fragment text is updated with no adapter change.
- registerTool and ModelContextRegisterToolOptions are unchanged; all other
  previously reviewed fragments still match byte-for-byte.
- ModelContext now extends EventTarget and adds getTools/ontoolchange/
  ontoolactivated/ontoolcancel. WebMCPModelContext is a structural subset of
  what this adapter calls, so it stays valid.

Also guards the ToolAnnotations members webmcp/src/types.ts maps
(readOnlyHint, untrustedContentHint). The contract previously asserted nothing
about annotations, so their removal upstream would have left the adapter
declaring a surface the spec no longer defines, with no signal.

Follow-up, not in this change: upstream ToolAnnotations gained consequentialHint
(#217) and debugging (#253); WebMCPToolAnnotations in webmcp/src/types.ts:20-23
carries neither. consequentialHint is already handled on the unmerged branch
codex/webmcp-consequential-hint; `debugging` is unclaimed. Upstream #302 also
reordered registerTool's name/description validation, which the adapter's
registration error expectations should be checked against.

Verified: scripts/check_webmcp_upstream.py reports status "matched" against
live upstream (exit 0); 3 checker tests pass; validate_repo.py passes.

Closes #101

Co-Authored-By: Claude <[email protected]>

* fix(deps): clear the four advisories failing SDK CI

Both audit steps on this PR fail on pre-existing advisories that postdate main's
last SDK CI run (2026-09-03), not on anything the contract re-pin touches.

Python (pip_audit, python/requirements-dev.lock):
  httpx2 2.10.0 -> 2.13.0, clearing PYSEC-2026-3846 (fixed 2.12.0),
  PYSEC-2026-3848 and PYSEC-2026-3849 (both fixed 2.11.0).
  Resolved with --upgrade-package httpx2 to keep the churn to that package;
  httpcore2 follows it, and hypothesis and uv drifted forward with the
  re-resolution.

Rust (cargo audit, rust/Cargo.lock):
  rustls 0.23.43 -> 0.23.45, clearing RUSTSEC-2026-0285 (medium, 5.3).
  Transitive through reqwest, which stays pinned at =0.13.4; a patch bump
  within the existing requirement, so no manifest change.

Verified with the workflow's own commands: `cargo audit --deny yanked --file
rust/Cargo.lock` exits 0 across 275 crates; `npm audit --audit-level=moderate`
reports 0 vulnerabilities; `cargo check --workspace --all-targets` compiles;
validate_repo.py passes; the WebMCP contract still reports matched. pip_audit
could not run locally (ensurepip aborts under uvx), so the Python side rests on
2.13.0 exceeding all three fix versions and is confirmed by CI.

Co-Authored-By: Claude <[email protected]>

* fix(webmcp): re-pin upstream to 433a1948 and map consequentialHint/debugging

The weekly upstream watcher failed again on 2026-09-28 (run 36394033999):
upstream moved past f5645e9a after this branch pinned it.

Review of f5645e9a..433a1948 (4 commits touching index.bs):
- #311: non-normative note that unregistration doesn't cancel in-flight
  executions; the adapter already preserves them (#90).
- #279: executeTool() input clarification and example; agent-side API the
  SDK never calls.
- #301: navigable-lookup and completion-step parallelism fixes; UA-internal.
- #315: MCP reference made non-normative.
None changes registerTool, its options, ToolAnnotations or the callback
shape the adapter relies on.

ToolAnnotations gained consequentialHint (#217) and debugging (#253) earlier
in the reviewed range. WebMCPToolAnnotations now declares both (absorbing
#102), and the contract guards their IDL lines so a removal upstream
surfaces here. No SDK tool is marked consequential: vcp_chat, the one
non-read-only tool, sends a chat query and changes nothing irreversible.
#302 (name validated before description) needs no change: neither the
adapter nor the polyfill re-implements registerTool validation.

Checker: matched 4a88ed6ff14a against live upstream (exit 0); checker
tests 3 passed; validate_repo passed; API snapshot regenerated and
verified; webmcp tsc clean, vitest 266 passed.

Co-Authored-By: Claude <[email protected]>

---------

Co-authored-by: Claude <[email protected]>