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., "@Chrome MCP Control Center list my open tabs"
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.
Single-click Windows Chrome Computer-Use MCP for non-technical users.
Install one app → open one desktop shortcut → complete a short wizard → click Start All → pair your LLM → automate Chrome safely.
Control Center desktop app (Start All / Stop All / Emergency Stop)
Local MCP server (stdio + optional loopback HTTP)
Chrome extension (Manifest V3) + Native Messaging
DOM-first browser tools; computer-use fallback (guarded)
Permission engine (read-only → reversible → commitment; L3 blocked)
LLM pairing for Grok CLI, Claude, Codex, generic MCP clients
Health check, Repair, audit logs with redaction
Related MCP server: Chrome MCP Server
npm install
npm run build
npm test
npm run desktopEnd-user install: see INSTALLATION.md.
Pairing: LLM_PAIRING.md.
Architecture: docs/ARCHITECTURE.md.
Living status: CONTEXT.md.
Open Control Center → Start All
Extension connects via Native Messaging
Pair Grok CLI
browser_list_tabs → browser_read_page → approve → browser_click
Emergency Stop blocks next action
Stop All clean shutdown
See SECURITY.md and THREAT_MODEL.md.
Webpage content is untrusted. Passwords and payment data never return to the LLM.
SemVer MAJOR.MINOR.PATCH. One number everywhere (app, extension, installers, GitHub tag).
npm run version:patch # or version:minor / version:major
npm run version:sync # sync desktop, extension, VERSION, src/version.tsInstallers (from next pack):
ChromeMCP-ControlCenter_1.0.4_win-x64_Setup.exe
ChromeMCP-ControlCenter_1.0.4_win-x64_Portable.exe
Details: docs/VERSIONING.md.
Free and Paid both sync operational telemetry to the owner backend (after consent). Free is not local-only for diagnostics. Secrets are never uploaded.
npm run cloud:backend # owner ingest + dashboard :8788
# Control Center → Cloud & Privacy → Accept agreement → Sync nowSee docs/CLOUD_SYNC.md.
Docs sync into the TTRG vault under 10-Projects/chrome-mcp-control-center/ (wikilinks, redacted).
npm run obsidian:exportRuns automatically after npm run build and npm run desktop:pack. Secrets and private logs are excluded.
MIT
Wait for a selector or timeout
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | ||
| selector | No | ||
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavior such as whether it throws on timeout, side effects on UI, or return value. No annotations exist to compensate.
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 no extraneous text, but could be slightly improved by front-loading key constraints.
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 basic three-parameter schema, the description should explain behavior and return values, which it entirely omits.
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 tool description does not explain the meaning or format of parameters (e.g., selector type, timeout units).
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 that it waits for a selector or timeout, differentiating it from sibling tools like click/type.
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, nor any contextual hints about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click screen coordinates (high caution)
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| url | No | ||
| tabId | No | ||
| confirmed | No | Set true after user approval for level ≥1/2 actions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only warns 'high caution' but does not explain what the click does (e.g., move cursor, trigger events), whether it requires a visible screen, or any side effects. The confirmed parameter suggests a safety mechanism but is not described.
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 (4 words) and front-loaded with the key action and a warning. However, it sacrifices clarity and completeness for brevity. Every word earns its place, but more detail is needed.
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 5 parameters, 2 required, and no output schema, the description is inadequate. It does not explain how to specify coordinates, the role of optional parameters, or what the return value is. The 'high caution' label is insufficient for safe usage.
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 schema description coverage is only 20% (only confirmed has a description). The tool description adds no information about parameters like x, y, url, or tabId. The agent must rely solely on parameter names, which are insufficient for correct usage.
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 'Click screen coordinates (high caution)' clearly states the action (click) and resource (screen coordinates). It distinguishes from sibling tools (computer_type and browser_wait_for) which involve typing and waiting, respectively. However, it could be more explicit about the context (e.g., mouse click on a GUI).
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. The description lacks any indication of prerequisites, appropriate scenarios, or when to avoid using it. The 'high caution' warning hints at care but does not provide concrete usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type via OS keyboard (high caution)
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| text | Yes | ||
| tabId | No | ||
| confirmed | No | Set true after user approval for level ≥1/2 actions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only mentions 'high caution' without explaining what that entails (e.g., potential for destructive actions, need for confirmation). No mention of side effects or required system state.
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 but arguably too brief for the complexity of a 4-parameter tool. It wastes no words but sacrifices informativeness.
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 4 parameters, no output schema, and no annotations, the description is insufficient. It lacks details on how the typing works, what the parameters mean in context, and safety precautions beyond a generic warning.
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 low (25%); the description does not explain parameters beyond the schema. It adds no meaning to 'text', 'url', 'tabId', or the purpose of 'confirmed' despite the schema providing a basic description for the latter.
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 phrase 'Type via OS keyboard' clearly indicates the tool performs keyboard typing, distinguishing it from sibling tools like computer_click and browser_wait_for. The 'high caution' adds a safety note.
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. The 'high caution' hint is vague and does not specify 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.3browser_wait_forcomputer_clickcomputer_typeEach tool targets a distinct action: waiting for a selector, clicking coordinates, and typing text. There is no overlap between their purposes.
All tool names use snake_case, but the prefix differs ('browser_' vs 'computer_'). This minor inconsistency does not hinder readability.
With only 3 tools, the server feels thin for a 'Chrome MCP Control Center'. It may be acceptable if the scope is intentionally narrow, but more tools are expected.
The tool set misses essential browser operations like navigation, page evaluation, or screenshot. For a control center, this leaves significant gaps that agents cannot work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Live browser debugging for AI assistants — DOM, console, network via MCP.
A paid remote MCP for AI agent browser approval MCP, built to return verdicts, receipts, usage logs,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/firyomaefx/chrome-mcp-control-center'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
