Skip to main content
Glama

browser

Idempotent

Render a URL in headless Chromium to capture a visual screenshot, console logs, errors, and page metadata for UI testing and verification.

Instructions

Render a URL in headless Chromium and SEE it: returns a WebP screenshot the model can view, plus console output, uncaught JS errors, failed requests, optional performance metrics, and page metadata. Use this (not web, which is HTTP-only) for the VISUAL result or client-side JS behavior — verifying a local dev UI (http://localhost:3000) after a change. Write & run a UI test: outline=true lists the interactive elements with ready-to-use selectors, then actions clicks/fills/asserts through the flow (pass/fail reported). WordPress admin: recipe=wp_login|wp_admin|wp_plugins|wp_posts|wp_new_post + site= fills login from encrypted/env secrets (never logged) and waits for #wpadminbar (plugins/posts navigate after). Session reuse: session= keeps cookies across browser calls in this MCP process. Responsive check: device=mobile|tablet|desktop, or devices=["all"] to capture every viewport in one call. Performance check: metrics=true (FCP, load, request count, page weight). Watch it happen: headed=true opens a visible browser that highlights each click/input. Lean by default — the opt-in outline is bounded, not a full-DOM dump. Loopback always allowed; set allow_private for LAN. Needs the managed browser: if missing, run ch browser install once. Binary must be built with -tags rod (default codehelper update / install.sh).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
guiNoAlias for headed=true (visible Chromium).
urlNoURL to open (e.g. http://localhost:3000). Optional when site= is set — then the site login/admin URL is used.
repoNoRepository name for site/secret resolution (optional; defaults to current MCP workspace)
siteNoConnections website profile name (codehelper connections add-site). Supplies base URL + user; password from env:/secret store only — never pass passwords in MCP args.
auditNoAccessibility + Core Web Vitals audit. 'lite' = fast built-in checks (missing alt/labels/accessible-names, page lang/title); 'full' = the axe-core engine (comprehensive, with impact levels — needs `ch browser install`). Both also report LCP/CLS/FCP/TTFB with good/poor verdicts.
splitNoCapture the full page split into vertical pieces (~2000px each), returned as multiple images at full resolution — read a long page without the downscaling a single tall screenshot suffers
traceNoInclude a compact timing trail (navigate/action/wait/heal/fail) for debugging flaky flows — not a CDP file.
widthNoOverride viewport width px (else from device)
clip_yNoCapture only a region starting at this Y offset (CSS px); pair with clip_height
deviceNoViewport preset: desktop (1280x800, default) | tablet (768x1024) | mobile (390x844). Sets size, pixel ratio, mobile emulation, and UA.
formatNoScreenshot format: webp (default, smallest) | png | jpeg
headedNoRun a VISIBLE browser (default headless) so a human can WATCH the agent drive the page: each action flashes a labelled box on its target element and SlowMotion paces the clicks/inputs. Needs a graphical display (skip over SSH/CI — or use xvfb-run). Alias: gui=true. Env CODEHELPER_BROWSER_HEADED=1 or project browser_headed sets the default.
heightNoOverride viewport height px (else from device)
recipeNoNamed interaction recipe prepended before actions: wp_login | wp_admin | wp_plugins | wp_posts | wp_new_post | laravel_login | django_admin | drupal_login | magento_login | spa_hydrate. Requires site=. When omitted with site=, uses site kind / project browser_recipe default.
actionsNoInteraction + test steps before the screenshot. Locators: selector CSS, testid:/role:button:Name/text:/name:/ref:e3 prefixes, or fields role/name/testid/ref. Actions: click|type|fill|select|hover|press|scroll|wait|wait_idle|wait_hydrate|navigate|wait_nav|assert|assert_text|upload|snapshot|storage_set|storage_get|storage_clear|clear_cookies. Example: [{"action":"click","selector":"ref:e3"},{"action":"assert_text","selector":".ok","text":"Thanks"}]. Stops at first failure; failure_pack + screenshot always attached. Tip: outline/snapshot first; session= for login cookies.
devicesNoCapture several viewports in one call, e.g. ["mobile","desktop"] or ["all"]. Overrides `device`. Returns one image per device.
metricsNoCollect performance metrics: FCP, DOMContentLoaded, load, request count, transfer KB, JS heap
outlineNoReturn a compact map of the page's INTERACTIVE elements (inputs, buttons, links, form controls) — each with a stable ref (e1,e2,…), ready-to-use CSS selector, role, accessible name, input type, placeholder and value. Use this FIRST to discover targets; drive them with selector=ref:e3 or ref="e3". Bounded (≤100 elements), not a full-DOM dump.
qualityNoCompression quality 1-100 for webp/jpeg (default 80)
sessionNoNamed in-process cookie jar. Captures sharing the same session reuse auth cookies (e.g. wp_login then open plugins without re-login). Lives for the MCP server process lifetime.
slow_moNoHeaded only: delay in ms before each action so clicks/inputs are perceptible (default ~650ms). Ignored in headless.
wait_msNoExtra fixed wait after load, in milliseconds (with wait_hydrate: overall hydrate timeout)
baselineNoVisual regression: name a baseline. First call saves the screenshot; later calls return a diff image (changed pixels in red) + % changed. Per-device baselines.
selectorNoScreenshot only this CSS-selected element
snapshotNoReturn a bounded ARIA/role snapshot (Playwright-MCP style: role "name" lines, ≤80 nodes). Prefer over dumping HTML. Use with role/name/testid locators in actions.
full_pageNoCapture the full scrollable page, not just the viewport
clip_heightNoHeight (CSS px) of the clipped region to capture at full width
timeout_secNoOverall timeout seconds (default 30)
upload_allowNoExtra upload sandbox roots (os path-list separator). Upload paths must live under the workspace repo root and/or these dirs (also CODEHELPER_BROWSER_UPLOAD_ALLOW). Multi-file: text= path1||path2 or newlines.
wait_hydrateNoAfter load, wait for network idle + DOM stable (SPA/React/Vue/Next and WP admin hydration). Pair with wait_selector for a ready landmark (#root, #wpadminbar, …).
allow_privateNoPermit private/LAN (RFC1918) targets; loopback always allowed, cloud-metadata/link-local always blocked (default false)
pause_on_failNoHeaded only: keep the window open ~3s after a failed step so a human can see the failure. Env CODEHELPER_BROWSER_PAUSE_ON_FAIL=1.
session_clearNoClear the named session cookie jar before this capture
wait_selectorNoWait for this CSS selector to appear before capturing (also used as hydrate landmark when wait_hydrate=true)
debug_pack_dirNoOn action/assert failure, write a debug pack (failure screenshot + report.json with console errors, failed network, outline/snapshot, URL, action log) to this directory. Default: ~/.codehelper/browser/debug-packs/<timestamp>/.
segment_heightNoMax height (CSS px) per piece when splitting a full-page capture (implies split+full_page)
preview_actionsNoReturn a viewport screenshot after each interaction step (before the final capture). Requires `ch config browser set --action-previews on` (disabled by default). Failed steps always attach a shot even when this is off.
update_baselineNoOverwrite the named baseline with the current screenshot instead of diffing
pause_on_fail_msNoHeaded + pause_on_fail: override pause duration in ms (default 3000).
Behavior5/5

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

The description discloses all key behavioral traits: it returns screenshots and page metadata, supports interaction scripts, sessions, responsive devices, visual regression, and debug packs. It clearly states it needs the managed browser and binary with -tags rod. Annotations are consistent (readOnlyHint=false, destructiveHint=false) and the description adds context like headed mode and security constraints.

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 long but information-dense, with each sentence adding specific value. It front-loads the core purpose and then lists use cases and parameters. Minor verbosity could be trimmed, but overall it is well-organized and earns its length.

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?

Given the tool's complexity (39 parameters, no required, no output schema), the description is remarkably complete. It covers setup prerequisites, security considerations, parameter interactions, error handling (debug packs, pause on fail), and diverse use cases. No gaps are apparent.

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?

With 100% schema coverage, the baseline is 3, but the description adds substantial value beyond the schema. It explains parameters like 'outline' (bounded interactive map), 'actions' (with locator prefixes and action types), 'recipe' (WordPress/laravel etc.), 'session' (cookie reuse), and 'audit' (lite vs full). It provides concrete examples and tips.

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 clearly states the tool renders a URL in headless Chromium and returns a screenshot, console output, errors, and more. It explicitly distinguishes from the sibling 'web' tool which is HTTP-only, specifying this tool is for visual results or client-side JS behavior.

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?

The description provides extensive when-to-use guidance, including examples like verifying a local dev UI, writing UI tests, WordPress admin tasks, responsive checks, and performance audits. It also mentions when not to use it (when HTTP-only is sufficient) and references alternatives like 'web'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/VeyrForge/codehelper'

If you have feedback or need assistance with the MCP directory API, please join our Discord server