MCP, WebMCP, and conversational interfaces: what comes next

What is MCP, and why does it matter for agent-native software?

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to tools and data. Build your product’s capabilities once as MCP tools and any compatible agent can use them.

Anthropic introduced MCP in November 2024 and donated it to the Linux Foundation’s Agentic AI Foundation on December 9, 2025, so it now has vendor-neutral governance ^[6]. The published 2026-07-28 specification describes stateless, self-contained requests with per-request capability negotiation, and lists Tasks, Skills over MCP, and MCP Apps as optional extensions ^[1]. The release post adds a formal extensions framework and hardened authorization ^[2].

For product teams, MCP is the “Act” layer in the anatomy of an agent-native product. It is where parity, scoped authority, and receipts get implemented.

What are MCP Apps?

MCP Apps is the first official extension to MCP. A tool can return an interactive HTML interface, declared ahead of time, which the host renders in a sandboxed iframe inside the chat ^[3].

It went live on January 26, 2026, and the announcement names Claude, ChatGPT, Goose, and Visual Studio Code among supporting clients ^[3]; coverage varies by client. This is what makes conversation functional: the agent can ask for a date range in plain language, then show a real picker, a diff, a chart, or an approval card when precision matters.

What is WebMCP?

WebMCP is a proposed browser API that lets a web page expose JavaScript functions as tools to AI agents. It is a Draft Community Group Report from the W3C Web Machine Learning Community Group, authored by people at Google and Microsoft. It is not a finished standard ^[4].

The proposal describes an imperative API, where the page registers tools in JavaScript, and a declarative approach for standard actions defined in HTML forms. Tools run in the page, in the user’s own session, and the browser mediates consent ^[4]. Secondary reports say Chrome began an early preview in February 2026; support in other browsers is unconfirmed.

navigator.modelContext.registerTool({
  name: "add-to-schedule",
  description: "Add a session to the attendee's personal schedule",
  inputSchema: {
    type: "object",
    properties: { sessionId: { type: "string" } },
    required: ["sessionId"]
  },
  async execute({ sessionId }, agent) {
    await agent.requestUserInteraction(() => confirmDialog(sessionId));
    return { content: [{ type: "text", text: "Added " + sessionId }] };
  }
});

MCP, MCP Apps, WebMCP, and the rest: which is which?

They are complements. A server-side MCP tool works when no browser is open. A WebMCP tool works because the user is already signed in and looking at the page. Many products will want both, backed by the same business logic.

Will conversational interfaces replace forms?

No. Conversation is best for stating intent and exploring options. Structured UI is best for review, precision, and commitment. Design the conversation as an additional front door, with the form still there as the place to verify and the fallback when talking is slower.

Forms are not a failure mode; they are compressed knowledge about what a system needs. A conversational layer that discards that knowledge produces ambiguity, so the better pattern is to use conversation to fill in the structure.

How do you make a conversational interface functional, not just chatty?

Put the same tools under both the chat and the UI, have the agent produce a structured proposal, and require a visible confirmation before anything irreversible. These six patterns are design guidance, not a standard.

1. One set of tools. The chat, the buttons, and any outside agent all call the same operations. If the chat can do something the UI cannot (or the reverse), you have two products.
2. Intent in, proposal out. The user says “move the keynote to Thursday.” The agent returns a typed change set (what, where, what it affects), not a paragraph.
3. Chat plans, UI commits. Render the proposal as an approval card with a diff. The user confirms with a click. This is where MCP Apps earns its keep.
4. Dry-run before write. Every costly or destructive tool supports preview, so the proposal is real, not a guess.
5. Keep the escape hatch. Every conversational flow links to the equivalent form with fields pre-filled. Power users and edge cases need it.
6. Receipts and undo. After the action, show what happened, who did it (human or agent), and how to reverse it.

What should you do this quarter?

1. Publish /llms.txt and Markdown versions of your key docs.
2. Expose your single most-used workflow as an MCP tool with a schema, dry-run, and idempotency key.
3. Add structured errors and receipts to that workflow.
4. Add one approval card via MCP Apps for the riskiest action.
5. Prototype WebMCP behind a flag on one page, and treat it as an experiment.
6. Test with real agents. Watch where they fail, and fix the interface, not the prompt.

See how we apply this in the shipped examples, then score your own product.

What is still uncertain?

• WebMCP’s API surface. Secondary sources disagree on whether the entry point is navigator.modelContext or a document-level property, and the official proposal page uses an older shape. Check the spec.
• Browser support. Chrome’s preview is reported; Firefox and Safari commitments are not confirmed in the sources we found.
• MCP Apps host coverage. Support varies by client and is changing quickly.
• Standards drift. MCP’s 2026-07-28 release deprecates Roots, Sampling, and Logging (deprecated, not removed) ^[2]. Build against the current spec, not a blog post.