Chrome Browser Control

Overview Schema Source Related Servers Discussions Admin

Extract page elements

extract_elements

Extract structured data from web page elements using CSS selectors. Provides a safe alternative to raw JavaScript evaluation in Chrome browser automation.

Instructions

Extract bounded structured data from elements selected by CSS selector. Safer alternative to raw JavaScript evaluation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "selector": "<selector>"
    },
    "name": "extract_elements"
  }
}

Input Schema

Name	Required	Description
`limit`	No
`tabId`	No	Optional Chrome tab id. Defaults to the claimed session tab, then the active tab.
`visible`	No
`selector`	Yes
`documentId`	No	Exact frame document id returned by list_frames. Omit to target the current top document.
`includeHtml`	No
`includeText`	No
`includeLinks`	No
`includeTimes`	No
`sessionTabId`	No	Optional claimed tab session id returned by claim_tab.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Sep 10, 2026

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'safer alternative' and 'bounded structured data,' hinting at safety and structure but not explicitly stating read-only behavior, side effects, or permissions. It does not disclose what happens with the extracted data, whether mutations are possible, or any constraints like rate limits. This is insufficient for a data-extraction tool.

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?

The description is a single, efficient sentence that front-loads the core purpose and the safety differentiator. There is no redundancy or filler. While it is brief, conciseness itself is a strength; the lack of depth is penalized under other dimensions, not this one.

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

Completeness2/5

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

Given the tool's complexity (10 parameters, no output schema, no annotations), the description is severely incomplete. An agent cannot infer the return format, how to handle pagination or limits, what the include* flags control, or any side effects. The description provides only a high-level overview and leaves critical operational details undefined, making it inadequate for reliable invocation.

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

Parameters2/5

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

Schema coverage is only 30%, so the description must compensate by explaining parameter meanings. It only clarifies that the selector is a CSS selector and that extraction yields structured data, which relates to the selector and output but not to flags like includeHtml, includeText, limit, or visible. The description adds minimal value over the schema and fails to cover the majority of parameters that the schema leaves undocumented.

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?

The description states a specific verb ('Extract'), a resource ('elements selected by CSS selector'), and a clear scope ('bounded structured data'). It also distinguishes itself from raw JavaScript evaluation by claiming to be a safer alternative, which separates it from a generic scripting tool. Even without naming a sibling explicitly, the purpose is unambiguous and easily differentiated from other tools like query_elements.

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

Usage Guidelines3/5

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

The description implies a usage context: use this instead of raw JavaScript evaluation for safer data extraction. However, it does not explicitly state when to use it versus other extraction tools (e.g., query_elements), nor does it mention exclusions or prerequisites. The single alternative mention provides only weak guidance, leaving the agent to infer the rest from sibling names.

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