Did the Form and WebMCP Tool Calls Reach the Same Save Rules?

A script tested two routes in one synthetic appointment app using fixed inputs. No AI model was called.

If an app adds a callable route beside its visible form, will both reach the same rules before saving? WebMCP is an experimental browser capability that lets a page register functions for AI to call. Here, a script supplied inputs chosen in advance; no AI model selected a tool or its arguments. Both routes were deliberately made to pass through the same rules. All 36 planned checks in one synthetic app on one Mac matched expectations, but this was a narrow integration check accepted with a procedural exception. It did not test autonomous booking or general safety.

This is a conceptual illustration, not a test screenshot or a WebMCP interface.

What the sources say: a second door

Chrome’s guide explains how a page registers a function’s name, input format, and execution code. Chrome’s overview describes the setting for local testing. The project’s saved checks of both documents are dated October 10, 2026. This article covers a local test of an experimental capability; it does not establish general availability or support across browsers. The draft specification also explicitly states that it is not a W3C Standard, according to the saved October 9, 2026 check.

A tool description provides guidance, and a schema describes the input format. Schema checks may reject a call before it reaches the app. Checking availability and repeated requests in app code is this article’s design judgment. Chrome’s best practices, in the saved October 10, 2026 check, also recommend validation in code and updates to the visible interface. The advice to put validation and repeat-request handling in one place behind both doors is a design judgment, not protection that WebMCP supplies automatically.

Recorded observations: did both routes reach the same rules?

The test ran on October 10, 2026, on one Mac (macOS 27.0 comes from the October 9 inventory), using the installed Chrome 155.0.8059.39 and the enable-webmcp-testing setting. It used one synthetic appointment app on a local server with a separate browser profile. There were no real bookings, accounts, or model calls. The browser-automation tool Playwright 1.62.1 operated the form and, inside the page, invoked the actual tool discovered by the browser. No simulated call, direct function call, or direct HTTP request replaced that tool route.

Both routes used the same server function to validate requests and save them in the local database SQLite. To let invalid inputs reach the app, the test disabled the form’s built-in browser validation and omitted required-field and date constraints from the tool schema. Dates were plain text fields, and empty fields were omitted from the submitted data. A missing attendee therefore meant an absent field, not an empty string. These were experimental settings, not a recommendation to weaken production validation.

The table below is the final expected-results table from the same project. The experiment record attributes its pre-implementation timing to the preflight record. The October 9 council had replaced the initial plan’s third submission of the same request with an unavailable-date case. The available dates were a fixed, made-up list: October 10–12, 2026. 09:00 is a label with no time-zone conversion. A request ID is a number used to recognize repeated requests; it differs from the stored appointment ID.

The appointment database was emptied before each condition, and all six steps used one route. Later steps depended on the first appointment. “Enabled” and “disabled” refer to the WebMCP testing capability, not the form. The first repetition ran the form and then the tool with the capability on, followed by the form with it off. The second ran the tool and then the form with the capability on, followed by the form with it off.

The 36 attempts comprised 12 tool calls and 24 form submissions. Every table cell had 0 failed, 0 invalid comparisons, and 0 unexecuted attempts. These were observations from a dependent sequence run in two repetitions, not independent samples or a success rate. Acceptance included a breached preparation correction limit and a procedural exception after a refused first launch. The written exception came after the results were known; the verifier’s reservation about unqualified acceptance remains intact. No further rerun was required.

A pass includes a rejection when rejection was expected. With earlier checks deliberately relaxed and both routes wired to one function, every attempt matched expectations for arrival at that function, response, actual appointment rows and IDs, and visible state. Input conversion before the function was checked only for these fixed payloads. A stricter schema or built-in input check stopping a request earlier was not compared.

On resubmission, the app returned the existing ID. After each of the four rejections, the original single row remained intact. Only sequential resubmission with the same request ID was checked, so this does not establish that all duplicate bookings were prevented. A form-created appointment was not resubmitted through the tool, and October 12, the last date in the designed inventory, was never submitted.

For the disabled condition, the setting was changed to Disabled, the browser was restarted, and the tool interface was confirmed absent. The form’s pass count alone did not establish that the capability was off. No tool invocation was attempted while the capability was disabled. Rejection of an attempted invocation in that state, or continued absence beyond the recorded checks, was not tested. The form produced the same results in both repetitions. After the capability was re-enabled, tool registration and discovery were also confirmed. Detailed inputs and verdicts are preserved in a separately kept experiment record.

