Mehmood Ur Rehman QureshiA small interface change can matter: a button that should appear after one step, or disappear after another, may be missing. This example uses page_watch to compare the controls on a public test page before and after an interaction. It is a quick, inspectable check you can repeat in the Chrome profile connected to MCP Browser Extension.
The test page is The Internet's Add/Remove Elements example. It is intentionally simple: one Add Element button creates a Delete button, and clicking Delete removes it. The page is public, requires no sign-in, and the demo does not enter or submit any personal information.
The prompt to give the agent
Open the public Add/Remove Elements practice page in a background tab. Save a page_watch checkpoint before changing it. Click Add Element, compare the checkpoint, and tell me which interactive control appeared. Save another checkpoint, click Delete, compare again, and report which control was removed. Do not sign in, enter personal information, or submit anything.
The prompt states what to compare and what counts as success. A real test of your own app should also name the target environment, the expected control, and any action the agent must not take.
What the agent did
The agent checked the browser connection, opened https://the-internet.herokuapp.com/add_remove_elements/ in its own background Chrome tab, and read the available controls. It created a checkpoint named “Before adding an action.” The saved snapshot contained the Add Element button and the page's two footer links.
Next, it clicked Add Element once. The page showed a new Delete button, and the first comparison reported one added control named Delete, with no removals. The agent then saved a second checkpoint while that button was present. After clicking Delete, the page returned to its initial state. Comparing against the second checkpoint reported Delete as removed.
The relevant MCP calls look like this:
page_watch { "action": "create", "name": "Before adding an action" }
click { "role": "button", "name": "Add Element" }
page_watch { "action": "compare", "watchId": "watch_<first id>" }
page_watch { "action": "create", "name": "After adding an action" }
click { "role": "button", "name": "Delete" }
page_watch { "action": "compare", "watchId": "watch_<second id>" }The IDs are returned by each create call. The example leaves them as placeholders so no temporary checkpoint ID is mistaken for a reusable value.
What the result tells you
The first comparison establishes that the page's accessible control list changed after the interaction: a button named Delete was added. The second establishes that this named button was no longer present after removal. The screenshots show the same visible change, so a reviewer can check the page alongside the structured diff.
This is evidence about the current control snapshot. It does not prove that a click handler works for every user, that server-side data was saved, or that the entire page stayed visually correct. The demo page has no account or data flow, and the agent did not send a form or make a purchase.
How to use this on your own page
Follow the quickstart and confirm page_watch is available in the MCP server version you have connected. Add the page's host to the allowlist only if the task needs it. Then ask the agent to:
- Open the test or staging page in a background tab and describe the controls it can access.
- Create a named checkpoint before the change.
- Perform one authorized action.
- Compare the saved checkpoint and report the exact added, removed, or changed controls.
- Remove the checkpoint when it is no longer useful.
For a release check, an example prompt might be: “Save a checkpoint on the staging account page, open the notification preferences section, and compare the accessible controls with the checkpoint from yesterday. Do not change settings or save the form.” The same idea works for navigation menus, setup wizards, and demo forms, as long as the page exposes useful accessibility labels.
Keep the checkpoint focused. It stores a limited accessibility view, not a full archive of the page. If a control has no accessible name, or several controls share the same name and role, the result may be unclear. page_watch can also miss selected tabs, custom states, and ordinary text changes. For those cases, ask for a text read or screenshot as a separate check and inspect the page yourself.
The tool does not run automatically or notify you when something changes. An agent needs to call compare while the relevant page is open. Checkpoints are kept locally for the active Chrome profile, and configured domain permissions still apply.
For the tool's full workflow and limits, see Save and compare browser page checkpoints with page_watch. The tools reference explains the browser actions used in this example.
FAQ
Does page_watch click buttons by itself?
No. In this example the agent uses the separate click tool to change the page, then calls page_watch to compare controls. A checkpoint or comparison does not itself click, type, or submit.
Does the tool keep checking the page in the background?
No. It saves and compares checkpoints when called. There is no timer or alert service in this workflow.
Can I use it on a signed-in account page?
Only if your task and domain permissions allow that access. Checkpoints do not persist form values, but labels and page titles can still be sensitive. Prefer a test account or staging environment and use the narrowest domain access that works.
Is this a full automated regression-testing suite?
No. It is an agent-run browser check of accessible controls. Use a maintained test suite for repeatable CI coverage, multiple browser engines, and a build gate.
Set it up in a few minutes