self-healing-browser-mcp
Summary: An MCP server that gives AI agents a real Chromium browser to drive, with self-healing locators that recover elements after markup/test-id drift and report when they healed.
browser_navigate(url) — open a URL in the shared page and return the final URL.
browser_snapshot() — list the page's interactive elements as
{role, name}(semantic accessibility-tree view, no screenshots).browser_click(...) — click an element described by any combination of hints:
testid,role,name,label,placeholder,text,css.browser_fill(value, ...) — type a value into an input located with the same optional hints.
browser_get_text(...) — read the visible text of the described element.
browser_assert_visible(...) — assert an element is present and visible, returning
PASS/FAIL.browser_close() — close the browser and release resources.
Self-healing resolution — strategies are tried in priority order (
testid → role+name → label → placeholder → text → css → fuzzy accessible-name match) and the first that matches exactly one visible element wins; falling back flags the result ashealed.Configurable —
SHBM_TESTID_ATTRchanges the test-id attribute (e.g.data-cy);SHBM_HEADED=1watches the run instead of headless.Client-agnostic — usable from Claude Desktop, Claude Code, Cursor, or any MCP client (via
uvxor a venv path).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@self-healing-browser-mcp Go to https://example.com and click the 'Get Started' button."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
self-healing-browser-mcp
An MCP server that hands an AI agent — Claude Desktop, Claude Code, Cursor, or anything that speaks MCP — a real browser to drive, with self-healing locators.
Why
The moment you let an agent automate a browser, brittle selectors bite: a data-testid gets renamed, the DOM is restructured, a button's markup changes — and the run dies on a locator not found. Agents burn tokens retrying, or just give up.
This server takes a different contract. You describe an element by whatever you know — a test id, a role + accessible name, a label, some text, a CSS selector — and it resolves the element using the most stable strategy that still works. If your preferred locator has drifted, it heals to a fallback and tells you so, instead of failing.
Related MCP server: browser-control-mcp-server
How the self-healing works
Each element tool accepts the same optional strategies. The resolver tries them in priority order and uses the first that matches exactly one visible element:
testid → role + name → label → placeholder → text → css → fuzzy (accessible-name match)If your first-choice strategy resolves the element, great — no heal.
If it doesn't (renamed test id, changed structure) but a later strategy does, the result is flagged
healedso you know the locator drifted and should be updated.If only a name is known and its casing/wording shifted, a final fuzzy pass matches the accessible name across interactive roles.
The agent "sees" the page semantically via browser_snapshot (roles + accessible names from the accessibility tree), not raw HTML or screenshots.
Demo
See it heal live — the same locator hint keeps working after a refactor deletes the element's data-testid (examples/self_healing_demo.py):
$ python examples/self_healing_demo.py
1) Original app — the preferred data-testid resolves the button:
-> resolved via 'testid' healed=False
2) After a refactor removed the data-testid — SAME hint, no code change:
-> resolved via 'role' healed=True
-> clicked the recovered element successfullyThe data-testid the agent learned is gone, but because the hint also carried the button's role and accessible name, the engine recovered the element, flagged the heal, and the element stayed clickable — no test edit, no agent retry loop.
Tools
Tool | What it does |
| Open a URL in the shared page |
| List interactive elements as |
| Click an element (self-healing) |
| Type into a field (self-healing) |
| Read an element's text |
| Assert an element is visible — |
| Close the browser |
The ... on element tools is the locator strategy set: testid, role, name, label, placeholder, text, css — all optional; pass as many as you know.
Install
From PyPI, into a virtual environment, then download the Chromium build Playwright drives:
python3 -m venv .venv
.venv/bin/pip install self-healing-browser-mcp
.venv/bin/python -m playwright install chromiumThe server executable is .venv/bin/self-healing-browser-mcp (on Windows,
.venv\Scripts\self-healing-browser-mcp.exe). It is only on your PATH while that venv is
active, and MCP clients do not activate it, so point the client at the full path.
To work on the code, install from a clone instead (editable):
git clone https://github.com/RAJUSHANIGARAPU/self-healing-browser-mcp
cd self-healing-browser-mcp
python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/python -m playwright install chromiumUse it from an MCP client
Option A — no venv, with uv. uvx installs the package
from PyPI into a cached environment and runs it. Download Chromium once with the same
Playwright version:
uvx --from self-healing-browser-mcp playwright install chromiumClaude Code:
claude mcp add self-healing-browser -- uvx self-healing-browser-mcpClaude Desktop / Cursor (MCP servers config):
{
"mcpServers": {
"self-healing-browser": {
"command": "uvx",
"args": ["self-healing-browser-mcp"]
}
}
}The first launch downloads dependencies, so the client's first connection can take a few seconds longer.
Option B — the venv you installed into. Replace /abs/path/to/.venv with the real path.
Claude Code:
claude mcp add self-healing-browser -- /abs/path/to/.venv/bin/self-healing-browser-mcpClaude Desktop / Cursor (MCP servers config):
{
"mcpServers": {
"self-healing-browser": {
"command": "/abs/path/to/.venv/bin/self-healing-browser-mcp"
}
}
}Then ask your agent to, e.g., "open example.com, snapshot the page, and click the Sign in button." When a selector has drifted, the tool result will say it healed.
Configuration
Env var | Default | Purpose |
|
| The attribute |
| (unset) | Set to |
How this differs from Microsoft's Playwright MCP
microsoft/playwright-mcp is the official,
much broader server. Both drive Playwright and both let the agent read the page as an
accessibility snapshot rather than screenshots. The differences:
This server | Microsoft's Playwright MCP | |
Targeting an element | Each element tool takes several optional hints ( | Each element tool takes one |
Scope | 7 tools: navigate, snapshot, click, fill, get text, assert visible, close. | Around 70 tools, including tabs, network, storage, DevTools, and opt-in coordinate-based vision tools. |
Browsers | Chromium only. | Chrome, Firefox, WebKit and Edge ( |
Runtime | Python 3.10+. | Node.js 18+ ( |
Default mode | Headless ( | Headed ( |
Both let you change the test-id attribute (SHBM_TESTID_ATTR here, --test-id-attribute
there). If you need multiple browsers, tabs, network control or screenshots, use
Microsoft's server. This one is for the narrower case where an agent reuses locators
across runs and you want them to survive markup changes and tell you when they drifted.
Develop
pip install -e ".[dev]"
python -m playwright install chromium
pytestThe self-healing engine (src/self_healing_browser_mcp/engine.py) is decoupled from the MCP layer and tested deterministically against in-memory HTML — no external site, no flakiness.
Releasing
Publishing to PyPI is automated with GitHub Actions via
PyPI Trusted Publishing (OIDC) — no API
token is stored in the repo. Every push builds and twine checks the distribution in
CI, so main is always release-ready.
To cut a release:
Bump
versioninpyproject.toml, commit, and tag (git tag v0.1.1 && git push --tags).Publish a GitHub Release for that tag — the
Publish to PyPIworkflow builds and uploads it to PyPI through the project's Trusted Publisher (workflowpublish.yml, environmentpypi).
License
MIT — see LICENSE.
Available Tools
7 toolsbrowser_assert_visibleC
Assert the described element is present and visible. Returns PASS or FAIL.
Inputs: css, name, role, text, +3 more. Returns: result
browser_clickA
Click an element described by any combination of locator strategies.
Provide as many as you know (e.g. role='button' + name='Log in', and a
testid if you have one). The most stable available strategy wins; if it
healed to a fallback, the result says so.
Inputs: css, name, role, text, +3 more. Returns: result
browser_closeA
Close the browser and release its resources.
Inputs: no named parameters. Returns: result
browser_fillC
Type value into an input described by the locator strategies.
Inputs: value (required), css, name, role, +4 more. Returns: result
browser_get_textC
Return the visible text of the described element.
Inputs: css, name, role, text, +3 more. Returns: result
browser_snapshotA
Return the page's interactive elements as roles + accessible names.
Use this to 'see' the page semantically before deciding what to click or type.
Inputs: no named parameters. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
Each tool targets a distinct action (navigate, snapshot, click, fill, get text, assert visibility, close) with no overlap. The descriptions clearly differentiate their purposes.
All tools follow a consistent 'browser_verb_noun' pattern in snake_case, making the set predictable and easy to understand.
The server has 7 tools, which is well-scoped for a browser automation server. Each tool provides a necessary function without redundancy or bloat.
The tool set covers core browser operations (navigation, interaction, state inspection, assertion). Minor gaps like scrolling or waiting exist but do not critically hinder typical agent workflows.
Maintenance
Related MCP Connectors
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceA semantic browser runtime for AI agents that replaces raw HTML with structured data and dynamic, page-specific tools. It features built-in site memory and automated bot detection bypass to enable efficient, self-healing web automation.1-
- AlicenseAqualityCmaintenanceEnables AI agents to fully control a browser for web automation, including navigation, clicking, typing, scrolling, screenshots, and DOM inspection, with session persistence and anti-bot bypass.4043 npmMIT
- AlicenseCqualityDmaintenanceEnables AI-powered browser automation with real profiles, supporting interaction, navigation, form filling, and advanced features like visual overlays and self-healing selectors.42Apache 2.0
- FlicenseNot gradedqualityBmaintenanceEnables AI agents to autonomously control browsers with zero-hardcoding semantic DOM interaction, real-time network telemetry, Cloudflare/bot self-healing, and human-in-the-loop reasoning for web QA and automation.-