Skip to main content
Glama
escapeWu

chrome-agent-bridge

by escapeWu

Attach Raw CDP

browser_cdp_attach

Attach a Chrome DevTools Protocol session to a tab to run commands and capture events; detach to release the tab.

Instructions

Attach an unrestricted Chrome DevTools Protocol session to one tab. Set captureEvents=false when only commands plus a sanitized network projection are needed; captured Raw events may expose credentials and private data. The session holds the tab under an idle lease that any valid call renews; always detach. If the tab is busy, the error names the holder.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tabIdYes
browserNoWhich connected Chrome to use: an instanceId or label from browser_list_instances. Required when more than one browser is connected; session-based tools infer it from their sessionId.
maxBytesNo
maxEventsNo
leaseTtlMsNoIdle period after which another task may take over the attachment (default 300000). Any valid call renews it.
ownerLabelNoDiagnostic label shown to other tasks that find the tab busy; not an identity.
captureEventsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.10.0
    • addedInput schema / properties / leaseTtlMs
      Added value: +{
      +  "description": "Idle period after which another task may take over the attachment (default 300000). Any valid call renews it.",
      +  "maximum": 3600000,
      +  "minimum": 30000,
      +  "type": "integer"
      +}
    • addedInput schema / properties / ownerLabel
      Added value: +{
      +  "description": "Diagnostic label shown to other tasks that find the tab busy; not an identity.",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Changed1 schema field changedv0.9.1
    • addedInput schema / properties / browser
      Added value: +{
      +  "description": "Which connected Chrome to use: an instanceId or label from browser_list_instances. Required when more than one browser is connected; session-based tools infer it from their sessionId.",
      +  "maxLength": 100,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. Changed1 schema field changedv0.8.0
    • changedInput schema / properties / maxBytes / maximum
      Previous value: -3000000New value: +67108864
  4. First observedv0.6.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely meets it: it warns that raw captured events may expose credentials and private data, explains the idle-lease model that any valid call renews, mandates detaching, and states that a busy tab produces an error naming the holder. It does not disclose return shape or whether elevated permissions are required, but the safety and concurrency behavior is unusually well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the core action and then layered safety, lease, and error behavior. Nearly every sentence earns its place; the density is high but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description still covers safety, concurrency, lifecycle, and the busy-error case adequately for a 7-parameter tool. The remaining shortfall is the undocumented maxBytes/maxEvents bounds and no pointer to the follow-up command tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 43%, so the description must compensate. It adds real meaning for captureEvents (sanitized projection, credential exposure) and the lease renewal behavior. But maxBytes and maxEvents have no description in either place, leaving a genuine gap the description does not fill.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Attach an unrestricted Chrome DevTools Protocol session to one tab.' It is clearly distinguishable from browser_cdp_send, browser_cdp_events, and browser_cdp_detach by being the attachment step. However, it never names a sibling, so the differentiation is inferred rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use guidance: set captureEvents=false when only commands plus a sanitized network projection are needed. It also prescribes lifecycle behavior ('always detach') and explains the busy-tab outcome. It stops short of naming alternatives like browser_cdp_detach or browser_cdp_send as the follow-up path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools