Skip to main content
Glama
DB-25

arc-control-mcp

Screenshot

screenshot
Read-onlyIdempotent

Capture a tab's viewport, entire page, or a specific element as an image via the DevTools engine, without bringing the tab to the foreground.

Instructions

Take a screenshot of a tab and return it as an image: the viewport, the whole page (full_page), or one element (selector). Needs the DevTools engine (see cdp_status). Works on a background tab without bringing it forward; pass activate true only if you want Arc to show it (that waits for the user to pause, like open_url, and restores their focus afterwards). A full page is capped at 16384 px tall and the result says when it was cut. Prefer jpeg with a quality for a long page, since a large PNG is a lot of tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nthNoWhich match to capture when several exist, 0-based
exactNoFor "text=", "label=" and "placeholder=" selectors, require the whole trimmed text to equal the label. No effect on CSS, ref= or role= selectors.
formatNoImage formatpng
tab_idNoArc tab id from list_tabs. Omit to use the tab you opened last. Unlike other read tools this never falls back to the tab the user is looking at: with no id and no tab of yours it is refused, so pass this or call open_url first.
qualityNoJPEG quality, 1-100. Ignored for png.
activateNoBring the tab to the front first. This changes what the user sees, so leave it off unless needed. It waits until the user has stopped typing, fails with userActive true if they never pause, and puts their window and application back in front afterwards (focusRestored says whether that worked).
selectorNoCapture just this element instead of the viewport. CSS selector, "text=Label", or ref=, role=, label=, placeholder= as in click.
full_pageNoCapture the whole scrollable page, not just the viewport. Not combinable with selector.
timeout_msNoGive up on the capture after this long. Capped at 30000ms so the call cannot outlive a client's request timeout. To wait longer, call this again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds real behavioral context: capture works on a background tab, activate blocks until the user pauses and then restores focus, full pages are capped at 16384px with a cut indicator, and large PNGs cost tokens. These are meaningful traits beyond the structured annotations.

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 with the core action and mode options, and each sentence carries information. It is somewhat dense in the parenthetical about activate/focus restoration, but nothing is padding.

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?

For a read-only capture tool with no output schema, the description covers modes, prerequisites (cdp_status), tab selection behavior, truncation reporting, and cost tradeoffs. An agent has everything needed to call it correctly.

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 the baseline is 3, but the description adds value: it links format='jpeg' with a quality setting for long pages and clarifies that selector and full_page are mutually exclusive. That is genuinely useful guidance beyond the per-parameter schema text.

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 opening sentence gives a precise verb+resource and immediately enumerates the three capture modes (viewport, full_page, selector), so the agent knows exactly what it gets without opening the schema. It also distinguishes itself from other read tools by noting the DevTools engine requirement and pointing to cdp_status.

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?

It states when to use which mode (selector vs full_page), when to pass activate true ('only if you want Arc to show it'), and the recommended format/quality tradeoff for long pages. It also explains the refusal case when no tab_id and no owned tab exist, routing the agent to open_url first.

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