Re: [w3ctag/design-reviews] Incubation: WebMCP (Issue #1238)

yoavweiss left a comment (w3ctag/design-reviews#1238)

I wasn't on said call, but I find the following odd:

> why is our solution shaped like an explicit capability layer / agent pathway to site code, as opposed to just "more HTML semantics" to help agents do everything through the UI?

To me, this feels similar to asking "why do we need JS? Can't we just have HTML semantics that define everything that developers will want to do?"

As someone deploying WebMCP (under an Origin Trial in various Chromium browsers) to a large number of storefronts, I don't see a feasible declarative alternative to the imperative tools that agents can call.
Even if we were to embark on a multi-year journey to define some of these semantics (e.g. an "add to cart" button being able to communicate that semantic to the browser) that doesn't cover the full range of tools developers are now using in the very-early, pre-release versions of this API. 

If I'm looking at Shopify storefronts, we currently have tools to browse store collections, manage orders, search catalog, navigate to a product page, show a variant of product, search the store policies and many more. That list is bound to expand and evolve in the near future.

The list of tools is likely to be somewhat different for non-Shopify merchant sites., and likely to be extremely different for non-commerce use cases. So I don't see how defining all these possible semantics upfront and codify them as built-in HTML elements would work.

I can see a future where we're paving some of the common semantic cow-paths, but that won't cover everything developers need *right now*.
I can similarly see us provide a way for web components to describe their semantics and work better with Agents, but I wouldn't consider this a replacement for imperative actuation. It'd effectively require us to develop a new actuation language and/or add extremely verbose tool descriptions into our markup. It'd also require any developers that want to take advantage of these capabilities to move their sites to use web components, which is bound to be a hurdle to adoption and a contentious point.

So, while these future evolutions are options we may want to consider, IMO we shouldn't think of them as alternatives to WebMCP, but as complementary options.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1238#issuecomment-5329869437
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1238/5329869437@github.com>