Skip to content

v1.2.0: WebMCP tools, HITL consent, tab control

Choose a tag to compare

@schequm schequm released this 19 Apr 22:40
· 10 commits to main since this release

Added

  • WebMCP agent tools (2 tools): list_webmcp_tools and call_webmcp_tool. AgentScripts can now register tools on web pages via navigator.modelContext.registerTool(...), callable from your IDE through the MCP bridge.
  • Tab control (3 tools): open_tab, close_tab, focus_tab. Tool count is now 18 (was 13).
  • AgentScript conventions resource: customaise://agentscript-conventions with the full reference for declaring and registering WebMCP tools.
  • CHANGELOG.md and LICENSE now ship in the tarball.

Changed (behavior MCP clients should know about)

  • call_webmcp_tool can block for up to 5 minutes when the tool is declared with the prompt permission in the AgentScript @webmcp header. The Customaise extension surfaces an in-browser consent modal, and the tool body only runs if the user approves. Previously, tool calls were fire-and-forget; this is a user-visible latency change for any client that invokes prompt-gated tools. Surface a pending state to the end user rather than timing out aggressively.
  • "Always allow / Always deny" persists per-script per-tool on the user's device, so subsequent identical calls may run without showing a modal. Transparent to the MCP client.
  • Remote HITL approvals (optional, user opt-in): if the user has Power User and has enabled Remote HITL Approvals on their account page, prompt-gated calls are also mirrored there. No MCP-client-side change; the tool simply returns whenever any authorised surface resolves.
  • Server-reported version now tracks package.json. Previously the MCP handshake hardcoded 1.0.3 and drifted silently. The number IDE clients see is now the same as the published version.
  • prompts capability removed from the initialize handshake. The server never registered any prompts, so advertising prompts: {} led clients to list an empty collection. If prompts ship later they will be added back alongside server.prompt(...) registrations.

Security

  • WebSocket bridge enforces an Origin allowlist. Only connections from Chrome extension service workers with the known Customaise extension IDs are accepted. A malicious webpage can no longer open new WebSocket('ws://localhost:4050') and issue tool calls behind the user's back. See the README "Security Boundary" section for the threat model and the CUSTOMAISE_MCP_EXTRA_EXTENSION_IDS / CUSTOMAISE_MCP_ALLOW_INSECURE env vars for dev and test flexibility.
  • Tool-call arguments are KMS-encrypted at rest in Firestore when remote approvals are enabled. Metadata (toolName, scriptName, origin, timestamps) stays plaintext, matching the sensitivity tier of billing records. Arguments transit HTTPS in plaintext to the backend, then encrypt before persistence.
  • No MCP client-side secrets, cookies, or session tokens cross the bridge. Tool calls run inside the user's browser session; the MCP server only initiates them.