The experiment’s incremental cost was USD 0. Recorded preparation took approximately 36 minutes 3 seconds, rounded up to 37 minutes for accounting; the measured run lasted 13.553 seconds. Separate verification was recorded as finishing within its 20-minute allowance. Preparation accounting excludes earlier research and editorial work. These time and cost figures are not an efficiency comparison between the two routes.

Preparation failures and a procedural exception

Before measurement, the checking tools were repaired for local connection restrictions, connection-error handling, and defects that could erase a known failure when evidence was missing or leave an executed cell marked unexecuted. These were preparation defects in the checking tools, not measured app failures. Requests refused only at the network-blocking proxy were retained and counted without stopping the run. Nonlocal page/context requests, observed outgoing traffic or bypass, and malformed events remained fatal. No forwarding path or domain allowlist was added. The measured run still recorded 187 proxy refusals. Their background classification came from the recording layer, not independent identification of an operating-system process.

The original one-correction allowance was exceeded and that noncompliance was accepted. The allowance was revised to count from the freeze—the point when code, inputs and expectations were fixed. This did not erase the earlier breach. The app file bundle also changed before the freeze, requiring fresh capability-off evidence; the 36 measurements did not pool results from earlier bytes.

After the freeze, the coordinating Codex agent appended a note to a monitored decision document, causing the first launch to be refused before any browser launch or measurement. The document was restored byte-for-byte and execution proceeded the same day. No code, inputs, expected results, or frozen values changed. A separate verification agent rechecked the saved observations but withheld unqualified acceptance because of its interpretation of the rule requiring work to stop for the day after a pre-measurement failure. After the results were known, the coordinator accepted the experiment with a procedural exception. This does not mean the original procedure was followed in full.

What was not measured

This was a small sequence of inputs run in two repetitions, and the expected-results table came from the same project. The design and that table could share the same mistake.

• App behavior: Concurrent retries, duplicates with different request IDs, allowing only one appointment per time slot, retries crossing between routes, and recovery after a failure were not checked. Nor were whitespace trimming, other times, fields, data types or input classes, comprehensive available-date boundary checks, time-zone conversion, or equivalence of built-in input checks.
• AI and production use: The test did not measure an AI choosing which tool to call, natural-language or cross-language understanding, autonomous recovery, speed or cost savings, an advantage over screen operation, production workloads, operational readiness, or statistical reliability.
• Browser behavior: Other browsers, behavior across different websites, permissions, consent and general security were not verified. A tool declared through form attributes, Chrome 156-only metadata, and a comparison route deliberately bypassing the rules were also excluded.

Unresolved documentary questions differ from unexecuted tests. The saved research did not resolve whether and how long the trial period was extended, general availability, the history of API name changes, or disagreements about consent features. There is also no later evidence resolving the October 9 disagreement between the ChromeStatus summary and the guides. The installation’s update channel remains unconfirmed. These records establish no browser-enforced consent guarantee; the sources used need another check before publication.

Traffic across the entire operating system was not measured, so the record cannot establish “zero external traffic” or complete isolation. Page records also cannot establish the absence of operating-system prompts. The separate verification compared saved evidence; it was neither live observation nor third-party certification.

My view: ask for the rules behind both doors

The result is a narrow confirmation that both routes reached rules deliberately shared by this app. You can copy the questions below when asking someone to build an app. This is neither a template with demonstrated effectiveness nor a safety certification.

□ Show the shared validation-and-save function used by the form and tool being compared.
□ State what happens when the same request number is sent with the same content or different content.
□ Agree an input → expected response, appointment rows, and visible state table with the requester before implementation. Code and expectations can still share a mistake.
□ State whether a script supplied fixed inputs, and compare actual responses, appointment IDs, rows, and visible state for both routes.
□ Record whether rejection happened in the browser, input-format checks, or app. All observed rejections in this test came from the app.
□ This test relaxed some earlier checks. Do not use it to justify weakening production browser or input-format checks.
□ Verify that the tool capability is actually disabled, then test the form against the same table.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.