Skip to main content
Glama
zhaohaijun734-arch

local-chrome-cdp-probe-mcp

probe_page

Measure DOM elements and capture PNG screenshots in real local Chrome, with optional in-page login so authenticated views include httpOnly cookies.

Instructions

Measure and/or screenshot a page in real local Chrome.

Args: url: full URL to probe (http/https/file) measure_js: in-page JS expression (IIFE returning an object) evaluated after load; its value comes back as measurements. Example that measures one element's real text width: (() => { const el = document.querySelector('#target'); if (!el) return null; const b = el.getBoundingClientRect(); const cs = getComputedStyle(el); return { x: Math.round(b.x), y: Math.round(b.y), w: Math.round(b.width), h: Math.round(b.height), usable_text_width: Math.round(el.clientWidth - parseFloat(cs.paddingLeft) - parseFloat(cs.paddingRight) - 2) }; })() viewport_w / viewport_h: emulated viewport (also set via Emulation.setDeviceMetricsOverride, so it holds regardless of the Chrome window size) screenshot: capture a PNG and return it as base64 login: "user:pass" - a JSON POST login executed IN the page context before measuring (httpOnly cookies are fine - the page fetch carries them). Requires the target app to have a JSON login API. login_url: login endpoint path, default /api/auth/login login_body: JSON template with %u / %p placeholders, default {"username":"%u","password":"%p"} timeout_ms: overall probe timeout

Returns: {ok, origin, viewport, login_status, measurements, png_base64}

Input Schema

NameRequiredDescriptionDefault
urlYes
loginNo
login_urlNo
login_bodyNo
measure_jsNo
screenshotNo
timeout_msNo
viewport_hNo
viewport_wNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that viewport emulation persists regardless of the Chrome window size, that login runs a JSON POST inside the page context and therefore carries httpOnly cookies, and that the target app must expose a JSON login API. It stops short of stating whether the tool is otherwise side-effect-free, whether the browser session is shared, or any concurrency/timeout failure behavior.

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 purpose is front-loaded in one sentence, then parameters are enumerated in a scannable list with the return shape last. The measure_js example is long but earns its space by making a non-obvious parameter usable; there is only minor redundancy in the viewport bullet.

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 9-parameter browser automation tool with no annotations and no output schema, the description supplies the return shape ({ok, origin, viewport, login_status, measurements, png_base64}), the login mechanics, and the measurement example. It is nearly complete; only safety/side-effect profile and failure modes are absent.

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 description coverage is 0% across 9 parameters, so the description must compensate entirely and it does: every parameter is documented with type-appropriate semantics, defaults (login_url=/api/auth/login, timeout 30000), the %u/%p placeholder contract in login_body, and a full working measure_js IIFE example. This is far beyond what the bare schema conveys.

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 pair and resource: 'Measure and/or screenshot a page in real local Chrome.' The 'real local Chrome' qualifier distinguishes it from headless/HTTP fetching and from the sibling probe_available, which by its name only checks reachability. An agent knows immediately what this tool produces (measurements and/or a PNG).

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?

Usage is implied by the worked measure_js example (measuring one element's real rendered text width), which conveys the intended use case without stating when to prefer this over probe_available or when not to use it. There are no explicit exclusions or prerequisites beyond the login-requires-JSON-API note. Adequate but with a clear routing gap.

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