Skip to main content
Glama
Sign In
Chrome Bridge

Chrome Bridge

by frsorrentino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_status

Idempotent

Diagnose bridge connection failures or missing tools by reporting extension reachability, versions, and active caps. Enable inactive capability groups for the session without restarting.

Instructions

Status of the bridge itself, not of a page: call it when a tool you expect is missing or browser commands fail (connected=false: the extension is not reachable, extension_install gives its Chrome Web Store link). Also reports mode (primary/relay), host, port, server and extension versions, js_evaluation (false under --no-js), write_root, read_root, session_tab_id (the implicit tab), owned_tabs (created by this session), uptime_sec, webmcp (whether WebMCP is active in the session tab, and how to enable it). caps_active and caps_available: a missing tool lives in an inactive cap. enable is the only change it makes: it switches caps on for this session, no restart, and lists the tools added. Optional caps: audits (cookie_audit); visual (inject_css, measure_spacing, emulate_media, viewport_resize); perf (animations, frames, perf_trace, screencast, lighthouse, heap_snapshot); network (http_auth, set_geolocation, track_events); storage (get_storage, set_storage, session_fixture); dom (modify_dom, watch_dom, drag_and_drop); files (save_page, manage_downloads, session_record).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
enableNoCaps to switch on now, all in one call; "all" = every cap

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.28.0
    • addedInput schema / properties / enable
      Added value: +{
+  "description": "Caps to switch on now, all in one call; \"all\" = every cap",
+  "items": {
+    "enum": [
+      "all",
+      "audits",
+      "visual",
+      "perf",
+      "network",
+      "storage",
+      "dom",
+      "files"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv1.8.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and idempotentHint=true; the description reconciles this by stating 'enable is the only change it makes: it switches caps on for this session, no restart, and lists the tools added' — a genuinely useful scoping of the side effect. It also discloses failure semantics (connected=false means the extension is unreachable) and conditional behavior (js_evaluation false under --no-js).

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?

Front-loaded and free of filler — every clause carries diagnostic or field information, and the trigger for calling precedes the field inventory. It is, however, one long semicolon-chained paragraph that would scan far better as a short list, which costs a point on structure.

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

Completeness5/5

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

There is no output schema, so the description carries the full burden of describing return values — and it enumerates them (mode, host, port, versions, js_evaluation, write_root, read_root, session_tab_id, owned_tabs, uptime_sec, webmcp, caps_active, caps_available). Combined with the cap/tool mapping and the failure interpretation, an agent has everything needed to call and interpret this tool.

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

Parameters5/5

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

Schema coverage is already 100%, so the baseline would be 3, but the description adds the information the schema cannot convey: it maps each cap name to the concrete tools it unlocks (audits→cookie_audit, perf→lighthouse/heap_snapshot, etc.). That mapping is exactly what the agent needs to choose the right enable value.

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

Purpose5/5

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

Opens with a precise verb+resource and an explicit scope exclusion ('Status of the bridge itself, not of a page'), which immediately separates it from get_page_info and the general inspection tools. An agent can identify what this returns without consulting the schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger: 'call it when a tool you expect is missing or browser commands fail', plus the diagnostic meaning of connected=false and where to get the extension install link. It also defines the only condition under which the mutation parameter should be used ('a missing tool lives in an inactive cap').

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