[benbalter]

Adds @open-and-async/mcp/browser, an entry point that registers the same 11 tools with a page's WebMCP model context. An agent in a WebMCP browser can then call them on open-and-async.com with nothing to install.

Why

The tools are pure functions over the bundled summaries (template formatting, lookups, keyword ranking). Nothing about them needs a local Node process, so running them in the page is the cheapest way to reach people who will never run npx. There's no server endpoint and nothing extra to deploy.

How

• One source of truth for tools. src/book.js holds the runtime-neutral helpers plus a createBook() factory. src/data.js keeps every export it had, but is now just the Node loader for data/book.json.br. registerContentTools(server, data) takes the book as a parameter rather than importing data.js, so the tool modules never touch node: APIs.
• src/browser.js collects the existing registerTool calls with a stand-in server (the same trick test/helpers.js already uses) and passes them to modelContext.registerTool():
  • Input is validated with each tool's own zod schema before the handler runs, the way McpServer does for stdio, so search_principles' limit bounds and the optional fields behave the same.
  • inputSchema comes from z.toJSONSchema(..., { io: "input" }).
  • zod runs jitless: its new Function probe otherwise logs a CSP violation on pages without 'unsafe-eval'.
  • A tool the browser rejects (say, a name clash) is skipped with a warning instead of failing the rest.
• The page supplies the book data. Browsers can't decompress Brotli streams yet (Chrome 155's DecompressionStream has no 'brotli' format), and where the data lives is the page's call. The site gzips the package's .br at build time.
• src/browser.d.ts types the entry point. The new exports map lists ./browser, ./data/book.json.br, and ./package.json. Nothing could import the package root before (no main, no root index.js), and npx/the bin aren't affected.
• Bumps to 1.1.0 (new entry point) in all four version spots. The manifest.json tool list is unchanged.

What WebMCP doesn't carry

Tools only. There's no channel for the server instructions, resources, or prompts, so the once-per-session funnel line in tool output is the only attribution that reaches the agent. In the browser, each page load is one session.

Verification

• Installed into the site from an npm pack tarball (so the files and exports filters apply): the site's build and CSP suites pass.
• npm test: 54 pass on Node 24 and Node 18. The new test/browser.test.js:
  • walks the browser import graph for node: imports;
  • checks the WebMCP tool list matches the stdio server's exactly;
  • covers input validation, the skip-on-reject path, and the per-registration funnel.
• End to end, in a real WebMCP browser: Playwright's Chromium 153 with --enable-experimental-web-platform-features exposes a native model context. Against a local build of the site, all 11 tools registered, triage_sync_vs_async executed, and there were no CSP violations once zod was jitless.

For the owner: data license

The site serves a gzip re-encoding of book.json.br at /webmcp/book.json.gz so the browser tools can read it. DATA-LICENSE.md permits use "solely as part of operating the @open-and-async/mcp software", which this arguably is, but it's still a second hosted copy. As the licensor, you may want the license to name the site explicitly. The README now says the browser entry point exists for open-and-async.com and that the license doesn't cover other sites hosting the data.

Releasing

The site PR depends on 1.1.0 being on npm. Publishing still goes through the tag and the release approvals. Nothing here tags or publishes.

🤖 Generated with Claude Code