Early Feedback from the Angular Team
Doug Parker
Hi WebMCP folks!
I have been looking into an integration within Angular, with the goal of making it really easy and straightforward for applications to create WebMCP tools (prototype, internal design doc). I'm still learning and exploring the spec myself, but wanted to share some early feedback as soon as I could. I'll try to sort these sections somewhat and keep it as brief as I can:
Form Submission Should Trigger a change Event
The biggest "showstopper" issue I found is that the <form toolname="..."> integration straight-up doesn't work with Angular and I don't see a way it could be made to work. Our forms system works by reading change or input events from <input> elements, with the source of truth being maintained in JavaScript objects. AFAICT, WebMCP does not emit any kind of usable event notifying the application that a form was modified. No change or input event is triggered, meaning we don't see this change and completely ignore it (video example).
I tried several workarounds, but none of them quite worked. toolactivated is triggered after form submission. agentInvoked only tells us an AI participated when the form is submitted, not when the form is filled out without toolautosubmit. monitorEvents($0) did not indicate any other event triggering. Unless I'm missing something, I think the only real "fix" on the Angular side would be to regularly poll every form field every X seconds, which just isn't practical.
I don't think this limitation is unique to Angular and worry that this breaks the feature for basically any application which uses JS as its source of truth for a form. I understand that's probably not the intended use case of this feature overall, but I think simply emitting a change event would be both semantically accurate (the value definition changed) and sufficient to work for the vast majority of JS-driven form systems.
Reactive Forms Use Cases
I spent a good amount of time experimenting with better supporting the <form toolname="..."> use case for Angular (ignoring the above problem temporarily), but ultimately have come to the conclusion that it's probably not a great fit for Angular and JS frameworks more broadly.
Driving forms systems from models in JS means the rendered <form> / <input> elements are potentially just one consumer of a more expressive form model known to the framework. The simplest example I can think of is adding a list of users. The <form> element might only have one <input> for a username, but there are other controls on the page to add more users and generate more <input> fields dynamically. In practice, these might just have name="username0" and name="username1", but in the core data model, this is something closer to users: Array<{ username: string }>. Having the WebMCP tool consume the rendered HTML instead of the original form model is inherently limiting to what we can express. I would want the AI to be able to understand that it can fill out multiple users at the same time and not have to click "Add User" twelve times in order to populate the input schema of the MCP tool before then invoking that tool with all twelve users.
This can also include use cases which don't strictly use <input> elements to capture user data. Developers might create custom controls for inputting complex data, and since they rely on the framework form system for managing and rendering that content, they don't strictly need <input> elements to achieve that goal. Any such field would be invisible to the AI using an automatically generated WebMCP tool.
This is a long-winded way of saying that our current belief is that the declarative API is not a great fit for Angular in particular (potentially any JS-driven form system more broadly) and that a better approach is to take Angular's view of the form's data model (Array<{ username: string }>) and attempt to translate that into an implicit tool via registerTool directly, instead of using this declarative API. More investigation is needed to figure out exactly what that looks like and whether the framework has the information and hooks necessary to present a more comprehensive WebMCP tool for less developer effort. I understand frameworks like Angular probably weren't the original intended use case for the declarative API, but I just wanted to call this out more directly as it is probably our most interesting take away from this experiment so far.
Potential Additional Features
Some potential future features which I imagine were intentionally out of scope, but I'll share anyway to provide the relevant use cases.
agentconnected event: I found myself kind of wanting an agentconnected event to tell the page that an agent who cares about WebMCP is ready and that the page should register any relevant tools. This could support lazy-loading tool schemas, though I'm personally skeptical that's a great design pattern anyway, as I suspect the performance hit of lazy-loading a bunch of disparate definitions would probably outweigh the initial load bundle size savings they would give.
toolactivated on the <form>: I was surprised to find that toolactivated triggers on the window with a form name. This requires the page to do extra work to map this back to the form in question if it is going to take any action. Would it be possible to dispatch this event on the <form> element directly? I feel like that would be much more ergonomic for the page.
Pre-submit validation errors: I appreciate that SubmitEvent.prototype.respondWith is a great hook for returning any errors which were found with form validity or during submission, but the AI won't get this information by default when filling out a form with no toolautosubmit. I suppose in the real implementation, the UI would likely update with any form errors and the AI would read the DOM to learn those issues, but that seems like it would introduce a lot of noise. I'm curious if there's a path towards some kind of independent formpopulated event, telling the page that content was filled out (independent of the change event I requested above) and possibly coming with its own respondWith function which the page can use to communicate back any validation errors directly. This could help the AI fix its mistakes or iterate through the process a couple times and resolve errors before sending control back to the user.
Implicit support for forms: This is more product feedback than spec feedback, but one of my goals for Angular is to make this work with as little effort as possible (ideally none) and I really like the idea of making existing <form> elements support their own implicit WebMCP tools without requiring developers to make any changes to their existing code. The idea of unlocking WebMCP support for millions of existing <form> tags is really enticing to me. The current implementation seems pretty close, but falls just short because of the need for an explicit toolname. I understand that a good name probably isn't super obvious, but I suspect a decent amount of DOM scraping / SEO-style indexing (look for an h* tag nearby or something) might be able to give at least a suggested name / description for the form, and we already have <label> elements or aria-describedby for parameter names. If we could get the required developer work down to zero, that can unlock a huge amount of potential for the ecosystem.
API Confusion
Some general questions / points of confusion I had about the API structure. This might just be limitations in my own understanding, but I wanted to share in case it might be indicative of ways we can improve future documentation or potentially tweak the names / semantics of some of these concepts.
agentInvoked without toolautosubmit: I was surprised to find that agentInvoked is true, even if toolautosubmit is not set. In my mind, I'm equating "invoked" to "submitted". Maybe that's not the right mental model, but I wonder if agentPopulated or agentParticipated might be more accurate? Alternatively, maybe agentInvoked actually should only be true when the agent directly submits the form?
Cancelling requests: Is there a way to receive a cancel event from the agent? If the user cancels the agent, then I would expect that to flow down into an AbortSignal on the actual execute function. toolcancel only seems to support the declarative API if I'm reading the documentation correctly.
Bugs
The only potential bug I found in the implementation is that the execute function does not bind this when it is invoked. At one point I tried:
class MyTool {
value = 'test';
readonly name = 'foo';
readonly description = 'Does foo';
readonly inputSchema = {type: 'object', properties: {}};
async execute(): Promise<WebMcpToolResult> {
return {content: [{type: 'text', text: this.value}]};
}
}
window.navigator.modelContext.registerTool(new MyTool());
But I found this fails with "Cannot read properties of undefined (reading 'value')". I think the invocation should bind the execute function to the provided tool object, so we can reference this safely. I'd file a bug, but Buganizer claims I don't have permission (even as a Googler!).
That's all the major points of feedback I have right now, I'll be sure to share more as we continue to learn about this problem space. Thank you all for driving this effort, I'm really excited for the overall direction of WebMCP!
François Beaufort
Hi Doug,
Thank you very much for the detailed feedback! Please see my comments inline:
Hi WebMCP folks!
I have been looking into an integration within Angular, with the goal of making it really easy and straightforward for applications to create WebMCP tools (prototype, internal design doc). I'm still learning and exploring the spec myself, but wanted to share some early feedback as soon as I could. I'll try to sort these sections somewhat and keep it as brief as I can:
Form Submission Should Trigger a change Event
The biggest "showstopper" issue I found is that the <form toolname="..."> integration straight-up doesn't work with Angular and I don't see a way it could be made to work. Our forms system works by reading change or input events from <input> elements, with the source of truth being maintained in JavaScript objects. AFAICT, WebMCP does not emit any kind of usable event notifying the application that a form was modified. No change or input event is triggered, meaning we don't see this change and completely ignore it (video example).
I tried several workarounds, but none of them quite worked. toolactivated is triggered after form submission. agentInvoked only tells us an AI participated when the form is submitted, not when the form is filled out without toolautosubmit. monitorEvents($0) did not indicate any other event triggering. Unless I'm missing something, I think the only real "fix" on the Angular side would be to regularly poll every form field every X seconds, which just isn't practical.
I don't think this limitation is unique to Angular and worry that this breaks the feature for basically any application which uses JS as its source of truth for a form. I understand that's probably not the intended use case of this feature overall, but I think simply emitting a change event would be both semantically accurate (the value definition changed) and sufficient to work for the vast majority of JS-driven form systems.
Reactive Forms Use Cases
I spent a good amount of time experimenting with better supporting the <form toolname="..."> use case for Angular (ignoring the above problem temporarily), but ultimately have come to the conclusion that it's probably not a great fit for Angular and JS frameworks more broadly.
Driving forms systems from models in JS means the rendered <form> / <input> elements are potentially just one consumer of a more expressive form model known to the framework. The simplest example I can think of is adding a list of users. The <form> element might only have one <input> for a username, but there are other controls on the page to add more users and generate more <input> fields dynamically. In practice, these might just have name="username0" and name="username1", but in the core data model, this is something closer to users: Array<{ username: string }>. Having the WebMCP tool consume the rendered HTML instead of the original form model is inherently limiting to what we can express. I would want the AI to be able to understand that it can fill out multiple users at the same time and not have to click "Add User" twelve times in order to populate the input schema of the MCP tool before then invoking that tool with all twelve users.
This can also include use cases which don't strictly use <input> elements to capture user data. Developers might create custom controls for inputting complex data, and since they rely on the framework form system for managing and rendering that content, they don't strictly need <input> elements to achieve that goal. Any such field would be invisible to the AI using an automatically generated WebMCP tool.
This is a long-winded way of saying that our current belief is that the declarative API is not a great fit for Angular in particular (potentially any JS-driven form system more broadly) and that a better approach is to take Angular's view of the form's data model (Array<{ username: string }>) and attempt to translate that into an implicit tool via registerTool directly, instead of using this declarative API. More investigation is needed to figure out exactly what that looks like and whether the framework has the information and hooks necessary to present a more comprehensive WebMCP tool for less developer effort. I understand frameworks like Angular probably weren't the original intended use case for the declarative API, but I just wanted to call this out more directly as it is probably our most interesting take away from this experiment so far.
Potential Additional Features
Some potential future features which I imagine were intentionally out of scope, but I'll share anyway to provide the relevant use cases.
agentconnected event: I found myself kind of wanting an agentconnected event to tell the page that an agent who cares about WebMCP is ready and that the page should register any relevant tools. This could support lazy-loading tool schemas, though I'm personally skeptical that's a great design pattern anyway, as I suspect the performance hit of lazy-loading a bunch of disparate definitions would probably outweigh the initial load bundle size savings they would give.
toolactivated on the <form>: I was surprised to find that toolactivated triggers on the window with a form name. This requires the page to do extra work to map this back to the form in question if it is going to take any action. Would it be possible to dispatch this event on the <form> element directly? I feel like that would be much more ergonomic for the page.
Pre-submit validation errors: I appreciate that SubmitEvent.prototype.respondWith is a great hook for returning any errors which were found with form validity or during submission, but the AI won't get this information by default when filling out a form with no toolautosubmit. I suppose in the real implementation, the UI would likely update with any form errors and the AI would read the DOM to learn those issues, but that seems like it would introduce a lot of noise. I'm curious if there's a path towards some kind of independent formpopulated event, telling the page that content was filled out (independent of the change event I requested above) and possibly coming with its own respondWith function which the page can use to communicate back any validation errors directly. This could help the AI fix its mistakes or iterate through the process a couple times and resolve errors before sending control back to the user.
Implicit support for forms: This is more product feedback than spec feedback, but one of my goals for Angular is to make this work with as little effort as possible (ideally none) and I really like the idea of making existing <form> elements support their own implicit WebMCP tools without requiring developers to make any changes to their existing code. The idea of unlocking WebMCP support for millions of existing <form> tags is really enticing to me. The current implementation seems pretty close, but falls just short because of the need for an explicit toolname. I understand that a good name probably isn't super obvious, but I suspect a decent amount of DOM scraping / SEO-style indexing (look for an h* tag nearby or something) might be able to give at least a suggested name / description for the form, and we already have <label> elements or aria-describedby for parameter names. If we could get the required developer work down to zero, that can unlock a huge amount of potential for the ecosystem.
Are you saying only tooldescription should be enough? Or that the browser should generate both toolname and tooldescription by itself? I personally prefer opt-in behavior over opt-out in this case.
API Confusion
Some general questions / points of confusion I had about the API structure. This might just be limitations in my own understanding, but I wanted to share in case it might be indicative of ways we can improve future documentation or potentially tweak the names / semantics of some of these concepts.
agentInvoked without toolautosubmit: I was surprised to find that agentInvoked is true, even if toolautosubmit is not set. In my mind, I'm equating "invoked" to "submitted". Maybe that's not the right mental model, but I wonder if agentPopulated or agentParticipated might be more accurate? Alternatively, maybe agentInvoked actually should only be true when the agent directly submits the form?
Time for some bikeshedding! The agentInvoked flag indicates whether the browser agent filled form attributes during the submission process. Note that I also like your agentPopulated or agentParticipated proposals as well.
Cancelling requests: Is there a way to receive a cancel event from the agent? If the user cancels the agent, then I would expect that to flow down into an AbortSignal on the actual execute function. toolcancel only seems to support the declarative API if I'm reading the documentation correctly.
An AbortSignal passed in the execute() along agent and params seems like a good idea. See https://github.com/webmachinelearning/webmcp/issues/48
Bugs
The only potential bug I found in the implementation is that the execute function does not bind this when it is invoked. At one point I tried:
class MyTool {
value = 'test';
readonly name = 'foo';
readonly description = 'Does foo';
readonly inputSchema = {type: 'object', properties: {}};
async execute(): Promise<WebMcpToolResult> {
return {content: [{type: 'text', text: this.value}]};
}
}
window.navigator.modelContext.registerTool(new MyTool());
But I found this fails with "Cannot read properties of undefined (reading 'value')". I think the invocation should bind the execute function to the provided tool object, so we can reference this safely. I'd file a bug, but Buganizer claims I don't have permission (even as a Googler!).
That's all the major points of feedback I have right now, I'll be sure to share more as we continue to learn about this problem space. Thank you all for driving this effort, I'm really excited for the overall direction of WebMCP!
--
You received this message because you are subscribed to the Google Groups "Chrome Built-in AI Early Preview Program Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ai-dev-previe...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/CA%2BdDt%3D9JdDSA7W6Kq8AM9Y5F3tr0DAeKTqXa3xzekmEX%3DQ7GNg%40mail.gmail.com.
Doug Parker
François Beaufort
Thanks for the detailed response!> The toolactivated event triggers before form submission. This means you can check form validation errors there, and use mySubmitEvent.preventDefault() later to prevent form submission if the form doesn't have toolautosubmit of course.That's not the behavior I see. I made a minimal demo and confirmed that `toolactivated` triggers after `submit`. Maybe this is a bug in the current implementation?Regardless, I see `toolactivated` as a workaround, not a fix. IMHO, a form implementation should not need to specifically go out of its way to detect data applied by an agent. The existing mechanisms it uses to detect and react to user data should be sufficient. Requiring every JS-driven form to go through the extra hurdle of also subscribing to `toolactivated` is an extra barrier which doesn't need to exist. It's also bad for performance, as we need to manually map the provided `toolname` to the associated `<form>` element (that part might be fixed now per your other response) and then assume that all fields in that form were modified, rerendering and rerunning validations for all of them.
Luckily for us, input/change events are now fired for declarative WebMCP tool executions in Chrome 148.0.7731.0, (thanks to your feedback). This should help with your initial issue.
>> Reactive Forms Use Cases> This is excellent feedback! Could you please submit this as a new issue at https://github.com/webmachinelearning/webmcp/issues/new? Doing so would allow other framework developers to chime in.
> Good news! The toolactivated event will actually be fired on navigator.modelContext instead of window soon and will get both the tool name and the form element.Very cool. I feel like emitting on the `form` element would be more intuitive IMHO, easier to listen to a specific form rather than juggling multiple `toolactivated` listeners / deduping with a `WeakMap<HTMLFormElement, ...>`. But ultimately having a direct reference to the affected `form` is the main thing I really wanted to see.
>> Pre-submit validation errors:> Once again. Good feedback! Please file an issue in https://github.com/webmachinelearning/webmcp/issues/new to see how others think about this.
> Are you saying only tooldescription should be enough? Or that the browser should generate both toolname and tooldescription by itself? I personally prefer opt-in behavior over opt-out in this case.My argument here is that I think there is a huge value add if we could make all existing web forms implicitly compatible with WebMCP. I see this as a feature of the user agent, not the application. I don't have to opt-in my form to be available to screen readers or accessibility tools. I don't have to opt-in my form to be available to Puppeteer or Web Driver. I'm just rendering some HTML tags, it's up to the user agent to decide how to interact with them. If that interaction happens to involve asking an agent to fill it out, who am I to tell them otherwise and say, "No, you can't do that because I didn't say you could"?I don't think the browser actually needs all that much information from the developer to make this feature possible. Inputs already have `name` attributes and accessible `label` fields. The only required information which doesn't have a comparable existing APIs is really `toolname` and `tooldescription`. I'm thinking if we can get the AI to infer this data when not present (based on headings, page text, etc.), we can make all forms accessible by default to AI agents. We should still have `toolname` and `tooldescription` so developers can explicitly control these values when they want to, and I guess I'm open to something like `tooldisableagent` if developers want to explicitly opt-out (though again, that feels like it's not the developer's decision IMHO). But it's the automatic default which makes this really powerful and avoids having to get the entire web ecosystem to add manually WebMCP support to their forms, something which only a small fraction will ever do.That's my personal philosophy on this particular feature, but I'm curious to know where others stand on it.
You’re right that a browser agent could easily scrape a form, use an LLM to infer a toolname and tooldescription based on the DOM context, and then expose that form to an AI.
But if the browser is doing that heavy lifting internally, that’s a user agent feature, not WebMCP in this case.
`respondWith` Breaks the Event ContractI also just remembered a pet peeve of mine with respect to the idea of `respondWith` function on an event object and filed a separate issue on that front. This design has bugged me ever since I discovered `FetchEvent.prototype.respondWith` and I'd like to share that concern before we're committed to a new spec. That said, I recognize this is just me nitpicking software architecture and that the practical design of `respondWith` is probably fine. This is purely an emotional thing of wanting to be heard, feel free to disagree and close the issue as just not that big of a deal. 😅
I'd argue it's not a pet peeve ;)
Let's see what the WebML WG folks think about it.
Doug Parker
> Let's see what the WebML WG folks think about it.