Communication with the TAG

[xiaochengh]

The TAG learned about the WebMCP proposal during our F2F meetings in 2025/09.

According to The Extensible Web Manifesto:

Browser vendors should provide new low-level capabilities that expose the possibilities of the underlying platform as closely as possible. They should seed the discussion of high-level APIs through JavaScript implementations of new features (as done in the cases of Mozilla’s X-Tags and Google’s Polymer). This involves web developers in the process and by iterating outside of the browser, avoids the platform getting stuck with bad APIs.

AI agent protocols (MCP, A2A, ANP and etc.) are still new and under rapid evolution, and sometimes introduce breaking changes. Therefore, the TAG think it's too early to port any specific protocol directly to the web platform.

Alternatively, is it possible to add some general lower-level capabilities to the web platform first, and then support specific protocols (including but not specific to MCP)?

[anssiko]

Thank you for the question. Despite the name, the aim of the WebMCP proposal is to avoid tight coupling, and keep the API surface as protocol-agnostic as possible. We have documented our current thinking here.

In this context I'd like to let you know this group is chartered to coordinate with the AI Agent Protocol Community Group to ensure also other emerging agentic protocols are considered in the design. This coordination topic on our TPAC F2F agenda webmachinelearning/meetings#35 and you are welcome to join that discussion. For substantive contributions, I encourage you to join the group.

Please indicate if this addresses your question. My recommendation is we follow-up in topic-specific issues as appropriate.

[khushalsagar]

Also see #25 for a more detailed explaination of how this proposal intersects with MCP. I've put up #36 to document this.

@xiaochengh does the API design sound reasonable? Is it just a naming issue, maybe WebMCP makes it sound like the API is very tightly coupled with MCP.

[xiaochengh]

@anssiko @khushalsagar Thanks for the prompt response, and especially for clarifying the relationship with MCP, which helps a lot!

We find the use cases very interesting, and would like to see them properly supported. We are also discussing it and will provide more comments later.

[anssiko]

Thank you @xiaochengh. I have renamed this issue to better reflect the thrust of this issue.

[xiaochengh]

Sorry in case of ambiguity... We found the use cases interesting, but still have some comments on the API design. We'll post it later.

[khushalsagar]

@xiaochengh do take a look at the API clarification here. I'm looking forward to the feedback.

Also, if TAG would prefer that we file a design review I'm happy to do that. I wasn't sure if it's too soon for it.

[xiaochengh]

@khushalsagar Thanks for the pointer! I've already read the section.

TAG would prefer that we file a design review I'm happy to do that. I wasn't sure if it's too soon for it.

Of course, an incubation review should help a lot.

And we are already engaged in the conversation anyway :)

[anssiko]

I will schedule time from our TPAC F2F to discuss TAG design review expectations.

@xiaochengh, please propose participants from the TAG who would like to take part in that discussion.

[xiaochengh]

Sure, let me check with the others of the TAG

[marcoscaceres]

I'd be interested in attending this as part of the TAG

[xiaochengh]

Hi @anssiko and @khushalsagar

There's a lot of discussion at the TAG on WebMCP recently and below are what we found:

• Motivation. Frontend agent integration (as opposed to backend integration in your terminology) is useful and should be supported on the Web. We encourage further exploration in this area.

• Generality. Whatever the WebMCP efforts introduce to the web standards should be general enough to support different protocols, not just MCP or something MCP-like. We appreciate the involvement of the AI Agent Protocol CG and would like to see more progress in this direction.

• Privacy and Security. The P&S aspects can be challenging, and we would also like to see more explorations.

• Declarative API. A declarative API can be quite useful and cover use cases that an imperative API can't cover, and hence we would like to see more explorations in this direction - particularly as MCP might need to interface with the OS statically (i.e., without the web application running)

Example: Consider a search engine scenario, where the user is facing a search result page. Some of the search results have defined endpoints so that the user can further interact with them without navigating to the search result. Such use cases can only be supported if the search results expose their endpoints declaratively.

---

However, the TAG couldn't reach consensus on how generality should be achieved. There are two different opinions:

1. WebMCP should be built bottom-up on lower-level primitives. We will identify the missing lower-level capabilities and introduce them to the web standards, while the high level APIs can be introduced via e.g. a JS library for now
2. WebMCP should be directly introduced to the web standards as a high-level API that's general enough to support different protocols

In either way, we are not trying to block, but instead would like to encourage further development of the high-level API that the WebML WG is currently working on.

[khushalsagar]

Agreed on most of the points raised above. Some questions below on the ones where we could use more clarity.

Whatever the WebMCP efforts introduce to the web standards should be general enough to support different protocols, not just MCP or something MCP-like. We appreciate the involvement of the AI Agent Protocol CG and would like to see more progress in this direction.

I don't think what we have is tightly coupled with MCP, it's only reusing the syntax for the base primitives (tools) from MCP. And that was because we expect MCP compatible clients to be a common consumer of the functionality. This would be a good topic to dig into at the TPAC f2f.

WebMCP should be built bottom-up on lower-level primitives. We will identify the missing lower-level capabilities and introduce them to the web standards, while the high level APIs can be introduced via e.g. a JS library for now

Can you give an example of what the lower-level primitives?