Communicate Validation Errors to Agent Prior to Form Submission

[dgp1130]

In the declarative form API, it seems limiting that an agent gets no feedback about the state of a form without either:

1. Looking at the DOM directly.
2. Attempting to submit the form.

If the users asks it to fill out a form with some data, it has no inherent visibility into whether or not that was successful. Best case it can hope for is that the app renders such validation errors directly to the DOM and that a subsequent check will find it, but this is generally inefficient (requires more tokes, time, etc.). It also won't catch asynchronous validations, which could take an unbounded length of time and the agent doesn't know how long to wait.

The browser can probably expose built-in form validation APIs (ex. <input required minlength="5">), and I think that's a great default. We should probably also consider communicating those constraints to the generated inputSchema. But ultimately I think this falls well short of the complexity of modern form systems, which need to express much more complex constraints not immediately visible to the DOM.

Following from SubmitEvent.prototype.respondWith, is there a similar way we can expose validation information to an agent directly without requiring it to submit the form first? Maybe we could put this on toolactivated? This might require an additional field to know if the form is about to be submitted (or maybe this tells the agent to abort submit and does emit the submit event?).

navigator.modelContext.addEventListener('toolactivated', (evt: ToolActivatedEvent) => {
  if (!evt.autosubmit) evt.repondWith(getMyErrorsForForm(evt.form));
});

This would allow the agent to wait until asynchronous validations have completed (Is this username already taken in the database?) and give it immediate feedback without requiring it to manually query the DOM and attempt to determine the current form state.

I suspect this might also give the agent and user much more confidence that a given form is filled out as intended. It is likely helpful to the workflow to have the agent fill out a form, check its validity, and then later decide if it wants to submit. The alternative of immediately committing to form submission without necessarily knowing what will be validated could be a seen as a bit "scary" both for the user and the agent and make them both more hesitant to move forward with the action.

[DavidMulder0]

Making this about the declarative form API hides the fact that IMHO a fair point is being made here: In general when an LLM wants to invoke a non-read-only tool an MCP host is likely to request confirmation for each attempt. The idea that non-read-only tools would be able to give a tool response prior to an MCP host requesting user validation is sensible.

Then again, given how WebMCP is modelled with a "human in the loop looking at a browser" mindset one can always simply in the execution take responsibility for getting user confirmation. In the declarative form approach one could simply mark all forms as autosubmiting and then 1) check the input validity, if invalid, respond with error 2) if valid, request user confirmation, don't respond to tool and 3) respond to tool only once user confirmation is given. The big question is whether there is value in the MCP host being responsible for user validation 'management' (the danger being that different browsers might have different MCP hosts with different rules and thus web application authors not trusting browsers enough to risk LLMs wreaking havoc on their systems)

[domfarolino]

Overall, I do appreciate the ToolActivatedEvent.prototype.submitValidationResult() proposal. @dgp1130 I guess this assumes that the ToolActivatedEvent is fired after the form is filled out, so that my getErrorsForForm() promise can act on the right values. Hmm, I was hoping to have the ToolActivatedEvent fire before the tool is actually activated, so that developers could use it to manage concurrency. That's something we'll have to think through.

Is the idea that the agent would receive the resolved validation status, and re-fill out the form (re-invoke the tool) if it sees that validation failed (i.e., username is already taken)?

---

In general when an LLM wants to invoke a non-read-only tool an MCP host is likely to request confirmation for each attempt.

Who is likely to request confirmation? I'm not sure what "MCP host" is here, but it sounds like the website. So you're saying the website's own tools are likely to request confirmation from the user before executing a tool that was fed data from the agent, right?

The idea that non-read-only tools would be able to give a tool response prior to an MCP host requesting user validation is sensible.

I don't think I follow this. Can you clarify? I guess I'm not seeing how this might generalize outside of the declarative API, or how this "requesting user elicitation" relates to giving validation feedback to the model.

[dgp1130]

Is the idea that the agent would receive the resolved validation status, and re-fill out the form (re-invoke the tool) if it sees that validation failed (i.e., username is already taken)?

Yeah, I think that's a great example. Alternatively, it might explain to the user what went wrong in natural language or suggest some alternative options. If the agent was given a higher-level task and only filled out the form to achieve one small part of it, then it might have ideas on how to deal with the consequences of the error. A simple example might be "That username is taken, actually maybe you already have an account, let me try to log in instead..."

[DavidMulder0]

@domfarolino WebMCP is based on the MCP spec. Key definitions are right at the start of the spec: https://modelcontextprotocol.io/specification/2025-11-25 . It gets confusing at the best of times, and WebMCP doesn't make it easier. So, in the context of WebMCP:

• Host = the browser (the "LLM application")
• Client = the code in the browser calling into the webpage (the "connector")
• Server = the webpage (the service that provides capabilities)

