Test a task list through a browser MCP tunnel

Watch a real browser MCP tunnel test create three tasks, complete one, check filters, and verify two active items remain after reloading Chrome.

Mehmood Ur Rehman Qureshi4 min readUse case

A tunnel connection is more useful when it can do a task and verify the result. This recorded run used MCP Browser Extension to operate the public TodoMVC demo in real Chrome through a public HTTPS tunnel. It created three tasks, completed one, checked the Active filter, reloaded the page, and read the remaining items.

The important result was visible application state: two active tasks remained after reload, and the Completed filter showed the task that had been checked. The run used synthetic task names and removed the tasks afterward. It did not open a private application or submit anyone's personal data.

Who this is for

A developer can use this pattern for a quick check of a small interface after a change. A QA reviewer can use it to document an interaction sequence before turning it into a repeatable automated test. It also gives someone setting up a remote browser connection a more informative first task than simply checking that a server is listed.

The demo is deliberately small. It checks task entry, a completion control, two filters, and persistence after a page reload. It is not a comprehensive application test, a cross-browser comparison, or evidence that a production task service has saved data on its backend.

The prompt

Open https://demo.playwright.dev/todomvc/ in a background tab.
If the list is empty, add these demo tasks:
- Review the tunnel setup
- Check the allowed site
- Verify the result
Complete the first task. Select Active and read the remaining tasks.
Reload and verify that the two active tasks remain.
Select Completed and verify that only the completed task is shown.
Report each check, then remove only the tasks you created and close your tab.
If existing tasks are present, stop before changing them.

The recorded run sent the corresponding MCP tools with an SDK client. The client and Chrome ran on the same Mac, using the public Cloudflare HTTPS endpoint between them. It proves this request path and these browser interactions, not a separate mobile-device demonstration.

What actually ran

The remote session allowed demo.playwright.dev and enabled mutations. It created a named task workspace, opened a new background tab, and used snapshot to inspect the controls before editing. The empty state was checked before adding any demo data.

For each task, it used the documented trusted-input mode:

{"tool":"type","args":{"tabId":"<returned-tab-id>","selector":".new-todo","text":"Review the tunnel setup","clear":true,"trusted":true,"pressEnter":true}}

The other two calls used the remaining task names. This detail matters: an earlier recording attempt used ordinary synthetic input, and the application did not create the tasks. Text accumulating in an input is not a successful task submission. The accepted run used trusted: true, then checked that the application had rendered the expected task controls.

Next, the client clicked the first item's checkbox and selected the Active filter:

{"tool":"click","args":{"tabId":"<returned-tab-id>","selector":".todo-list li:first-child .toggle"}}
{"tool":"click","args":{"tabId":"<returned-tab-id>","role":"link","name":"Active"}}
{"tool":"get_text","args":{"tabId":"<returned-tab-id>","selector":".todoapp","maxBytes":3000}}

The read returned the two remaining task names and 2 items left. The client called reload, read .todoapp again, and verified the same active items. It then selected Completed and checked that the first task appeared while the other two did not. Screenshots captured the meaningful states along this sequence.

Actual Chrome viewport captures: three tasks, one completion, filter checks, and persistence after reload. Only synthetic demo data is shown. Recorded by the agent on 14 October 2026.

Results from the accepted run

CheckObserved result
Create the three named tasksAll three appeared in the list
Complete the first taskIt left the Active view
Read the Active filterThe other two task names and 2 items left appeared
Reload the pageThe two active tasks remained
Read the Completed filterOnly the first task appeared in the filtered list
Clean upThe created tasks were cleared and the agent's tab was closed

This is why the report includes reads after actions. A tool returning success means that its operation ran; the application result still needs checking. The earlier input attempt would have produced a misleading success story if the recording had stopped after the type calls.

Try the same pattern

Install and pair the extension with the quickstart, then follow the tunnel guide. Allow the public demo host and enable mutations. Use a private connector URL, and keep the browser computer awake while running the task.

Start with the public demo rather than real customer data. Inspect the initial state, give each created item a recognizable name, and specify cleanup. For your own application, use staging and identify what counts as a successful save. Reload persistence in this demo does not establish the persistence model of a different app.

The public demo is hosted at Playwright's TodoMVC page. TodoMVC is MIT-licensed. The recording shows the application's actual interface rather than a simulated task list.

Variations

You can extend the task to edit an item, clear completed items, or verify an empty state after cleanup. Add one assertion at a time and preserve the corresponding page result. If a selector no longer matches, take another snapshot and inspect the current controls instead of reporting a pass from an old layout.

For a task that only reads a public page, see the remote release-page check. For choosing the connection's permitted operations, see the permissions guide.

FAQ

Did the actions really travel through a tunnel?

Yes. The accepted run sent MCP requests to the public HTTPS connector, which reached the local server and paired Chrome extension. The SDK client was on the same Mac.

Why was trusted input used?

The initial synthetic-input attempt did not create tasks in this React demo. Trusted input followed by a page-state check produced the recorded working result.

Does this replace automated regression tests?

No. It is a small recorded smoke test. Repeatable regression coverage needs controlled test data, clear assertions, and the browser environments your application supports.

Set it up in a few minutes

One command for the server, one click for the extension.