The chromium-bridge server lets you control a Chromium-based browser programmatically through Claude Code via MCP, enabling web automation, content extraction, and debugging.
Connection & Tab Management
Check browser extension connectivity (browser_status)
List all open tabs with id, title, and URL (browser_tabs_list)
Open/close tabs (browser_tab_create, browser_tab_close)
Navigate to URLs or move through history (browser_navigate)
Resize the browser window (browser_resize_window)
Page Reading
Extract visible text, title, and URL from a page (browser_page_text, ≤80 kB)
Read the full accessibility tree with element refs (browser_read_page)
Find elements by visible text, accessible name, or ARIA role (browser_find)
Mouse & Keyboard Interaction (via CDP)
Take screenshots or zoomed region screenshots
Click (left, right, double, triple), hover, drag, and scroll
Type text and send key combos (e.g. cmd+a, Backspace)
Wait for a specified duration
Form & Input Control
Set values on inputs, textareas, selects, checkboxes, and contenteditable elements (browser_form_input)
Click elements via DOM .click() by CSS selector (browser_click)
Upload local files to <input type="file"> elements (browser_upload_file)
JavaScript Execution
Run arbitrary JS in the page context with await support (browser_javascript)
Debugging & Monitoring
Read console output (log/warn/error) with optional regex filtering and buffer clearing (browser_console_messages)
List network requests with optional regex filtering and buffer clearing (browser_network_requests)
Recording
Record tab activity as an animated GIF and save it to disk (browser_gif_start, browser_gif_stop)
A bridge between your Chromium-based browser and Claude Code. The official
"Claude in Chrome" extension connects in some Chromium browsers (Arc, Vivaldi,
and others) but automation hangs: its tools are built on the tab groups API,
which is missing or broken there. This bridge uses only plain
chrome.tabs / chrome.scripting / chrome.debugger, so it works in any
Chromium browser that can load an extension.
Claude driving the browser through the bridge — opening Wikipedia, typing a search, and landing on the article:
Related MCP server: gotham-browser
Claude Code ⇄ (stdio MCP) ⇄ server/index.mjs ⇄ (WebSocket, 127.0.0.1:8929) ⇄ extension in the browser
⇅ (WebSocket /chat)
chat panel (popup on the extension icon)extension/ — an MV3 extension: the service worker keeps a WebSocket to the
local server and executes its commands (tabs, navigation, page text,
screenshots, clicks, form filling). Clicking the icon opens the chat panel
(chat.html) — a popup anchored to the extension icon.
server/ — an MCP server (stdio) that exposes the browser_* tools to
Claude Code and proxies them to the extension. It accepts WS connections
only from a chrome-extension://… Origin — regular web pages cannot connect.
It also serves the /chat channel: panel messages run through the
Claude Agent SDK (authenticated via the Claude Code login) with the same
browser_* tools; built-in tools (Bash, Read, etc.) are disabled.
An equivalent of the "Claude in Chrome" side panel: a popup that opens when you
click the extension icon (no chrome.sidePanel — it is not supported
everywhere). The chat can see the browser: list tabs, read pages, take
screenshots, and click.
The panel UI is in English by default and switches to Russian automatically when the browser UI language is Russian. A language selector (Auto / English / Русский) in the bottom bar overrides auto-detection; the on-page badge follows the same choice.
The popup closes when it loses focus (clicking the page) — that is browser
behavior. The conversation context is not lost: the panel remembers the
session_id and the server resumes the conversation via the Agent SDK
resume. A turn that is in flight when the popup closes is interrupted.
It only works while the server is running (usually an active Claude Code
session with the chromium-bridge MCP); otherwise the panel shows
"Server unavailable".
Model picker in the panel header: "Default" takes the model from
~/.claude/settings.json (whatever was set via /model; SDK sessions do not
read Claude Code settings themselves, the server passes the model
explicitly), the other entries are hard overrides. Switching applies on the
fly (setModel) and is remembered. Startup override:
CHROMIUM_BRIDGE_CHAT_MODEL=sonnet in the server environment.
Port: CHROMIUM_BRIDGE_PORT (8929 by default) — server side only; the
extension always connects to 8929, so changing the port also means editing
WS_URL in extension/sw.js and extension/chat.js.
Chat history: the 🕓 button in the header lists past conversations (stored in the panel's localStorage, the last 30).
After each turn there is a usage line: turn tokens (↑ input incl. cache / ↓ output) and the accumulated session cost in $ (on a subscription this is an estimate, not a separate bill).
Screenshots the agent takes along the way are shown right in the chat feed (click to expand). They are not saved to history (localStorage is finite).
You can paste images from the clipboard (Cmd+V in the input, up to 5 per message) — the model sees them; only a marker remains in history.
"Ask before acting" mode (checkbox above the input): reading (tabs, text, screenshots, console, network) proceeds without questions, while mutating actions — clicks/typing/navigation/JS/forms/closing tabs/file uploads — wait for an Allow / Deny card. The agent sees a denial and continues the conversation. Toggling applies immediately, without recreating the session (via the Agent SDK's canUseTool).
When Claude acts on a tab (from the panel or from Claude Code):
an orange glow burns around the page edges with a "✳ Claude is working…" badge, fading 2.5s after the last action;
a virtual cursor (an orange arrow) glides to the action point and pulses a ring on click; it disappears after 3.5s of inactivity.
Both are hidden on screenshots so they don't end up in the frame and confuse
the model when working with coordinates. On pages where scripts cannot be
injected (chrome:// and the like) the indication is silently skipped.
Extension: clone this repository, open chrome://extensions (in the
right space/profile!), enable "Developer mode", click "Load unpacked", and
pick the extension/ folder.
MCP server — either way:
via npm: claude mcp add -s user chromium-bridge -- npx chromium-bridge
from the clone: cd server && npm install, then
claude mcp add -s user chromium-bridge -- node "$(pwd)/index.mjs".
It loads at session start — restart your Claude Code session after installing the extension.
For other MCP clients, add this to your config:
{
"mcpServers": {
"chromium-bridge": {
"command": "npx",
"args": ["chromium-bridge"]
}
}
}Check: the browser_status tool should return {"connected": true}.
As of v0.5.
Tool | What it does |
| Check the connection to the extension |
| List tabs (id, title, URL) |
| Open / close a tab |
| Navigate to a URL; |
| Page title, URL, and visible text |
| Mouse/keyboard/screenshots via CDP: clicks by coordinates or ref, drag, hover, type, key combos, scroll, zoomed region screenshot, wait |
| Accessibility tree with ref ids (filter=interactive) |
| Find elements by text/role, returns refs |
| Set input/textarea/select/checkbox/contenteditable value by selector or ref |
| DOM click by CSS selector (plain .click()) |
| Put files into an |
| Run JS on the page (await supported) |
| Tab console (with a regex filter) |
| Tab network requests (with a regex filter) |
| Window size |
| Record a GIF of the tab → file; on long recordings the frame rate halves automatically, so the whole scenario fits |
Everything except basic tab operations works through chrome.debugger (CDP):
screenshots don't require activating the tab, clicks are real mouse events,
and console/network are collected from the first CDP touch of the tab.
The extension lives in one browser profile — install it in the one you want to automate.
While the server is running, its periodic ping keeps the extension's service worker awake. If the worker is asleep anyway (e.g. the server has just started), a keepalive alarm wakes it within ~30 seconds, and the server waits up to 12 seconds for reconnection before erroring.
Trust model: the WS server listens on 127.0.0.1 and rejects connections
whose Origin is not chrome-extension://…, which keeps web pages out. It
does not distinguish between extensions, and a non-browser local process can
fake the Origin header — anything running as your user is trusted, like with
most local dev tools. Don't run the bridge on a shared machine.
On the first CDP action the browser shows a "Chromium Bridge started debugging this browser" bar — that's normal, the debugger is the control mechanism. Closing the bar detaches the debugger (the next action re-attaches it).
Console/network are not recorded retroactively — only after the tab is first touched.
Port 8929 is owned by one session: a second parallel Claude Code session cannot start its own WS server (the extension stays with the first one).
Find elements by visible text, accessible name, or role, and return their refs for use with browser_computer and browser_form_input. Read-only. Cheaper than reading the whole accessibility tree when you know what you are looking for. An empty result means nothing matched — not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | visible text, accessible name, or ARIA role to search for | |
| tabId | Yes | tab id from browser_tabs_list or browser_tab_create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It declares read-only behavior, return of refs, and empty result handling. It does not disclose performance characteristics, rate limits, or potential side effects beyond what is stated. Adequate but not comprehensive.
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 three sentences, front-loaded with the main purpose, and each sentence adds essential information without fluff. Very concise and well-structured.
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 the tool's simplicity (2 params, no output schema), the description fully explains the purpose, usage context, and expected outcomes (refs, empty results). It also links to sibling tools. Slightly lacking in behavioral depth, but sufficient for the complexity.
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 descriptions for both parameters. The description adds context about query being for visible text, accessible name, or role, and tabId coming from browser_tabs_list or browser_tab_create. This adds marginal value over the schema alone.
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 finds elements by visible text, accessible name, or role, and returns refs for use with browser_computer and browser_form_input. It distinguishes from siblings like browser_read_page and browser_page_text which are broader reads.
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 strong usage guidance: it is read-only, cheaper than reading the whole accessibility tree when you know what you are looking for, and empty results indicate no match (not an error). However, it does not explicitly mention when not to use it or list specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start recording the tab into an animated GIF: a frame every intervalMs (default 800 ms); on long recordings the frame rate halves automatically so the whole scenario fits in ~80 frames. One recording per tab at a time; starting twice is an error. Nothing is saved until browser_gif_stop.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | tab id from browser_tabs_list or browser_tab_create | |
| intervalMs | No | frame interval in ms, default 800 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: default interval (800 ms), automatic frame rate halving to fit ~80 frames, single recording per tab restriction, and that saving only occurs on stop. This provides sufficient transparency for an agent to understand side effects and constraints.
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: two sentences covering purpose, defaults, behavioral tweak, and constraints. Every sentence adds value, and the key information is 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?
For a simple tool with 2 parameters and no output schema, the description covers all needed context: what it does, how it behaves (frame rate halving), constraints (single recording per tab, error on double start), and lifecycle dependency on browser_gif_stop. Complete for agent use.
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 have descriptions. The description reiterates 'default 800 ms' from the schema and adds context about halving, but does not significantly augment the schema's parameter meanings. 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 states the tool's purpose: 'Start recording the tab into an animated GIF'. It specifies the verb (start recording), resource (tab), and output type (animated GIF). This distinguishes it from sibling tools like browser_gif_stop and browser_tabs_list.
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 usage constraints: 'One recording per tab at a time; starting twice is an error' and 'Nothing is saved until browser_gif_stop.' It implicitly tells when to use (start a recording) and that the stop tool must be called. Could be more explicit about when to use vs. alternatives, but siblings are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the recording started by browser_gif_start and write the animated GIF to an absolute path on the user's machine. Mutating: creates or overwrites that file. Errors if no recording is active or no frames were captured.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | absolute path for the output .gif; overwritten if it exists | |
| tabId | Yes | tab id the recording was started on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutating nature (creates/overwrites file) and error conditions. No annotations provided, so description carries full burden; covers key behaviors.
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 with no waste. Action, result, and error conditions all 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?
Sufficient for a simple tool with 2 params. Covers side effects and errors. No output schema, but success return is implicit; minor gap.
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?
Adds 'overwritten if it exists' for path parameter beyond schema description. Schema already covers 100% with good descriptions; tool description adds context.
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 it stops a recording started by browser_gif_start and writes an animated GIF. Differentiates from sibling browser_gif_start by being its complement.
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?
Mentions errors if no recording or no frames, implying when to use. Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a tab's network requests (method, URL, status), newest 200. Read-only unless clear=true, which empties the buffer. Captured only from the first CDP touch of the tab — reload the page after attaching to see its full traffic. urlPattern (regex) filters by URL.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | empty the buffer after reading | |
| tabId | Yes | tab id from browser_tabs_list or browser_tab_create | |
| urlPattern | No | regex filter over the URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: read-only by default, clear empties buffer, capture timing limitation. No annotations present, so description carries full behavioral burden and does so adequately.
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?
Front-loaded with core purpose, then conditions. Three concise sentences, no redundant 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?
Covers parameters, behavior, and constraints. No output schema, but describes output format. Missing details like auth or error handling, but acceptable for a list 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 coverage is 100%, but description adds context beyond schema: buffer capacity (newest 200), capture timing clarification, and regex filtering purpose. Adds meaningful value.
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 it lists a tab's network requests with method, URL, status, and a limit of 200. Distinguishes from siblings like browser_page_text or browser_tabs_list which serve 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 usage context: captured from first CDP touch, requires reload for full traffic. Implicitly advises when to use (after attaching) but lacks explicit alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accessibility tree of the page with a ref id per element; use refs with browser_computer (clicks, scroll_to) and browser_form_input. filter=interactive returns only clickable/editable elements — a compact map of the page. Read-only. Refs go stale after navigation or heavy DOM changes; call again to refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | tab id from browser_tabs_list or browser_tab_create | |
| filter | No | interactive — only clickable/editable elements; default all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature, staleness of refs, and the effect of the filter parameter. Lacks details on performance or rate limits.
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?
Very concise, two sentences with critical information front-loaded. No wasted 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?
Given 2 parameters and no output schema, the description adequately covers core semantics and usage. Could mention the tree structure returned but otherwise complete.
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. Description adds value by explaining the filter parameter's interactive mode returns a compact map of clickable/editable elements, beyond the schema's enum 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?
Clearly states it provides the accessibility tree with ref IDs per element. Distinguishes from sibling tools (browser_computer, browser_form_input) by focusing on reading the page structure.
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?
Explicitly mentions how refs are used with sibling tools and that refs go stale after navigation or heavy DOM changes, requiring a fresh call. Could add more explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize the browser window that contains the tab to width×height CSS pixels. Mutating and user-visible: it resizes the user's real window. Use for reproducing responsive layouts or framing a recording, and consider restoring the original size afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | tab id from browser_tabs_list or browser_tab_create | |
| width | Yes | window width, CSS px | |
| height | Yes | window height, CSS px |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states the action is mutating and user-visible (resizes the real window) and recommends restoration. This is sufficient disclosure beyond the basic mutation hint.
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 very concise: two sentences front-load the purpose and provide usage guidance without any redundant or filler content. Every sentence adds value.
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 the tool's low complexity (3 simple parameters, no output schema), the description covers purpose, usage, and behavioral traits completely. An agent has enough information to select and invoke the tool correctly.
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 the description adds minimal extra meaning beyond parameter names and types. It notes that tabId should come from browser_tabs_list or browser_tab_create, which provides usage context but doesn't significantly enhance understanding of the parameters.
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 resizes the browser window to given CSS pixel dimensions. It distinguishes from sibling tools, which handle gifs, page reading, finding, uploading, and network requests, none of which involve window resizing.
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 advises using the tool for reproducing responsive layouts or framing a recording, and suggests restoring the original size afterward. While it does not explicitly list when not to use, the use cases are well-defined and the alternatives are clear from the sibling tools list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put local files into an selected by CSS selector, as if the user picked them in the file dialog (fires change). Mutating. files are absolute paths on the user's machine; the input must already exist in the DOM.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | absolute file paths on the user's machine | |
| tabId | Yes | tab id from browser_tabs_list or browser_tab_create | |
| selector | Yes | CSS selector of the <input type="file"> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It notes the tool is mutating, triggers a change event, and requires the input to already exist. This is sufficient for basic 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?
Two sentences, front-loaded with the primary action, and every sentence adds value. 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?
Given no output schema or annotations, the description covers the essential behavior, parameters, and preconditions. It does not describe return values or failure modes, but the tool is simple enough that this is acceptable.
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?
All 3 parameters have schema descriptions (100% coverage). The description adds context beyond schema, e.g., clarifying that files are absolute paths and that the selector targets an input of type file.
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 the tool uploads local files into a file input via CSS selector, mimicking user behavior. It uses a specific verb and resource, and uniquely distinguishes from siblings like browser_click or browser_find.
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 explains key usage constraints (absolute paths, input must exist, fires change) but does not explicitly state when to use this over alternatives or mention 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.
Each tool targets a distinct browser action: reading page, finding elements, uploading files, network requests, resizing window, and GIF recording start/stop. No overlap.
All tools follow a consistent 'browser_' prefix with verb_noun pattern using snake_case, e.g., browser_read_page, browser_upload_file. Minor deviation with 'browser_find' but still fits.
Seven tools is a reasonable number for a browser automation server, covering core read, find, upload, network, resize, and GIF recording without being overwhelming.
Missing essential browser interactions like navigation, clicking, and typing. The descriptions reference browser_computer and browser_form_input for those, but they are not included in this tool set, leaving significant gaps.
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.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dashi96/chromium-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
