Invoke advertised vault operations with generic inputs

[rgarcia]

Summary

• Show every API-advertised item operation in invocation hints and recheck availability immediately before invocation.
• Accept generic operation-specific inputs and pass them directly to client.vaults.items.performOperation; no MCP branch or schema names an operation. The API validates required inputs.
• Remove the field-name-based fill path, its dedicated response/error helpers, and its local response type. Project returned items with the existing item policy; project other results through a shared public-field allowlist. Unknown shapes fail closed rather than exposing opaque provider data.
• Pass through the exact 4xx provider rejection reason only when the API explicitly marks it in inner_error, followed by inspect-state/no-automatic-retry guidance; otherwise use generic curated errors and conservative unknown-outcome guidance. Unmarked 429 rate limits stay distinct.

Compatibility

• Calls that previously passed a dedicated fill argument now pass the same object as inputs. This intentionally changes the MCP tool schema while keeping the API request body unchanged.
• The tool no longer claims that particular validation errors guarantee no browser writes; after an operation error it tells the agent to inspect state/events/browser before acting.
• Deploy kernel/kernel#4346 first: it adds the rejection marker, persistent card state.status_reason, and rejection item events.

Tests

• bun test (700 pass)
• bunx tsc --noEmit (pass)
• Targeted Prettier formatting passed; repository-wide bun run format:check flags pre-existing AGENTS.md formatting.

[vercel]

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

Project	Deployment	Actions	Updated
mcp	Ready	Preview	Sep 24, 2026 1:34am UTC

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6ae1383. Configure here.}

[hiroTamada]

looks good overall. two non-blocking questions:

• src/lib/mcp/tools/vault-items.ts:173-185 — can the API ever return status: "completed" with a missing or failed field outcome? the old fill response check treated that as unconfirmed; if it is possible, should we preserve that consistency check without tying it to an operation name?
• src/lib/mcp/vault-responses.ts:437-456 — when passing through an API-marked provider rejection reason, should we also include the usual inspect-state/no-automatic-retry guidance? the specific error currently returns only the reason.

[rgarcia]

Thanks — the current API fill executor allocates one outcome per requested selector, and completed is returned only after every outcome becomes filled; a missing or failed outcome produces an error or failed/unknown instead. I kept MCP response projection generic rather than restoring a fields/input-shape-specific validator. In 29e11c5, marked provider reasons retain the exact reason and now add inspect-state/no-automatic-retry guidance. The test also covers an unmarked 429 staying curated.