Big picture what I was trying to say:

This entire proposal sounds to me like it's purely a question of 'code to be executed without User confirmation' and 'code to be executed with user confirmation'. Or put differently 'code to be executed before and/or after User confirmation'. (After all, showing e.g. a form to the user with 'does this look all right, click the submit button if it does' is fundamentally just a User confirmation).

In a traditional MCP setting only the Host is interacting with the User, so only the Host can get confirmation from the User. In WebMCP either the Host, or the Server can get confirmation from the user. IF it's the responsibility of the Host to collect User confirmation then this proposal makes sense. IF it's the responsibility of the Server to collect User confirmation then this proposal is unnecessary^[1].

User confirmation collected by	Arguments in favor
Host	UX Consistency. Less overhead for developers. Can use LLMs to make judgement calls.
Server	Only the Server truly knows the right ways to visualize a tool call (many Hosts show users a literal JSON object[2]). Only the Server knows the true severity of a tool call (e.g. I work on an editor, and many tool calls are not read only, but they can be trivially undone using the undo button if incorrect). No risk of double confirmations (first by the Host, then by the Server)

And to respond to why I think this applies equally to both the imperative and declarative API: in normal MCP interactions it's incredibly common that the MCP host will ask for User confirmation for a tool that ends up instantly failing because the input parameters were completely incorrect. Being able to 'respond' to the LLM "go and fix this first" is absolutely a sensible idea for normal MCP. In the imperative WebMCP API one could however simply not have the Host collect user feedback, in which case the tool can simply be if (checkInputs()) { return "go fix this" } else { await showUIToUserForConfirmation(); goDoStuff() }. This is not an option for normal MCP.

---

Footnotes:

1. Just in case my "unnecessary" is not self evident, this is what I meant:

   <form toolautosubmit toolname="create-user" tooldescription="Create a user. This is a legally binding agreement.">
       <input type="text" name="first-name" toolparamdescription="User's legal first name as written in passport" required>
       <input type="text" name="last-name" toolparamdescription="User's legal last name as written in passport" required>
       <button type=submit>Create</button>
   </form>
   
   <script>
        const form = document.querySelector('form');
        form.addEventListener('submit', ev => {
             if (ev.agentInvoked) {
                  if (/* input valid according to passport rules */) {
                       alert("Check the form values, and press the submit button when satisfied");
                  } else {
                       ev.respondWith("The characters are used are not allowed in passports. Fix the inputs and call this tool again.");
                  }
             } else {
                  // actual submit
             }
        });
   </script>

2. I have already seen a proprietary MCP extension that allows MCP servers to send back a rendered HTML view of a tool call to fix this issue, so this is a real world problem.

[dgp1130]

     form.addEventListener('submit', ev => {
          if (ev.agentInvoked) {
               if (/* input valid according to passport rules */) {
                    alert("Check the form values, and press the submit button when satisfied");
               } else {
                    ev.respondWith("The characters are used are not allowed in passports. Fix the inputs and call this tool again.");
               }
          } else {
               // actual submit
          }
     });

IMHO, when the agent submits a form, the agent should receive the feedback, not the end user. So I think you shouldn't really be triggering an alert in this scenario. The user might be doing other things on the page, or the AI might make multiple attempts at submitting. We wouldn't want the agent to go through the extra effort of closing an unnecessary alert or for the user to see noise of multiple failed attempts before the successful one which matters. It reduces confidence in the whole system when nothing bad really happened.

Now this does reveal perhaps a separate issue that agentInvoked only tells you an agent participated in filling out the form, it does not actually mean the agent submitted the form. So I feel like the data this handler is receiving is ambiguous, and you don't really have a great option. If the user clicks the "Submit" button, then I would fully expect to receive visual feedback about whether that was successful, regardless of whether or not an agent helped me fill out the form.

This maybe highlights the value in a separate theAgentSubmittedThisForm field, so you could write this handler like:

form.addEventListener('submit', (evt) => {
  const errorMessage = validateFormAndGetErrorMessageIfWrong();

  // `theAgentSubmittedThisForm` is needed, not `agentInvoked`
  if (evt.theAgentSubmittedThisForm) {
    evt.respondWith(errorMessage ?? 'Success!');
  } else {
    alert(errorMessage ?? 'Success!');
  }
});

This way you can cleanly disambiguate between "Respond to the agent" vs "Respond to the user".

(This is tangenting a bit from the original scope of pre-submit validations, but...)

@beaufortfrancois, I had mentioned in a previous email thread that I didn't like the name of agentInvoked and that agentParticipated or agentPopulated might be more accurate. I think this is actually a much stronger argument that agentInvoked doesn't provide enough signal for the page to know whether to respond to the user or the agent. There's some implicit UX assumptions here, but that feels like a reasonable thing for the page to want to do.