Make your software callable by AI agents.

MCP is an open protocol that standardises how AI applications connect to external tools and data. Instead of writing a bespoke integration for every model-and-system pair, you build one MCP server per system and any compliant host — Claude, ChatGPT, an IDE, or your own agent — can discover and call it. It turns an N × M integration problem into an N + M one, which is the same reason people standardised on ODBC, LSP, and OpenAPI before it.

WebMCP takes the same idea and moves it into the browser. Rather than running a server that an agent connects to over the network, your web page registers tools directly on document.modelContext, and an agent running in the browser can list and call them inside the user's existing session.

The practical difference is authentication and integration cost. An MCP server needs its own credentials and its own deployment. A WebMCP tool inherits the cookies, SSO session, and permissions the human already has on the page — so the agent can only ever do what that person could do by clicking. It is the fastest path to making an existing web app agent-operable.

Not yet, and we are direct with clients about that. WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group — explicitly not a W3C Standard and not on the Standards Track. Chrome shipped an implementation and has been running origin trials; Microsoft co-authors the spec; Firefox and Safari are engaged but have not committed to timelines.

The API surface has already moved once — from navigator.modelContext to document.modelContext — which is exactly what you would expect from a spec at this stage. We therefore build WebMCP behind a thin adapter with feature detection and a graceful no-op fallback, so a spec change is a small, contained edit rather than a rewrite.

2026-07-28, the current revision. It is the most substantial change to the protocol since authorization was added: the transport became a stateless request/response protocol with no protocol-level sessions and no Mcp-Session-Id, so any instance behind an ordinary load balancer can answer any request.

It also added multi round-trip requests for mid-call confirmations, moved method and tool names into Mcp-Method and Mcp-Name headers so gateways can route and authorize without parsing JSON bodies, made list results cacheable with ttlMs and cacheScope, and formalised Tasks, MCP Apps, and Enterprise Managed Authorization as extensions rather than core features.

Mostly transports and authorization. The legacy HTTP+SSE transport is deprecated, as are Roots, Sampling, and Logging — each with a minimum twelve-month support window, so you have time but not indefinite time. On the auth side, Dynamic Client Registration gives way to Client ID Metadata Documents, and RFC 9207 issuer validation becomes a requirement rather than a good idea.

Our migration engagement is a fixed-scope audit: we run your server against the current spec and the Tier 1 SDKs, produce a prioritised diff, and then do the work. Most servers are a week or two of engineering; the interesting findings are usually in authorization, not transport.

It is safe when the MCP server is treated as a policy layer rather than a passthrough. The dangerous pattern is handing a model one broad API key and a hundred tools. The workable pattern is per-tool scopes, verified identity on every request, human confirmation on destructive or costly actions, hard rate and spend caps, and a structured audit log for everything.

The failure mode people underestimate is indirect prompt injection: instructions hidden in content your tools return — a ticket body, a scraped page, a document — that the model then follows. We handle that with the untrustedContentHint and readOnlyHint annotations, by keeping privileged tools away from unvetted text, and by adversarially testing the deployment before it goes live.

A focused first server — one system, a handful of tools, real authorization, deployed and observable — is typically three to six weeks. A gateway serving several internal servers with a shared policy layer and registry runs longer. WebMCP tool layers on an existing web app are usually faster, because there is no new backend to stand up.

We scope fixed-fee where the boundary is clear and run a discovery sprint first where it is not. Start with the software cost calculator for a rough envelope, then talk to us for a real number.

The Tier 1 MCP SDKs — TypeScript, Python, Go, and C# — plus Rust where a team is already there. In practice most of our servers are TypeScript or Python, deployed as ordinary containers on whatever you already run: AWS, GCP, Azure, Fly, Cloudflare, or your own Kubernetes. Because the 2026-07-28 core is stateless, no special session-affinity infrastructure is required.

Yes, fully, and it lives in your repository from the first commit rather than being handed over at the end. You get the source, the infrastructure definitions, the eval suite, the runbook, and thirty days of post-launch support. We are frequently retained afterwards to extend the tool surface, but nothing about the engagement depends on that.

If the value is in your data and back-office systems, and the consumers are AI hosts your team or your customers already use, build the MCP server. If the value is in your web product and you want an agent to be able to operate it the way a person does, start with WebMCP — it is cheaper, requires no credential design, and works within permissions you have already modelled.

Plenty of teams end up wanting both, and they compose cleanly: the same tool inventory and the same authorization model can back a network-facing server and an in-page tool layer.