Mehmood Ur Rehman QureshiA release report often starts with a small question: which version does the public website currently show? You want the answer from the page that visitors can see, with its date and source URL. This use case runs that check through MCP Browser Extension's tunnel, using the browser on the owner's computer.
The recorded task visited the product's public changelog, read the newest release, and captured the visible page. The result was 0.9.22, dated 2026-10-13, with a summary about remote tunnels and proxies per Chrome profile. That is an observation from 14 October 2026, not a permanently current version claim.
Who needs this check
This workflow suits a maintainer checking documentation after a release, a support person preparing a version-specific answer, or a developer comparing a release announcement with the live website. The source page matters because a local repository, a package registry, and a website can update at different times.
A browser is useful when the visible page is the thing being verified. A public API may be better for a large recurring release inventory. Here, the point is to establish that a remote MCP request reaches the paired Chrome, reads the actual page, and returns evidence you can inspect.
The prompt
Open https://mcp-browser-extension.com/docs/changelog in a background tab.
Read the newest release heading and its first feature summary.
Return the version, date, and source URL. Capture the visible release section.
Report what the page says; do not infer that any package registry matches it.
Close only the tab created for this check.The recording used an SDK client to send the equivalent tool calls. Both the client and Chrome ran on the same Mac, but the client connected to the public HTTPS tunnel address. This tests the public connection path without claiming a phone or second-computer demonstration.
What the agent did
The server was started with tunnel mode, an allowlist containing the product website, and mutations enabled for creating and navigating tabs. The remote client initialized its MCP connection before sending browser calls. No website login or private account content was needed.
The important calls were:
{"tool":"task_new","args":{"name":"daily-2026-10-14-check-release-page-remote-browser"}}
{"tool":"tab_new","args":{"url":"https://mcp-browser-extension.com/docs/changelog","active":false}}
{"tool":"get_text","args":{"tabId":"<returned-tab-id>","selector":"main","maxBytes":6000}}
{"tool":"screenshot","args":{"tabId":"<returned-tab-id>","format":"jpeg","quality":85,"scale":1}}The tab ID shown here is a placeholder for the ID actually returned by tab_new. The recording saved that ID and used it explicitly for subsequent operations, so the task did not depend on whichever tab happened to be active in the owner's browser.
After reading the main content, the run captured the heading and scrolled through the release section. It then returned to the top and captured the heading again. The text result was capped at 6,000 bytes, which included the newest release; it was not a full archival copy of the changelog. The run finally closed its own tab.
The result
| Field | Observed value |
|---|---|
| Page | https://mcp-browser-extension.com/docs/changelog |
| Newest visible release | 0.9.22 |
| Release date displayed | 2026-10-13 |
| Release summary | Remote tunnels and proxies per Chrome profile |
| Transport used | Public HTTPS tunnel to the local MCP server |
The page read and the visible heading agreed. That supports a report about what the website displayed at the time of the check. It does not establish that every installation has updated, that the Chrome Web Store serves the same package, or that a separate remote client has been configured correctly.
For a release review, those distinctions prevent a common reporting mistake: turning one current-looking page into a claim that every distribution channel is current. If the report needs registry or Web Store state, check those sources separately and label each observation.
Try it with your own documentation
Follow the quickstart to install and pair the extension, then use the tunnel setup guide. Allow the exact documentation host and start with a public page whose expected fields you can recognize. Keep the connector URL private.
Ask for a small output schema: version, displayed date, summary, source, and any uncertainty. A page with no date should produce “date not shown,” rather than a date guessed from surrounding text. A redirect, timeout, or login wall should be reported as the observed outcome.
Variations
The same pattern can check a public status announcement, a documentation page's supported version, or the visible release notes for a dependency. When comparing two pages, keep their source URLs beside their results and use explicit tab IDs. Do not describe a comparison as complete if one source could not be read.
For an interactive example that changes and verifies page state, see the task-list test through the tunnel. It uses public demo data and checks what remains after reloading the page.
FAQ
Was this a real request through the tunnel?
Yes. An MCP SDK client connected to the public HTTPS endpoint and sent the browser tools. The client and browser were on the same Mac; no second device is claimed.
Why use a background tab?
It gives the task its own page without replacing the page the owner is working on. Explicit tab IDs also make the read and screenshot targets clear.
Does the report prove every installed extension is current?
No. It records the version displayed on the public changelog. Installed copies and distribution channels require their own checks.
Set it up in a few minutes