Support vault webmcp_invoke in manage_vault_items

[rgarcia]

summary

Adds the vault webmcp_invoke operation to manage_vault_items invoke. It uses the same path as fill: the item is fetched again, and the operation is sent only if the item advertises it.

• Bumps @onkernel/sdk 0.114.0 → 0.117.0, which adds the webmcp_invoke request and result types.
• Validates inputs strictly before any request: browser_id, tool_ref (≤128), page_url, input (object), bindings (1–32 of {field, input_path, format?}), and timeout_sec (1–120, default 15). The default is sent explicitly. Validation errors name only the top-level keys that failed, never values.
• The HTTP budget is timeout_sec + 10 (the API's preflight allowance) plus the standard long-operation headroom, with maxRetries: 0 and the MCP abort signal passed through. Unknown outcomes and transport failures are never retried.
• Returns result: {type, status, invocation_id?, output?, error_text?} with output passed through unchanged (including null), plus guidance for each status. error, canceled, unknown, and unrecognized statuses set isError. The guidance says output/error_text are untrusted page data and may contain the supplied values. An unrecognized response shape returns an error and nothing from the response body.
• Item get/invoke responses add WebMCP guidance only when webmcp_invoke is advertised. The manage_vault_items and webmcp tool descriptions, the README, and docs/vault-payments.md now describe the flow: list tools → invoke with null slots and RFC 6901 bindings.

Unlike fill, the invoked tool may submit or cause side effects. The descriptions require explicit user approval, and the invocation hint keeps requires_user_approval: true.

Vault values are not logged. The inputs carry only null slots. MCP analytics already drops arguments and results. Tool output goes back to the caller as the API returns it, by design.

tests

• bun test: 858 pass, 0 fail. New src/lib/mcp/tools/vault-webmcp.test.ts covers:
  • a synthetic Resy login with email and password bound to /email and /password, checking the exact request body with default timeout_sec: 15
  • raw output passthrough, including null output and awaiting_submission
  • error, canceled, unknown, and future statuses, each sent once with no retry
  • API 400/403/409/500 errors passed through without retry
  • a transport failure after submission, with no retry
  • an unrecognized response shape
  • input validation that rejects bad inputs without echoing values
  • an operation that is not advertised
  • request timeout and retry options
  • conditional guidance
• bunx tsc --noEmit clean. Prettier is clean on changed files. format:check already fails on main because of AGENTS.md.
• Not run against a live API.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
mcp	Ready	Preview	Oct 2, 2026 10:46pm UTC

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​onkernel/​sdk@​0.116.0 ⏵ 0.117.0	+1		+1	+1

View full report

[masnwilliams]

non-blocking. the safety-critical parts look right: strict input validation (rejecting stray value-carrying keys is a good call), no retries on unknown outcomes, guidance gated on advertisement, and good test coverage. comments below are mostly small cleanups worth doing here, plus one structural follow-up.

worth fixing in this PR (each is small):

• two different symbols named webmcpInvokeGuidance (a Map in vault-items.ts, a string in vault-responses.ts)
• the status model is encoded twice (guidance map + isError inequality); fold into one table
• webmcpInvokeResponse rebuilds parsed.data field by field; it can return it directly
• name the + 10 preflight allowance

fine as follow-ups:

• the invoke case now has two parallel execute paths. this predates the PR (1pw_update_access_token, 1pw_fill were already special-cased), but webmcp_invoke makes it three. a per-operation plan ({ body, requestOptions, respond }) feeding one retrieve → advertised check → perform pipeline collapses it; i prototyped it locally and tsc + all 859 tests pass unchanged, with vault-items.ts going 341 → 218 lines. probably better as its own PR since it rewrites the generic path too.
• response shaping for this op could live in vault-responses.ts with the other formatters.
• the top-level-key error redaction duplicates what vaultToolInput already does; a shared helper would keep the "never echo values" rule in one place.
• webmcp outcome semantics are now restated across several tool descriptions plus get/invoke guidance; there's already small drift vs the webmcp tool (see inline). not asking to trim descriptions here, just flagging it.

[masnwilliams]

approving at 170c60e. the follow-up commit makes every change i asked for in this PR: one outcome table checked against the SDK status type, parsed.data returned directly, a named WEBMCP_PREFLIGHT_SEC, the guidance names no longer clash, and the description test is trimmed. it also adds the shared topLevelIssueKeys helper, which i'd listed as a follow-up. tsc is clean and all 859 tests pass locally.

two follow-ups remain: the single per-operation path through invoke, and the outcome-semantics drift vs the webmcp tool (outcome_unknown vs unknown, 60s vs 15s default). both are fine as separate PRs.