Update README with refined definition of headless usecases

[sdras]

We have seen some confusion around headless usecases, so this PR refines the definition to be more clear about when WebMCP can be used for headless, and potentially headless combined with human in the loop experiences.

[anssiko]

Appropriate clarification. Designed for human-in-the-loop workflows does not mean we’d exclude applicable headless use.

[domfarolino]

Thanks for clarifying this, @sdras! To add more color the OP, there's fundamentally no reason what we're developing in this specification is inappropriate for headless scenarios. A native (non-in-page) agent can choose to actuate a browser however it wants, be it by injecting content scripts into the page directly from the product, or even by actuating the browser through whatever headless protocol the browser offers, such as Chrome DevTools Protocol, or drivers like chromedriver and safaridriver.

Each of these may offer an agent that lives outside of web platform a view into an invisible page's WebMCP tools. Usage through any of these means—UI or no UI—is entirely transparent to the tools, and our thinking is that the tools do not need to be designed with each entry point in mind. In fact, that is intentional by design: a tool shouldn't need to know whether it's being run via CDP on a remote ChatGPT VM, or in a real user's local browser session with a visible agent helping them actuate a visible page (or anything in between).

What we're not doing, however, is specifying the headless protocol that facilitates an agent reaching the browser and its WebMCP tools in any way outside of web platform APIs. Exactly how a browser chooses to expose web platform WebMCP tools to a native agent or to the outer world intentionally remains implementation defined. That is, this specification has no opinion, dependency, or knowledge of specific headless driver protocols like CDP et al.