This server lets MCP clients control a user's Chrome (or Edge) browser profile via the Codex Chrome Extension and Chrome DevTools Protocol (CDP), enabling browser automation with access to existing sessions, cookies, and tabs.
Status & Diagnostics
Check native host manifest path, bridge sockets, and connected extension backend info.
Session Management
Name the current Chrome tab group/session.
Finalize claimed tabs with a status of handoff or deliverable.
Tab Management
List all visible user tabs or tabs claimed by the current session.
Create new background tabs or claim existing tabs by ID.
Chrome Debugger (CDP) Control
Attach/detach the Chrome debugger to/from claimed tabs.
Send raw Chrome DevTools Protocol (CDP) commands to attached tabs.
Read and clear buffered CDP, network, and console events.
Browser Actions
Navigate claimed tabs to specified URLs.
Execute JavaScript in claimed tabs.
Capture screenshots in PNG, JPEG, or WebP format.
Provides tools to control Google Chrome via the Codex Chrome Extension, enabling management of tabs, navigation, screenshots, CDP commands, and reading network/console events.
Click on "Install 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., "@Codex Control Chrome MCP navigate to example.com and take a screenshot"
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.
Expose the Codex Chrome Extension flow to other Agent tools through MCP.
This project lets MCP clients control the user's normal Chrome profile through the installed Codex Chrome Extension. It is useful when an Agent needs existing tabs, cookies, logged-in sessions, installed extensions, screenshots, console/network events, or raw Chrome DevTools Protocol commands.
This is an independent community project. It is not affiliated with OpenAI, Codex, Google, or Chrome.
Chrome Extension: Codex Chrome Extension
Platform | Status | Notes |
macOS | Tested | Primary supported platform. |
Linux | Experimental | Manifest path targets Google Chrome under |
Windows | Unsupported | Native Messaging registration uses registry keys on Windows and is not implemented yet. |
Node.js 20 or newer is required. npm Trusted Publishing for releases uses Node.js 24 in GitHub Actions.
Related MCP server: @nimbus21.ai/chrome-devtools-mcp
Both Chromium browsers use the same Codex extension and the same chrome-extension:// origin, so a single manifest works for either.
Browser | Status | Notes |
Google Chrome | Tested | Default target. |
Microsoft Edge | Supported | Same extension and native-messaging mechanism; installs to the Edge |
Commands accept --browser <chrome\|edge\|all>. Without the flag, install-native-host installs for every supported browser whose profile directory exists, uninstall-native-host targets every browser it previously installed for, and status reports both.
Install and enable the Codex Chrome Extension in the Chrome or Edge profile you want to automate.
Install the package globally, then register the native host (auto-detects the browsers present):
npm install -g codex-control-chrome-mcp
codex-control-chrome-mcp install-native-hostA global install gives the native host a stable path, so its launcher execs Node directly against the installed CLI with no per-connection npx cost. To target one browser explicitly:
codex-control-chrome-mcp install-native-host --browser edgeConfigure your Agent to use the MCP stdio server through the installed binary:
{
"type": "stdio",
"command": "codex-control-chrome-mcp",
"args": ["--stdio"],
"startup_timeout_sec": 30
}If your MCP client does not inherit a shell PATH that includes npm's global bin directory (common for GUI apps), use the absolute path from npm prefix -g — for example /opt/homebrew/bin/codex-control-chrome-mcp — as command.
Check status and uninstall:
codex-control-chrome-mcp status
codex-control-chrome-mcp uninstall-native-host # restores the previous Codex native host manifestnpx -y codex-control-chrome-mcp@latest <command> still works for every command. Be aware that npx … install-native-host writes a launcher that re-runs npx on every extension connection; a cold or evicted npx cache can add seconds and may exceed the extension's connect timeout (the bridge then looks stuck "not connecting"). The installer detects the npx temp copy and keeps that launcher as a fallback — install globally and re-run install-native-host for the fast, stable path.
If your Agent supports skills, install or reference the bundled skill folder:
skills/codex-control-chrome-mcpThe skill documents the recommended MCP tool order for:
status checks
tab listing and claiming
CDP attach and command execution
screenshots
network and console event reads
tab finalization
This project controls the user's normal Chrome profile. MCP clients connected to it can inspect page contents and send raw CDP commands to claimed tabs.
Only install and run it on machines and Chrome profiles you own or are explicitly authorized to automate. Do not send browser cookies, password stores, profile databases, tokens, or private session files in issues or logs.
See SECURITY.md for the security model and reporting process.
The Codex Chrome Extension does not need an external Chrome remote debugging port. It uses Chrome Native Messaging and the extension's chrome.debugger permission:
Chrome extension
-> chrome.runtime.connectNative("com.openai.codexextension")
-> codex-control-chrome-mcp native host
-> local MCP bridge socket
-> chrome.debugger.attach / chrome.debugger.sendCommand
-> CDPBecause the control entrypoint is inside the normal Chrome profile, existing cookies, logged-in sessions, tabs, and extensions can be reused.
Read more:
Install dependencies:
npm ciRun checks:
npm run ciRun the MCP server locally:
node ./bin/codex-control-chrome-mcp.js --stdioRun native host mode locally for development:
node ./bin/codex-control-chrome-mcp.js --native-hostCodex App/extension updates re-register their own com.openai.codexextension native-messaging manifest, which overwrites this project's proxy registration (the bundled host binary has even been renamed across releases). The symptom is status showing sockets: [], registered: false, and a manifest path back inside the Codex bundle.
The MCP stdio server now self-heals: on startup it re-asserts the manifest when it detects it was reverted, so you usually do not need to re-run install-native-host. Because Chrome only reads the manifest when the extension reconnects, reload the Codex Chrome Extension (or restart Chrome) once after a Codex update to bring the bridge back. Set CODEX_CONTROL_CHROME_NO_AUTO_REGISTER=1 to disable the auto re-register.
If Codex App integration stops working, uninstall this native host to restore the backed-up manifest:
npx -y codex-control-chrome-mcp@latest uninstall-native-hostIf tab or CDP tools fail, use the bundled skill workflow: list tabs again, claim only current tab IDs, attach before raw CDP calls, and read CDP events after enabling the relevant domain.
CDP tools self-heal a stale debugger attachment since 1.4.0 (attach is verified,
and a lost attachment is recovered with detach → re-attach → retry). If you
still see attach flakiness — most likely when several browser-control stacks
share one Chrome and contend for the single debugger per tab — see the
Troubleshooting & Debugging Playbook for the root
cause, reference points (official client, extension service worker), and the
scripts/concurrency-check.mjs soak test.
See Install And Uninstall for the full per-browser checklist (the registered flag and host classification).
MIT
Attach Chrome debugger to a claimed tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a state change but does not disclose side effects, error conditions, or required permissions. 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?
A single, front-loaded sentence with no unnecessary words. Efficient 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?
Lacks information about prerequisites (tab must be claimed), effects after attachment, and how it relates to other tools. No output schema to compensate.
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?
The sole parameter tabId is not described in the input schema (0% coverage) and the description does not explain its meaning or format beyond the tool's purpose.
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 action (Attach), resource (Chrome debugger), and context (claimed tab). It is specific but does not differentiate from siblings like chrome_detach_tab.
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. It does not mention prerequisites (e.g., tab must be claimed) or when not to attach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the active Codex Control Chrome MCP bridge for status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full burden of disclosing behavioral traits. It only states the purpose and gives no information about side effects, destructive nature, rate limits, or what the status response contains.
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 short sentence with no superfluous words. It is front-loaded and efficient.
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 has no parameters and no output schema, the description should at least hint at what the status output contains (e.g., connection state, active tab info) or provide behavioral context. The minimal description leaves the agent uninformed about the return 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?
The input schema has zero parameters, and the schema description coverage is 100% (trivially). With no parameters to document, the description adds no parametric info but is not required to; baseline for 0 params is 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 returns the status of the Chrome MCP bridge, with a specific verb ('ask for status') and resource ('active Codex Control Chrome MCP bridge'). It distinguishes from sibling tools like chrome_status (general status) and tab-related tools.
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 such as chrome_status. It lacks context like prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a raw CDP command to a claimed and attached tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | ||
| method | Yes | ||
| params | No | ||
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions 'raw CDP command' implying low-level and potentially destructive, but does not disclose safety concerns, state dependencies, 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?
Single sentence, front-loaded, concise. But misses opportunity to structure information for clarity; no bullets or separation of concerns.
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?
With 4 parameters (including nested object), no output schema, and no annotations, the description is far from complete. Does not explain valid CDP methods, response format, or error handling.
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 0% and description adds no parameter information. It does not explain tabId, method, params, or timeoutMs. Completely insufficient for a tool with 4 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?
Description uses specific verb 'Send' and identifies the resource as a 'raw CDP command' to a 'claimed and attached tab'. It is clear but does not differentiate from siblings like chrome_evaluate which also sends commands.
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 like chrome_evaluate or chrome_navigate. Does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim an existing Chrome tab by numeric tab id.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks disclosure of behavioral traits. It does not explain what 'claim' entails (e.g., ownership, side effects, whether the tab must be unclaimed). Since no annotations are provided, the description carries the full burden and falls short.
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 a single sentence and is concise. It front-loads the action and resource. However, it could benefit from additional detail without becoming verbose.
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 annotations, no output schema, and a simple parameter, the description is incomplete. It does not explain what happens when a tab is claimed, return values, or prerequisites, leaving the agent underinformed.
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?
The description only adds that the parameter is a 'numeric tab id', which is already implied by the schema type 'integer'. With 0% schema description coverage, the description fails to adequately explain how to obtain or use the tabId.
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 action ('claim'), the resource ('Chrome tab'), and the method ('by numeric tab id'). However, it does not distinguish from the sibling tool 'chrome_attach_tab', which may have similar semantics.
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 like chrome_attach_tab or chrome_create_tab. There is no mention of prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new background tab and claim it for this MCP session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: creates a background tab (not visible) and claims it for the session (ownership), which is crucial for an agent. No contradictions; annotations absent.
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, well-structured sentence with zero redundancy or fluff.
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?
Adequate for a simple 0-parameter creation tool. Could benefit from mentioning return value (e.g., tab ID), but the description suffices 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?
No parameters exist, so baseline 4 applies. Description adds no parameter info, but none needed.
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 action (create) and resource (tab), with specific context 'background tab' and 'claim it for this MCP session', distinguishing it from siblings like chrome_attach_tab or chrome_claim_tab.
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?
Implies usage as the initial step for creating a new tab, but lacks explicit when-to-use or alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detach Chrome debugger from a claimed tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It says 'detach' but does not explain if it is reversible, what happens to the tab, or any side effects.
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 at four words, but it is under-specified and lacks necessary detail, making it more minimal than concise.
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, no annotations, and a single parameter, the description should provide more context about what detaching entails and any return values. It is completely inadequate.
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 0%, and the description adds no meaning beyond the parameter name 'tabId'. No hints on how to obtain this ID.
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 'Detach' and the resource 'Chrome debugger from a claimed tab', and it distinguishes from the sibling tool 'chrome_attach_tab'. However, it lacks any additional context or specificity.
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. No mention of prerequisites or conditions for detaching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JavaScript in a claimed tab using Runtime.evaluate.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | ||
| expression | Yes | ||
| awaitPromise | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'claimed tab' implying a prerequisite, but does not disclose side effects, permissions, or constraints (e.g., sandboxing, access to DOM, error handling). No annotations are present, so the description carries full burden but provides 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?
Single sentence is concise, but it omits important details. It is not overly verbose, but the brevity comes at the cost of missing essential 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?
No output schema, no annotations. The description covers only the basic purpose. For a tool that evaluates JavaScript, which could have side effects and complex return values, the description is not complete enough to guide correct invocation.
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 0% and description adds no meaning to parameters. The three parameters (tabId, expression, awaitPromise) are not explained beyond their types and constraints in the schema. The description does not describe what tabId refers to, how expression is evaluated, or the effect of awaitPromise.
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 it evaluates JavaScript in a claimed tab using Runtime.evaluate. It identifies the verb and resource, and mentions the CDP method. However, it does not explicitly differentiate from sibling tools like chrome_cdp_send, which could also evaluate JavaScript via arbitrary CDP commands.
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. For example, it could be compared to chrome_cdp_send for more general CDP interaction. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finalize claimed tabs. Use status handoff or deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| keep | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry full behavioral burden. 'Finalize' implies a terminal action, but it does not disclose side effects (e.g., whether tabs are closed, status updated, or destroyed). The behavioral impact is unclear.
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?
Extremely concise (two sentences) but at the cost of clarity. The description is under-specified, lacking essential details that conciseness should not sacrifice.
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 one parameter, no output schema, and no annotations, the description is incomplete. It does not explain return values, side effects, or usage steps, leaving significant gaps for an 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?
Schema description coverage is 0%. Description adds minimal meaning with 'Use status handoff or deliverable', which references the enum but does not explain the 'keep' array structure, its purpose, or how tabId and status interact. The schema's complexity (nested objects) is not addressed.
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 states 'Finalize claimed tabs' with a verb and resource, but lacks specificity and does not differentiate from sibling tools like chrome_bridge_status or chrome_claim_tab. The phrase 'Use status handoff or deliverable' hints at the parameter but is insufficient for clear purpose.
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. Prerequisites (e.g., tabs must be claimed) are not stated, and no when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get connected Codex Chrome extension backend info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description only says 'get info' without disclosing behavioral traits such as read-only nature, potential side effects, or what 'backend info' includes. Insufficient 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, concise and front-loaded. However, some information about what 'backend info' means could be added without sacrificing conciseness.
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 info retrieval tool with no parameters or output schema, the description is minimally adequate but could specify what kind of info is returned and confirm no side effects.
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?
No parameters exist, so description does not need to add parameter-level semantics. Baseline 4 for 0 params 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?
Description clearly states the tool gets backend info from the Chrome extension, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like chrome_status or chrome_bridge_status.
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. Lacks context about prerequisites or 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.
Set the Chrome tab group/session name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Codex Control Chrome MCP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the operation is a 'set' but does not mention side effects, permissions required, or whether the change is persistent or reversible. The description is too skeletal.
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 a single sentence with no wasted words. However, it is too brief, sacrificing useful information for conciseness. It earns its place but could include more context without becoming verbose.
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 one parameter, no output schema, and no annotations, the description should provide more context. It does not mention return values, side effects, or scope of the name. For a simple setter, it is minimally adequate but incomplete.
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 0%, and the description only repeats the parameter name ('name') without adding semantic context. It does not explain what the name is used for, valid formats, or the significance of the default value. The description fails to compensate for the schema's lack of detail.
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 states 'Set the Chrome tab group/session name' with a specific verb and resource. It clearly indicates the action and object, distinguishing it from sibling tools like chrome_navigate or chrome_screenshot, though 'session name' could be more precise.
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. There is no mention of prerequisites, context, or cases where this tool should not be used. Sibling tools like chrome_create_tab or chrome_session_tabs are not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and clear CDP/download notifications buffered by this MCP process.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| method | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the read-and-clear behavior, but does not provide details on side effects, state changes, or whether calling it multiple times has different effects.
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 at one sentence, but it omits important information about parameters and behavior, making it slightly too brief for full utility.
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 complexity of two parameters with no schema descriptions, and no output schema, the description fails to provide sufficient context. The agent is left guessing about parameter meanings and return values.
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?
The input schema has zero description coverage, and the description does not explain the purpose of the 'limit' or 'method' parameters. The agent cannot infer their meaning or constraints from the tool definition.
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 it reads and clears CDP/download notifications, with a specific verb and resource. It is distinct from sibling tools like chrome_cdp_send which sends commands.
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 explicit guidance on when to use this tool versus alternatives. The description only states what it does, but not when it is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot from a claimed tab. Returns base64 PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | ||
| format | No | png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the output format but does not disclose whether the operation is safe, idempotent, or if it has side effects (e.g., whether it interacts with the tab's state). For a capture tool, this is insufficient.
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 a single sentence that efficiently conveys the tool's purpose and output. It is front-loaded and not verbose, but could include a bit more detail without losing conciseness.
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 two-parameter tool with no output schema, the description is adequate but lacks contextual details: it doesn't mention that the tab must be claimed, doesn't describe the format parameter values, and doesn't indicate if the screenshot is full-page or viewport. More context would improve usability.
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 0%, yet the description adds no explanation of the parameters (tabId, format). It does not mention that tabId is required or that format has a default of 'png'. The description fails to add value beyond the schema.
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 action ('Capture a screenshot'), the resource ('from a claimed tab'), and the output format ('Returns base64 PNG'). This distinguishes it from sibling tools like chrome_navigate or chrome_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?
No guidance is provided on when to use this tool vs alternatives. It does not mention that the tab must be claimed (referenced in sibling chrome_claim_tab) or any prerequisites. The agent has to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tabs currently claimed by this MCP browser session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'list tabs' without disclosing behavioral traits such as side effects, rate limits, or what 'claimed' means. No additional behavioral context is added.
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 a single, front-loaded sentence with no wasted words. Every word adds clarity.
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 zero parameters and no output schema, the description is adequate but minimal. It lacks explanation of return format, the concept of 'claimed' tabs, and how it relates to sibling tools. Could be more 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?
There are zero parameters and schema coverage is 100%. The description does not need to add parameter info, and it effectively states the tool's function. Baseline for 0 params is 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 verb 'List' and the resource 'tabs', and specifies 'currently claimed by this MCP browser session', which distinguishes it from sibling tools like chrome_claim_tab or chrome_create_tab.
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 the tool lists claimed tabs but gives no explicit guidance on when to use it versus alternatives like chrome_user_tabs or chrome_claim_tab. There are no when/not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show native host manifest path and discovered bridge sockets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Show' implies a read-only operation, but with no annotations provided, the description does not explicitly confirm safety or lack of side effects. It is adequate but not 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?
Single sentence with no wasted words. Clearly states the tool's purpose in minimal space.
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 tool with no parameters and no output schema, the description is sufficient to understand the purpose. It could be improved by noting that the output is a status report, but it is not incomplete.
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?
There are no parameters, and schema coverage is 100%. The description adds no parameter info because none is needed. Baseline of 4 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 it shows 'native host manifest path and discovered bridge sockets', which is specific to a status check. However, it doesn't differentiate from the sibling 'chrome_bridge_status' which might overlap.
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 like chrome_bridge_status. The description lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user Chrome tabs visible to the extension.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is minimal and does not disclose behavioral traits such as permissions, return format, or limitations beyond being a list operation.
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, efficient sentence with no wasted words; front-loaded with verb and resource.
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 parameters, no output schema, and no annotations, description is adequate but could benefit from specifying what information is listed (e.g., tab IDs or URLs).
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?
No parameters exist, so schema coverage is 100%; description adds no param info, but baseline for 0 parameters is 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?
Description clearly states action ('List'), resource ('user Chrome tabs'), and scope ('visible to the extension'), effectively distinguishing it from sibling tools like chrome_session_tabs.
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 explicit guidance on when to use this tool vs alternatives like chrome_session_tabs or chrome_create_tab; context is clear but lacks exclusions.
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. Dates show when Glama detected each change.
v1.0.0chrome_attach_tabchrome_bridge_statuschrome_cdp_sendchrome_claim_tabchrome_create_tabchrome_detach_tabchrome_evaluatechrome_finalize_tabschrome_get_infochrome_name_sessionchrome_navigatechrome_read_eventschrome_screenshotchrome_session_tabschrome_statuschrome_user_tabsEach tool has a clearly distinct function (e.g., attach, detach, claim, navigate, evaluate). While chrome_session_tabs and chrome_user_tabs both list tabs, their contexts differ (claimed vs. all user tabs), and descriptions clarify the distinction.
All tools follow a consistent 'chrome_verb_noun' snake_case pattern (e.g., chrome_attach_tab, chrome_create_tab, chrome_evaluate). No mixing of conventions or abbreviations.
With 16 tools, the count is slightly above the typical well-scoped range (3-15), but each tool serves a specific purpose in Chrome tab automation (e.g., claiming, navigating, evaluating, screenshotting), justifying the number.
The tool set covers the full lifecycle of tab control: creation, claiming, attachment, navigation, evaluation, screenshot, and finalization. Minor gaps exist (e.g., explicit 'close tab' tool is missing, but finalize_tabs may handle it), but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
Live browser debugging for AI assistants — DOM, console, network via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iola1999/codex-control-chrome-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
