Skip to main content
Glama
frsorrentino

Chrome Bridge

by frsorrentino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

execute_js

Destructive

Run custom JavaScript in the page's MAIN world when no dedicated tool fits. Await promises up to timeout, return JSON, or save full result to disk.

Instructions

Run JavaScript in the page (MAIN world). Requires the extension's "Allow user scripts" toggle; errors explain setup if disabled. Use it when no dedicated tool fits: extract or extract_table read data, query_dom inspects elements, inject_css restyles, and none of them needs the toggle. A promise is awaited up to timeout. A cut result stays valid JSON and says truncated; save_to writes the whole result to disk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesJS evaluated in the page; the value of the last expression is returned
tab_idNoTarget tab; omitted = last tab navigated in this session, else the active one
save_toNoAbsolute path: write the result (a string as is, anything else as JSON) there and return the path instead of the content
timeoutNoMax ms to wait for the result (default 30000); raise it for long async work
frame_idNoTarget iframe id from get_frames; omitted = main frame
max_lengthNoMax output chars

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.28.0
    • addedInput schema / properties / save_to
      Added value: +{
+  "description": "Absolute path: write the result (a string as is, anything else as JSON) there and return the path instead of the content",
+  "type": "string"
+}
    • addedInput schema / properties / timeout
      Added value: +{
+  "description": "Max ms to wait for the result (default 30000); raise it for long async work",
+  "type": "number"
+}
  2. Changed3 schema fields changedv1.10.0
    • addedInput schema / properties / code / description
      Added value: +"JS evaluated in the page; the value of the last expression is returned"
    • addedInput schema / properties / frame_id / description
      Added value: +"Target iframe id from get_frames; omitted = main frame"
    • addedInput schema / properties / tab_id / description
      Added value: +"Target tab; omitted = last tab navigated in this session, else the active one"
  3. First observedv1.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the risk profile (destructive, open-world, non-idempotent); the description supplies the operational context they cannot: the toggle prerequisite, awaiting promises up to timeout, the fact that a truncated result remains valid JSON and is marked as truncated, and that save_to returns a path instead of content. No contradiction with annotations.

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

Conciseness5/5

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

Five dense sentences with no filler; the capability and its key constraint (toggle) come first, the sibling-routing guidance second, and return-shape behavior last. Every sentence carries information an agent needs.

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 six-param arbitrary-code tool with no output schema, the description covers prerequisites, async/timeout behavior, truncation shape, and disk output. It does not address how non-JSON-serializable return values are handled or how the result behaves when the code throws, which is the only remaining gap.

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 100%, so baseline is 3, but the description adds real meaning for two params: max_length truncation still yields valid JSON flagged as truncated, and save_to writes the whole (untruncated) result to disk. tab_id and frame_id resolution rules remain schema-only.

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 specific verb+resource with scope: "Run JavaScript in the page (MAIN world)". It immediately contrasts itself against named siblings (extract, extract_table, query_dom, inject_css), so an agent can distinguish it without opening any 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?

Explicit fallback semantics: "Use it when no dedicated tool fits," then names four alternatives and what each does. It also states the enabling prerequisite ("Allow user scripts" toggle) and that disabled-state errors explain setup, covering what to do when the call fails.

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