Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_cdp_send

Destructive

Runs an allowlisted Chrome DevTools Protocol command on a specified tab for DOM, accessibility, runtime, network, and screenshot inspection while refusing unsupported operations.

Instructions

Runs a Chrome DevTools Protocol command on the tab, from an ALLOWLIST OF COMMANDS kept by the extension: DOM reads (DOM.getDocument, querySelector, describeNode, getBoxModel, getOuterHTML...), Accessibility.getFullAXTree, Runtime.evaluate, Page.captureScreenshot, getLayoutMetrics, printToPDF, Input.dispatch* (agent's tab), display Emulation.*, Network.enable/disable, Log/Console. Everything else is refused (cookies, storage, request bodies, Fetch, IO, injected scripts, browser targets...): use the dedicated tool.

world (Runtime.evaluate only): "isolated" (default) evaluates in the extension's isolated world (shared DOM, page variables invisible); "page" evaluates in the PAGE WORLD, like browser_eval and the DevTools console, to inspect an application's state (window.INITIAL_STATE, Redux/Pinia store...). In both cases: enforced context (never the one chosen in params) and no console API. Both worlds share the document: Runtime.evaluate has the same FULL ACCESS as browser_eval (document.cookie, storage, fetch with the session), unmasked; Chrome's other responses are raw too (DOM.getOuterHTML, getFullAXTree: field values included). Page.reload with scriptToEvaluateOnLoad is refused (script injected on load). NOT covered by the outward-action accord check (Runtime.evaluate, Input.dispatch*): never use it to perform an outward gesture (send, pay, publish...) that the gated tools would refuse without the user's accord.

Input Schema

NameRequiredDescriptionDefault
worldNoisolated
methodYes
paramsNo
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.31.6
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "browser_cdp_sendOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the destructive/openWorld annotations: discloses the enforced execution context (params cannot choose it), absence of the console API in both worlds, that Runtime.evaluate has full unmasked access to cookie/storage/fetch with the session, that raw Chrome responses include field values from getFullAXTree, that Page.reload with scriptToEvaluateOnLoad is refused, and that it is exempt from the outward-action accord check — a genuine safety caveat an agent must know.

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-loads the core purpose and allowlist before the details, and the labeled 'world' passage is easy to locate. The parenthetical enumerations and sentence-level density make it heavier than necessary, but nearly every clause carries operational information.

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?

For a four-parameter, no-output-schema power tool with destructive semantics, the description supplies the allowlist, world semantics, response muting/full-access behavior, and safety constraints. It does not enumerate per-command params or indicate what a refused call looks like, which keeps it short of complete.

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

Parameters4/5

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

Schema coverage is only 25%, and the description compensates by fully explaining the 'world' enum's two values and their observable consequences, plus the allowlist that constrains 'method'. The free-form 'params' payload is left to CDP semantics rather than described per-method, which is the main residual gap.

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?

States a precise verb+resource (runs a CDP command on the tab) and immediately bounds it to an explicit allowlist, enumerating the permitted families (DOM reads, Accessibility.getFullAXTree, Runtime.evaluate, etc.). It distinguishes itself from the many dedicated siblings by declaring that everything outside the list is refused and pointing at 'the dedicated tool'.

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?

Explicit about what is allowed and, more importantly, what is refused (cookies, storage, request bodies, Fetch, IO, injected scripts, browser targets) with a redirect to dedicated tools. It also gives the positive routing rule for the 'world' parameter (page world to inspect app state like window.__INITIAL_STATE__, Redux/Pinia) and an explicit prohibition against using it for outward gestures.

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