Should concurrent execution by multiple Agents be allowed?

[khushalsagar]

Since we've been discussing that there can be multiple Agents that can use a site's declared functionality, one question is can that happen in parallel. I'd say no, it'll be an extremely rare case and makes the execution unnecessarily complicated for the site. The simple thing to do is for the browser to abort existing tool executions from the current Agent if the user wants to allow another Agent to connect.

[MiguelsPizza]

+1

I can see a world where tools with a readonly annotation are able the be executed by multiple agents concurrently, but it's probably a premature optimization for a problem that does not exist yet.

[khushalsagar]

@reillyeon made an interesting point at TPAC. Since we're thinking of agent-to-agent, we'd likely want the browser Agent to be able to delegate tasks to in-page Agent. #31 is one idea of simple agent to agent.

From an API perspective, the in-site Agent execution in this case is likely opaque to WebMCP but just mentioning as something worth thinking through.

[43081j]

i think this is solved the same way as i explained in #47 - i.e. not our concern

even if a tool is going to use an in-page agent, that is just something the tool can call and wait for before resolving itself. we don't need to be concerned with tool author's implementation details like that IMO

[SuperPauly]

Thoughts For Website MCP – A Solution?

Before diving into the protocol details, it is crucial for me to establish a claim why I think this is a (better for everyone) need.
And a standardized "Website MCP" working group or specification is a solution for a few problems which I'll explain below. That is unless one already exists? that I've not come across 🤔...

But if none do exist then here is the where, what & why I think it's better for business, compliance, end users, advertisers, developers and/or server admins, security teams/admin and possibly ops and marketing.

• Where: Website MCP sits at the application layer, acting as the bridge between the User's AI Agent (Client) and the Website's logic (Server). It lives in the negotiation phase between a browser and a server, distinct from but complementary to existing browser APIs.
• What: It is a standardized interface specification that allows websites to declare "I am agent ready." It defines the tools, resources, and operational policies (concurrency, data types, LLM delegation) that an external agent can utilize.
• Why:
  • Standardization vs. Fragmentation: Without a standard, every website builds custom API wrappers, limiting agents to specific, hardcoded integrations.
  • Safety & Control: As discussed in this issue, websites need granular control over how agents interact managing concurrency, enforcing serial execution, and protecting infrastructure from "agent swarms."
  • The Agent Economy: It unlocks the ability for generic agents to interact with any website that implements the spec, creating a truly interoperable web of agents.

---

Proposal: Advanced Website MCP Handshake & Enhanced Tool Data Type Support

This proposal builds on the discussion from issue (#31) by expanding not just protocol level coordination and concurrency, but also the nuanced control over data types, formats, and LLM responsibility within WebMCP's site_mcp_spec.json.

Website MCP Handshake with Capabilities Negotiation

We propose a handshake protocol on Agent connection (WebSocket/AJAX/WebRTC), during which the Website MCP server pushes a site_mcp_spec.json. The WebMCP client echoes this spec to confirm receipt and acceptance, enabling:

1. Granular Concurrency and Topology: The spec can define which tools must run serially, which can safely execute in parallel, and the overall concurrency limits.
2. Dynamic State & RBAC: The handshake enables dynamic tool exposure based on user session state, authentication, and API quotas.
3. Infrastructure Protection: The server can enforce hard limits on parallel threads to mitigate DoS.
4. Compliance & Deterministic Execution: The spec can declare tool dependencies/orderings.
5. Live Policy Updates: The server can update specs to handle outages or maintenance.
6. Trust, Provenance, Versioning: The echoed spec provides an auditable contract.
7. Server Internal A2A/MCP Use: What of the server offers external MCP or A2A tools that are a premium depending on your Role and Authorisation? A simple use case of this would be federated login via GitHub with the Models permission would give you access to LLMs & GitHub MCP via GitHub but if you logged in via Google then you only get access to Gemini.

Improved Data Type & Format Negotiation for Tool Inputs

Going further than A2A coordination, the Website MCP should also declare in site_mcp_spec.json:

• Accepted Data Types & Formats for Tools: Specify which data types (text, audio, image, video) and formats (mp3, pdf, webp, etc.) are supported per tool.
• Tool Chaining for Macro Tools: Specify data types and formats for each step in complex macro chains. So the admin/dev decides which tools to chain together to accomplish common tasks carried out on there platform and can have granular control of which tool in that chain should be called in serial or parallel and if tools 2,4 and 7 out of 9 tools in a Macro Tool or Tool Chain run in parallel, what's the max limit that parallel tool can be called.

LLM Policy Negotiation: Client vs. Server Intelligence

A critical question is where the tool parameters are generated. Does the Website have an LLM, or does the Client (Web MCP)?

We propose adding an llm_policy object to the spec to negotiate this responsibility:

• Scenario A: Delegation (Clients Side Intelligence)
  The website has no LLM but exposes tools. It requests the Client's WebMCP LLM to generate tool parameters and execute them.
• Scenario B: Compliance (servers side Enforcement)
  The website requires that its own trusted LLM generates parameters for sensitive tools, or requires data from an unauthorised source on available on the server (Like a user row from a DB) to populate the params for this sensitive tool call, ignoring clients generated params as they'll not all be correct.
• Scenario C: Hybrid/Negotiated
  Both sides have LLMs; the spec defines a preference or requirement.

Very rough & basic example! of site_mcp_spec.json addition:

{
  "llm_policy": {
    "preferred_source": "client", 
    "allowed_sources": ["client", "server"],
    "enforce_source": null, // or "server" for strict compliance
    "traceability": true // require audit log of which LLM generated the call
  },
  "tools": [
    {
      "name": "search_inventory",
      "llm_source": "client" // Delegation: Client LLM figures out the search query
    },
    {
      "name": "execute_refund",
      "llm_source": "server" // Strict: Only Server LLM can trigger this based on context
    }
  ]
}

This ensures that websites without AI infrastructure can still be "Agents ready" by leveraging the user's browser/client model, while secure sites can enforce strict servers side logic.

I just feel this would speed up adoption for enterprise, corporate and businesses given the granularity control, compliance friendly rule based approach that makes security, logging and monitoring much easier and security teams/admins would be able to check and red team Tool Chains and RBAC and gives the website/service owner more control around how people and LLMs use their systems.

Website devs could create extremely long 50 or 100 Macro Tool Chains that run in on go using a mix of serial and parallel for different tools and accomplish very complex tasks that a LLM with WebMCP with access to 50 or 100 Tools would struggle to achieve a the same determinist result as Website MCP would achieve.

Dev teams can release new Tool Chains fairly rapidly enabling quick offerings of new services, features and upgrades for their website with Website MCP, if the Tools are granular enough.

###TLDR

Combining a handshake based session contract for concurrency, data types, and LLM policy gives Website Owners flexibility. It allows a site to be "dumb pipes" (using client side LLMs) or a "fine tuned smart backend" (enforcing server side fine tuned LLM), all defined clearly in the handshake. Can combine a large amount of small and larger tools in a Tool Chain that will always run in order, enables RBAC auth and much more.

References: #31 – A2A Interaction & Coordination

Thoughts?