Add webmcp-core: zero-dependency navigator.modelContext polyfill (2.94KB)

[up2itnow0822]

Following the suggestion from @domfarolino in webmachinelearning/webmcp#127 — filing here as requested.

webmcp-core

A community polyfill implementing the navigator.modelContext API surface for environments without native WebMCP support.

Key properties:

• 2.94KB zero-dependency ES module (no build tools required)
• Implements navigator.modelContext.registerTool(), tool invocation lifecycle, and context management
• Feature-detects native browser support — defers to native when available (Chrome 146+)
• SSR-safe with typeof navigator guards
• Drop-in script tag or ESM import

Package: @webmcp/core (npm)
Source: WebMCP-org/npm-packages

Happy to add any information that would help the listing. Thanks for the redirect!

[anssiko]

Possible collaboration with @mcp-b/webmcp-polyfill discussed in WebMCP-org/npm-packages#147 (comment)

[up2itnow0822]

Thanks for the pointer, @anssiko — read through the thread with @MiguelsPizza carefully.

The core observation from that discussion: webmcp-core and @mcp-b/webmcp-polyfill implement the same spec surface, and maintaining two separate polyfills risks fragmenting the community. That's a fair point and I agree with it.

We're open to two paths here:

Option A — Contribute to @mcp-b/webmcp-polyfill directly
If the goal is a single canonical community polyfill for the W3C WebMCP spec, we'd rather contribute to @mcp-b/webmcp-polyfill than maintain a fork. We can bring the 2.94KB optimization work and our payment metadata additions as PRs. The spec should have one reference implementation, not two.

Option B — webmcp-sdk as a higher-level developer toolkit
If there's space for a separate listing, it would be for webmcp-sdk (not webmcp-core) — which is a developer toolkit built on top of the polyfill: agent payment flows, x402 integration, testing utilities, and React bindings. That's genuinely a different layer from the polyfill itself.

Happy to pursue either direction based on what's most useful for the community. If Option A is the right call, I'll open PRs against @mcp-b/webmcp-polyfill this week. If there's a path for a higher-level toolkit listing, I'd like to understand what the bar looks like.

Also — would love any guidance on spec alignment. One thing that came up: the provideContext() / registerTool() separation. We've read the current spec draft but want to make sure our implementation tracks any pending changes before contributing upstream. Is there a good place to follow active spec work beyond the GitHub issues?

[DavidMulder0]

Just want to put out there that webmcp-core seems like a misleading project, as it seems like a spec-shaped wrapper around a crypto product implementing a non-standard version of the spec. This project would be much improved if it was called webmcp-coinbase-x402 or something along those lines, although I am unsure who would benefit from such a project.

[up2itnow0822]

Thanks for the feedback, @DavidMulder0 — appreciate you raising this.

A few clarifications:

1. Spec alignment: webmcp-core implements the W3C WebMCP spec surface exactly — navigator.modelContext, registerTool(), tool invocation lifecycle, context management. It's feature-detective and defers to native Chrome 146+ when available. No custom extensions.

2. The x402/payment piece: That's a separate layer (webmcp-sdk) built on top of the polyfill, not part of the polyfill itself. The SDK adds payment flows, agent identity (ERC-8004), and x402 integration. The polyfill is payment-agnostic.

3. Naming: Totally fair point on potential confusion. We'd rather contribute to @mcp-b/webmcp-polyfill as a unified community polyfill (per the discussion with @anssiko). The 2.94KB optimization work could be a PR to that project rather than a separate listing.

Would you prefer we close this issue in favor of consolidating around @mcp-b/webmcp-polyfill? That seems like the cleanest path to avoid fragmentation.

[up2itnow0822]

@anssiko Thanks for flagging the collaboration opportunity. Will check the WebMCP-org discussion.

@DavidMulder0 Fair point on naming. You're right that webmcp-core as a name implies it's the canonical spec implementation, which it isn't. The x402 payment integration is one specific application built on top of the MCP transport - not the core spec itself.

We've since split things out more clearly:

• webmcp-sdk (v0.5.6) - the W3C MCP toolkit, spec-aligned
• webmcp-id (v1.0.0, just published) - W3C DID-based agent identity, zero blockchain dependency
• agentpay-mcp - the x402 payment layer, clearly named as a payment product

The identity package (webmcp-id) is pure W3C standards: DID Core 1.0, Verifiable Credentials 2.0, DNS-based discovery. No crypto rails involved. That might be more aligned with what this list is looking for.

Appreciate the honest feedback on the naming confusion. It's a valid concern and the split naming addresses it.