An AI agent with a browser is powerful. An AI agent that understands what it sees in the browser is unstoppable.
Brocogni is an open-source MCP server that sits between your AI agent and Playwright. Instead of dumping raw HTML into your agent's context (noisy, fragile, token-wasting), it compiles pages into a structured semantic map the agent can navigate, reason about, and act on in real time.
Two modes:
Agentic browsing loop -- The agent calls Brocogni tools directly: navigate, observe, click, extract, diff. Each step feeds back into reasoning. The browser is the environment, the agent is the brain.
Self-healing script generation -- The agent observes a page and generates vanilla Playwright code with automatic fallback selectors that survive frontend rebuilds.
No SaaS. No data leaves your machine. MIT.
Before -- fragile selectors that break on every deploy:
await page.click('.btn-primary');
await page.fill('.css-x83kf2 > input', 'hello');Works today. Fails tomorrow when Tailwind classes rebuild.
After -- semantic selectors with self-healing fallbacks:
await page.click('role=button[name="Sign in"]');
await page.fill('role=textbox[name="Email"]', 'hello');If the primary selector breaks, the fallback chain handles it:
role=button[name='Sign in']
-> button:has-text('Sign in')
-> xpath=//button[contains(text(),'Sign in')]
-> css=div:has(> button) + buttonThe engine anchors unnamed elements to named siblings using relational XPath and CSS adjacent selectors. If a button has no accessible name but sits next to a labeled input, Brocogni finds it anyway.
Related MCP server: WeaveTab-MCP
AI Agent
|
| MCP protocol (stdio)
v
Brocogni MCP Server
|
| Playwright + CDP
v
AX Tree --> DOM Geometry --> Selector Engine
|
v
Self-healing selectors
(ARIA / CSS / XPath / relational)The agent calls MCP tools in a loop: navigate to a URL, observe the page as structured semantic nodes, find targets by role or name, click to trigger new states, diff before/after to catch dynamic content. Actionable nodes carry role, name, bounding box, visibility, enabled state, and ranked selectors with fallback chains. The agent never sees raw HTML.
Brocogni is 81% cheaper than @playwright/mcp for the full workflow: observe → act → export a working Playwright script.
@playwright/mcp returns a raw AX tree with temporary refs (e5, e10).
Refs work inside the MCP session. When the LLM wants to export a persistent script,
they expire.
@playwright/mcp Brocogni
────────────── ────────
Try 1: write ref-based script Try 1: copy pre-computed selectors
→ refs expire, script broken → #search-input works
Try 2: re-observe, guess getByRole → One shot. Done.
→ 75% correct
Try 3: debug failed selectors
→ script finally works
Cost: $0.04 per script Cost: $0.01 per script
(3 attempts, trial & error) (1 attempt, one-shot)Scripts/mo | @playwright/mcp | Brocogni |
50 | $1.78 | $0.33 |
200 | $7.11 | $1.33 |
1,000 | $35.53 | $6.64 |
Pricing based on Claude Sonnet 4 ($3/M input, $15/M output).
What the LLM must parse | @playwright/mcp | Brocogni |
Elements returned | 62–93 AX nodes | 9 semantic nodes |
Actionable | mixed | 9 of 9 (100%) |
LLM must filter | yes | no |
Pre-computed selectors | no (refs) | yes (CSS/XPath/ARIA) |
Bounding boxes | no | yes |
Purpose inference | no | yes |
Fallback chains | no | yes |
Confidence scores | no | yes |
@playwright/mcp gives the LLM raw data and says "figure it out." Brocogni gives the LLM understanding and says "here's what to do."
npx playwright install chromium
npx browser-cognition-mcpThen connect your agent:
Claude Code
claude mcp add brocogni -- npx -y browser-cognition-mcpCursor
Settings -> Features -> MCP -> Add New
Name: brocogni | Type: stdio | Command: npx -y browser-cognition-mcpClaude Desktop
npx browser-cognition-mcp installOpenCode
Zero setup -- reads opencode.json automatically.
Tool | What it does |
| Open a URL |
| Compile page into semantic node map |
| Search by role, name, or purpose |
| Get primary + fallback selectors |
| Click, fill, or hover |
| Preflight: visible, enabled, compatible |
| Diff two page states |
| Capture viewport as PNG |
| Run JS in page context |
| Persist session cookies |
| Page URL, title, iframe count |
Also exposes a write-robust-playwright-script prompt that teaches agents how to use these tools effectively.
npm testDeterministic, no browser required. Covers semantic extraction, DOM fusion, selector ranking, relational fallbacks, delta computation, and action verification.
Does it need API keys? No. Every observation runs locally. No accounts, no telemetry, no data leaves your machine.
Which agents does it work with? Any MCP-compatible agent: Claude Code, Claude Desktop, Cursor, OpenCode, and others.
Does it add runtime bloat to my project? No. Brocogni is a dev-time MCP server. It generates vanilla Playwright code -- no runtime dependencies introduced.
What happens when a selector fails? The fallback chain activates automatically. ARIA -> text -> XPath -> relational sibling. The agent tries each one in order.
Bug reports, feature requests, and PRs welcome. See CONTRIBUTING.md. Security issues? SECURITY.md.
MIT. Go build something.
Execute an action (click, fill, hover) on a node using its ID. Optional: pass 'state' if querying offline; otherwise defaults to last observed state.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The text value to fill (required if action is 'fill'). | |
| state | No | The current SemanticPageState (optional, falls back to server-side cache). | |
| action | Yes | The action to execute. | |
| nodeId | Yes | The ID of the semantic node. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. It states the action and optional state but does not disclose side effects, return values, or error handling. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second adds optional parameter context. No extraneous information; well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite clear purpose, the description lacks details about post-action behavior (e.g., page state changes, waiting, return values). No output schema, so more context is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining the state parameter's optionality and default behavior. Also implies text is required for fill action, reinforcing schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool executes actions (click, fill, hover) on a node by ID. This distinguishes it from sibling tools like browser_navigate and browser_observe, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to pass the state parameter (if querying offline) and defaults to last observed state. Does not explicitly mention when not to use this tool, but purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the difference between two semantic states. Optional: pass parameters if querying offline; otherwise defaults to comparing the last two observed page states in memory.
| Name | Required | Description | Default |
|---|---|---|---|
| newState | No | The current SemanticPageState (optional, falls back to server-side cache). | |
| oldState | No | The previous SemanticPageState (optional, falls back to server-side cache). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains default behavior and offline mode, but lacks disclosure of other traits like side effects or return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, every phrase contributes meaning. Front-loaded with purpose, then usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not mention return value or structure of the difference. Also 'semantic states' could be better defined. Somewhat adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described), so baseline is 3. Description adds situational context ('if querying offline; otherwise defaults...') which adds value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and resource ('difference between two semantic states'), clearly distinguishing it from sibling tools like browser_act or browser_evaluate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to pass parameters (offline queries) and default behavior (comparing last two observed states), but does not explicitly mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary JavaScript code in the page context and return the result. Fast and direct.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript function body to execute in the page context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only adds 'Fast and direct', but fails to mention limitations, error handling, execution context (e.g., sandboxing), or return format. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff, and the core action is front-loaded. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly adequate. However, it does not clarify whether the code must be a function body (as per schema) or any code, potentially causing confusion. Also missing details on error handling and return types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds limited value beyond the parameter description. The description reiterates 'arbitrary JavaScript code', which is similar to the schema's 'JavaScript function body'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'execute', the resource 'arbitrary JavaScript code in the page context', and the outcome 'return the result'. It is distinct from sibling tools like browser_act or browser_verify, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_act or browser_verify. The description does not mention any exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the last observed page state for nodes matching specific criteria (role, name content, enabled state). Extremely fast and token-efficient.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter by accessibility role (e.g. 'button', 'textbox'). | |
| onlyEnabled | No | Filter to only enabled/interactable elements. | |
| nameIncludes | No | Filter by substring in the accessible name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool searches the 'last observed page state' (not live) and implies no side effects, but does not explicitly state that it is read-only or mention any limitations. The claim of speed and efficiency adds some context, but more behavioral details would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the purpose followed by a short phrase highlighting performance. It is front-loaded with the core function and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three parameters and a clear purpose, the description covers the essential functionality. However, it does not describe the return format or what the caller can expect (e.g., list of node identifiers). Minor gap given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description lists the criteria (role, name content, enabled state) matching the parameters, but adds no new meaning or formatting details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'the last observed page state for nodes matching specific criteria', and lists the three criteria (role, name content, enabled state). It effectively distinguishes from sibling tools like browser_observe (which observes general state) and browser_act (which performs actions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_observe or browser_get_selector_plan. It mentions being 'extremely fast and token-efficient' but does not explicitly compare to siblings or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the pre-computed selector plan (primary + healed fallback locators) for a specific semantic node. Optional: pass 'state' if querying offline; otherwise defaults to last observed state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | The current SemanticPageState (optional, falls back to server-side cache). | |
| nodeId | Yes | The ID of the semantic node. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool retrieves pre-computed data and mentions server-side caching and state fallback. However, it does not explicitly confirm read-only behavior or discuss side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no filler, and directly front-loads the primary purpose. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return structure. It only mentions 'primary + healed fallback locators,' which is vague. It does not cover what happens when the node is missing or the plan is empty, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are documented in the schema (100% coverage), so baseline is 3. The description adds value by explaining when to use the state parameter ('if querying offline' and 'defaults to last observed state'), which supplements the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a pre-computed selector plan for a semantic node, specifying it includes primary and healed fallback locators. This distinctively differentiates it from sibling tools like browser_act or browser_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using the state parameter for offline queries, but does not explicitly state when to use this tool versus alternatives like browser_find_targets or browser_observe. There is no when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open tabs/pages in the browser session. Returns index, title, and URL for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic functionality. No disclosure of side effects, limitations, or behavioral traits beyond reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no output schema; description adequately explains what is returned (index, title, URL) and suffices for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters; schema coverage is 100% implicitly. Baseline 4 applies because no param info needed, and description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'List', resource 'open tabs/pages', and specifies return fields (index, title, URL). Distinguishes from sibling tools like browser_navigate or browser_act.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not explain context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observe and extract the structured semantic state of the current active page, filtering out DOM noise. Note: If you see dropdowns/menus with expanded: false, you must hover them to reveal contents, then observe again.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Context compilation mode. | |
| budget | No | Maximum node budget for token optimization. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It mentions DOM noise filtering and a specific interaction pattern, but lacks details on side effects, permissions, or rate limits. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: one functional statement and one useful usage note. No fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple observation tool, but given no output schema, it could clarify what 'structured semantic state' means or hint at return format. Still, the usage note adds practical value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – both parameters (mode, budget) are described in the schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'observe and extract the structured semantic state of the current active page, filtering out DOM noise' – a clear verb+resource. It distinguishes from sibling tools like browser_screenshot (visual) and browser_evaluate (JS execution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a practical note about dropdowns with expanded:false, hinting at when to re-observe. However, it does not explicitly state when not to use this tool or compare with alternatives among the 11 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save page cookies to a file for session persistence.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | File path to save cookies to (default: session_cookies.json). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose whether the file is overwritten, if a page must be loaded, or what happens if no cookies exist. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with verb and resource. No wasted words, but brevity limits informativeness. Appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal behavioral context, the description misses details like return value and preconditions. Adequate but with notable gaps for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter, including default value. Description adds no new parameter meaning beyond schema, earning baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Save' with resource 'page cookies to a file', clearly distinguishing from sibling tools like browser_navigate or browser_observe. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as browser_verify for cookies or browser_navigate for sessions. No exclusion or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page viewport and return it as a base64 encoded PNG string (useful for visual validation).
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No | Take a screenshot of the full scrollable page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It discloses the return format (base64 PNG) but doesn't mention whether the page is scrolled or if any side effects occur. The behavior is inferred but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear, front-loaded, and contains no superfluous information. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional boolean and no output schema, the description covers the main intent and output format. Could optionally mention that it only captures the current tab's viewport.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (fullPage). The description adds no extra meaning beyond 'useful for visual validation', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes a screenshot of the current page viewport and returns it as a base64 PNG. It mentions 'visual validation' which hints at differentiation from siblings like browser_observe, but doesn't explicitly distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for visual validation but does not specify when to prefer this over alternatives like browser_observe or browser_verify. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the active page context to a specific tab by its index (from browser_list_pages).
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | The index of the page to switch to (from browser_list_pages). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Switch' implies active context change but doesn't disclose error handling (e.g., out-of-bounds index) or if state is preserved. Adequate for a simple action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Efficiently conveys purpose and required input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter, no output schema, and clear reference to sibling tool. Could benefit from mentioning that it sets active context for subsequent browser operations, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter 'index' fully described). Description does not add extra semantics beyond what schema provides. Baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Switch', resource 'active page context', and specifies source 'index from browser_list_pages', distinguishing it from sibling tools like browser_navigate and browser_list_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly tells when to use (after browser_list_pages to switch context). It lacks explicit when-not-to-use or alternatives, but the context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run safety action verification on a semantic node to confirm if it supports click/fill/hover and is interactable. Optional: pass 'state' if querying offline; otherwise defaults to last observed state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | The current SemanticPageState (optional, falls back to server-side cache). | |
| action | Yes | The action intent. | |
| nodeId | Yes | The ID of the semantic node to verify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that the tool performs a verification (likely non-destructive) and defaults to a cached state. However, it does not explicitly state side effects (e.g., read-only), nor does it describe what happens on failure (error or return value). This partial disclosure warrants a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, efficiently front-loading the core purpose and adding one optional detail. Every word is necessary, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and a parameter nuance but lacks information about return values (no output schema) and error conditions. For a tool with 3 parameters and no output schema, the description should at least hint at the return type. This gap prevents a higher score, but the core functionality is adequately explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'state' parameter's purpose ('pass if querying offline; otherwise defaults to last observed state'), which exceeds the schema's generic description. It also reinforces the 'action' parameter's meaning. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: running safety action verification on a semantic node to confirm interactability and support for click/fill/hover. It uses specific verbs and resources, distinguishing it from sibling tools like browser_act (which performs actions) and browser_evaluate (which evaluates expressions). However, it does not explicitly differentiate itself, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions optional 'state' for offline querying, but lacks explicit instructions on when to use this tool versus alternatives (e.g., 'Use this before browser_act to verify safety'). No exclusions or prerequisites are given, leaving the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0browser_actbrowser_deltabrowser_evaluatebrowser_find_targetsbrowser_get_selector_planbrowser_list_pagesbrowser_navigatebrowser_observebrowser_save_cookiesbrowser_screenshotbrowser_use_pagebrowser_verifyScored across 12 tools
Each tool targets a distinct browser automation task: navigation, state observation, interaction, JS execution, etc. There is no overlap; even similar tools like browser_verify and browser_find_targets serve different purposes.
All tools follow a consistent 'browser_verb_noun' pattern, making it predictable which action applies to which resource. No mixed conventions or vague verbs.
12 tools cover the essential browser automation capabilities without being excessive. The count is appropriate for the domain, providing a focused set that avoids bloat.
The tool surface covers core workflows (navigation, interaction, state extraction, screenshots, cookies) but lacks explicit tab creation or closure tools, which are minor gaps for a complete browsing session manager.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
