This server drives a real Chromium browser to verify and document that features work, producing screenshots, video, and trace files as evidence.
Start a session (start_evidence_session): Launch a Chromium browser context with video and trace recording enabled for a named feature, optionally scoped to a base URL. Returns a sessionId for subsequent calls.
Navigate (navigate): Direct the browser to any URL (absolute or relative to the session's base URL).
Click (click): Interact with page elements using CSS/text selectors or ARIA role and name attributes.
Fill (fill): Type values into form inputs located by CSS selector.
Wait for (wait_for): Pause execution until an element reaches a desired state (visible, hidden, attached, or detached).
Screenshot (screenshot): Capture and save PNG screenshots immediately into the evidence directory, with a custom label used in the filename.
Finish session (finish_evidence_session): Close the browser, finalize video and trace, write a manifest.json, and receive a report of any console errors, uncaught exceptions, or failed network requests detected during the session.
Passive error monitoring: Every session automatically records browser console errors, uncaught page exceptions, and failed/non-2xx network requests into manifest.json, ensuring silent failures aren't missed.
Auto-cleanup: Sessions idle for 10 minutes are automatically finalized, and open sessions are flushed on process termination to prevent lost evidence.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-evidence Capture evidence for checkout flow on localhost:3000"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that drives a real Chromium browser (via Playwright) and packages the run into evidence — screenshots, a video, and a Playwright trace — proving a feature works. Meant for an agent to call after implementing something, as a verification step.
Generic and reusable: no assumptions about any particular app's routes or
auth. You pass a baseUrl per session, and evidence is written into the
consuming project's working directory at
.evidence/<featureName>/<timestamp>/.
Browsers aren't bundled — install Chromium once per machine:
npx playwright install chromiumPer-user (available in every project):
claude mcp add --scope user evidence -- npx -y github:meovan07/mcp-evidenceOr per-project, add to .mcp.json:
{
"mcpServers": {
"evidence": {
"command": "npx",
"args": ["-y", "github:meovan07/mcp-evidence"]
}
}
}This repo is public, so no GitHub credentials are needed on the machine
running npx.
Consuming projects should add .evidence/ to their own .gitignore.
Related MCP server: Playwright Browser MCP App
Tool | Purpose |
| Launches a browser context with video + trace recording on. Returns |
| Goes to |
| Clicks an element, located by CSS/text |
| Fills a form field. |
| Drags a source element onto a target, firing native HTML5 drag events. |
| Drags an element by a pixel distance — no drop target. For resize handles, sliders, swipe gestures. |
| Waits for an element to reach a state (default |
| Simulates losing ( |
| Mid-session version of |
| Runs a JS expression in the page, returns the (JSON-serializable) result. |
| Returns the accessibility tree as YAML (role, name, ref, bounding box) — see below. |
| Saves a PNG immediately into the evidence dir. Survives even if the session later errors. Pass |
| Closes the context, finalizes |
A session left open for 10 minutes with no tool calls is auto-finished. The
server also flushes any open sessions on SIGINT/SIGTERM so evidence isn't
lost if the process is killed mid-run.
click, fill, drag, drag_by_offset, and wait_for are the tools most
likely to fail while you're still figuring out an unfamiliar page — wrong
selector, element not visible yet, wrong assumption about the DOM. Rather
than returning a bare Playwright timeout, the error has a compact
accessibility snapshot of the page auto-attached, so you can usually see
what actually happened and correct course in the same round-trip instead of
needing a follow-up snapshot()/evaluate() call just to find out why.
Playwright's own error text is also cleaned up before it reaches you: terminal ANSI color codes are stripped (pure noise outside a terminal), and the actionability retry log — which can run to dozens of near-identical "waiting for element to be visible, enabled and stable" lines on a slow or animating element — is capped at the first few lines plus a count of how many were omitted.
start_evidence_session defaults to Chromium. Pass browser: "firefox" or
browser: "webkit" to use a different engine — webkit is the open-source
engine behind Safari, the closest available option for catching
Safari-specific bugs (though not a literal Safari build; some macOS-only
behavior like Intelligent Tracking Prevention may differ slightly). Install
the extra engines once per machine:
npx playwright install webkit firefoxmanifest.json records which engine a session used (browserEngine).
Every session also passively records, into manifest.json, anything a
screenshot or video wouldn't show: browser console errors and uncaught page
exceptions. finish_evidence_session reports the counts directly so a
silent failure doesn't slip through unnoticed.
Every request the page makes — not just failures — is also logged to
network.json (method, url, resource type, status, timing), the same data
Chrome DevTools' Network tab shows. manifest.json keeps a filtered
networkIssues list (non-2xx/failed only) plus a networkRequestCount for a
quick read without opening the full log. (The trace.zip already had this
same data in Playwright's own trace viewer; this just makes it directly
readable by the calling agent too, not only a human opening the trace UI.)
storageStatePath)Every session starts from a completely clean browser context by default —
good for testing a fresh visit, but it means any auth-gated flow (email OTP,
password login) has to be redone from scratch on every single run. Pass
storageStatePath to skip that:
start_evidence_session({ featureName: "checkout", baseUrl, storageStatePath: ".evidence/.auth/test-user.json" })First run: the file doesn't exist yet, so the session starts fresh
(logged out) as usual. Log in normally with navigate/fill/click
(using wait_for_email from mcp-evidence-api if it's an OTP flow). When
finish_evidence_session runs, the session's cookies + localStorage are
saved to that path.
Every subsequent run that passes the same storageStatePath: the
file exists, so the session loads it and starts already signed in —
start_evidence_session's response says
[loaded existing storage state, likely pre-authenticated]. The state is
refreshed on every finish_evidence_session too, so rotating session
tokens stay current.
This file contains live session credentials — treat it exactly like a
password. Store it under .evidence/ (already covered by the gitignore
guidance below) or another path you've confirmed is gitignored, never commit
it, and use a separate path per test account/user if you're testing more
than one identity.
device)Pass a Playwright device name to emulate a real device's viewport, user agent, touch support, and pixel ratio instead of a generic desktop window:
start_evidence_session({ featureName: "checkout mobile", baseUrl, device: "iPhone 13" })Common values: "iPhone 13", "Pixel 5", "iPad Pro 11" — see
Playwright's device list
for the full set (includes landscape variants, older devices, etc.). An
invalid name throws immediately with that link. manifest.json records
which device a session used.
Two genuinely different things fall under "PWA testing," with different support levels here:
Offline / service-worker-cache behavior — fully supported today via
set_network({ sessionId, offline: true }). This is the actual mechanism
a PWA is tested against: does it serve cached content, show a fallback
UI, sync back up when reconnected.
"Installed" look/behavior (display-mode: standalone) — partially
supported, and it's worth understanding the real limitation rather than
assuming it's fully covered. There is no browser API — CDP or otherwise —
that can force the native CSS @media (display-mode: standalone) feature
to match (confirmed by testing every parameter combination of Chrome
DevTools Protocol's media-emulation command, and cross-checked against
Puppeteer's docs, which list only prefers-color-scheme,
prefers-reduced-motion, and color-gamut as supported — not
display-mode). What displayMode/set_display_mode actually do is
override the JS window.matchMedia() function, so an app's JS
install-detection logic (matchMedia('(display-mode: standalone)').matches
— a common real pattern, e.g. to hide an "Install app" banner once
running standalone) reports the requested mode correctly. Any CSS
written as @media (display-mode: standalone) { ... } will not be
affected — the browser's CSS engine evaluates that independently of the
JS function, and nothing in Playwright or CDP can override it.
start_evidence_session({ featureName: "pwa install banner", baseUrl, displayMode: "standalone" })
// or mid-session:
set_display_mode({ sessionId, mode: "standalone" })For a full pixel-accurate "how does this look actually installed" check —
CSS included — there's no automatable substitute for genuinely installing
it (desktop: Chrome's --app=<url> launch mode; mobile: an actual
home-screen install on a real or emulated device), which is outside this
tool's scope.
snapshot)Reach for this before reaching for evaluate or trial-and-error click
calls to figure out what's on a page. It returns Playwright's aria snapshot
— a YAML tree of role, accessible name, a stable ref, and (by default) a
bounding box for every element:
snapshot({ sessionId })
-> - generic [ref=e1] [box=0,0,393,727]:
- button "Ask Coach..." [ref=e45] [box=40,412,321,24]
- button [disabled] [box=337,775,40,40]:
- img [box=347,785,20,20]Two things this surfaces for free that a screenshot or DOM query won't:
elements with missing accessible names (the second button above is
icon-only with no aria-label — a real accessibility gap, not just
inconvenient for automation), and disabled state (explains why a filled
form's submit button won't respond, immediately, instead of via minutes of
click-timeout debugging). Pass selector to scope it to part of the page
instead of the whole thing, or boxes: false to drop the bounding boxes
if you only need structure.
drag_by_offset)drag() is element-to-element (drag this onto that) — built for
reordering/drop-target interactions. Some gestures have no target element:
a bottom-sheet resize handle, a slider, swipe-to-reveal. drag_by_offset
grabs selector and moves the mouse by (dx, dy) pixels instead:
drag_by_offset({ sessionId, selector: "#resize-handle", dx: 0, dy: -250 })It uses Playwright's real mouse API, dispatched via CDP as trusted OS-level
input — not JS-synthesized PointerEvents. That distinction matters: some
UI libraries (Radix, among others) ignore untrusted synthetic events
entirely, so a dispatchEvent(new PointerEvent(...)) approach can silently
no-op even though the element clearly has a pointerdown listener attached.
Validated against both a native <input type="range"> (jumped straight to
its max when dragged past the track) and a custom pointerdown/
pointermove-based drag handle (moved exactly the requested distance) —
the same pattern that didn't respond to synthetic events in earlier testing.
start_evidence_session({ featureName: "checkout flow", baseUrl: "http://localhost:3000" })
-> sessionId, evidenceDir
navigate({ sessionId, url: "/cart" })
click({ sessionId, role: "button", name: "Checkout" })
fill({ sessionId, selector: "#email", value: "test@example.com" })
wait_for({ sessionId, selector: "#confirmation", state: "visible" })
screenshot({ sessionId, name: "confirmation" })
finish_evidence_session({ sessionId, summary: "Checkout completes and shows confirmation" })Resulting evidence directory:
.evidence/checkout-flow/2026-07-08T07-52-21-042Z/
0-confirmation.png
video.webm
trace.zip
network.json
manifest.jsonView the trace with npx playwright show-trace trace.zip.
If the process is killed within roughly a second of a session starting or
navigating (tracing/video still warming up), the video or trace for that
session may be incomplete or missing. Screenshots and manifest.json are
written eagerly and always survive. This doesn't affect the normal flow of
calling finish_evidence_session at the end of a run.
One Chromium process per session. Idle sessions are reaped after 10 minutes to avoid orphaned processes.
npm install
npm run build # tsc -> dist/
npm run dev # tsc --watch
npm start # node dist/index.jsClicks an element, located either by CSS/text selector or by ARIA role (optionally with name).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Accessible name to match, used together with `role` | |
| role | No | ARIA role, e.g. 'button', 'link' | |
| timeout | No | Max time to wait for the element, in milliseconds | |
| selector | No | CSS or Playwright text selector | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action but does not disclose behavioral traits such as success/failure behavior, waiting mechanics beyond the timeout parameter, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loads the verb 'Clicks', and efficiently specifies the two locating methods without redundancy. Every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return values are not described. The tool has 5 parameters, but the description covers the key aspects. However, for a click action, it may be adequate. Missing information on error states or preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), but the tool description adds value by explaining the relationship between selector and role/name parameters, clarifying that elements can be located either by CSS/text selector or by ARIA role with optional name. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Clicks) and the resource (an element) with two distinct locating methods (CSS/text selector or ARIA role with optional name). This unambiguously distinguishes it from sibling tools like fill, navigate, or screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use click vs alternatives. While the sibling tools have different purposes, the description does not state when click is preferred or when not to use it. The distinction is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fills a form field located by CSS selector with the given value.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| timeout | No | Max time to wait for the element, in milliseconds | |
| selector | Yes | ||
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions filling a form field but does not disclose behavior on element not found, multiple matches, or error handling. The timeout parameter is not mentioned in the description, leaving behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core action without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is too brief. It lacks information on return values, error states, and prerequisites, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%), and the description adds only minimal context: it notes the selector is a CSS selector and that a value is given. It does not explain sessionId or timeout beyond the schema, and the parameter descriptions are not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fills a form field using a CSS selector with a given value. It uses a specific verb and resource, and distinguishes from sibling tools like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify when not to use it or provide context for selecting it over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes the browser context (finalizing the video), stops tracing, writes manifest.json, and returns the evidence folder path. Always call this at the end of a verification run.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | No | Short human-readable summary of what was verified | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It lists key actions (close, stop, write, return) but does not discuss side effects or error states. Adequate for a cleanup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no redundant words. Perfectly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return value (evidence folder path). It covers all major actions. Could include warning about calling prematurely, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters: summary (has description) and sessionId (no description). Description does not add any parameter details beyond the schema. With only 50% schema coverage, description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: closing browser context, stopping tracing, writing manifest, and returning folder path. It distinguishes from sibling tools like start_evidence_session by specifying it's for finalizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Always call this at the end of a verification run,' providing clear when-to-use guidance. No explicit alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Takes a screenshot and saves it immediately into the evidence directory, so it survives even if the session later errors.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short label for this screenshot, used in the filename | |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that screenshots survive session errors, but lacks details on output, asynchronous behavior, or error handling. With no annotations, the description provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and front-loaded with the main purpose, no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and persistence, but omits details on output format, directory location, and integration with evidence session siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Does not add meaning beyond the input schema; the description repeats the tool's action but doesn't explain parameters like sessionId or how name affects filenames.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'takes a screenshot' and specifies it saves to an evidence directory for persistence, distinguishing it from sibling tools that perform actions like clicking or navigating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; only implies usage for capturing evidence without contrast to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches a Chromium browser context with video and trace recording enabled, and creates an evidence directory under .evidence/<featureName>/<timestamp>/ in the current project. Returns a sessionId to pass to the other tools. Call finish_evidence_session when done to finalize the recording.
| Name | Required | Description | Default |
|---|---|---|---|
| baseUrl | No | Base URL of the app under test; relative navigate() URLs resolve against this | |
| featureName | Yes | Short name for the feature being verified, used in the evidence path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: browser launch with video/trace, directory creation, and sessionId return. However, lacks details on side effects like state reset or concurrent session limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with primary action, followed by return value and next step. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return value (sessionId) needed for other tools, directory structure, and pairing with finish tool. Given no output schema, this is sufficient. Could mention implications of recording but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters. The tool description adds minor context (evidence path pattern), but the schema already covers meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it launches a Chromium browser context with recording and creates an evidence directory, returning a sessionId. Distinct from siblings like click or finish_evidence_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call finish_evidence_session when done, providing clear pairing guidance. Lacks mention of when not to use, but this is the only session starter so exclusions are less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Waits for an element (located by CSS selector or visible text) to reach the given state.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| state | No | visible | |
| timeout | No | Max time to wait, in milliseconds (default 30000) | |
| selector | No | ||
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose behavioral traits such as whether the tool blocks, what happens on timeout, or if it returns a value. This omission is significant for a waiting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in one sentence but lacks structure, such as bullet points or sections. It could be expanded with example usage or parameter details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count of 5 and 20% schema coverage, the description is incomplete. It does not explain return values, error conditions, or how to choose between selector and text parameters, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that 'selector' is a CSS selector and 'text' is visible text, and enumerates state values. However, with only 20% schema description coverage, it does not fully compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('waits for an element') and resource ('element'), and specifies the locating methods (CSS selector or visible text) and target state, distinguishing it from sibling tools like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for waiting before interacting with an element, but lacks explicit guidance on when to use this tool versus alternatives like click or fill, and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0clickfillfinish_evidence_sessionnavigatescreenshotstart_evidence_sessionwait_forScored across 7 tools
Each tool has a distinct purpose: session management (start/finish), navigation, page interaction (click/fill/wait), and evidence capture (screenshot). No overlap in functionality.
All tools use snake_case with a verb_noun pattern (e.g., start_evidence_session, finish_evidence_session, wait_for), and the naming is clear and predictable.
Seven tools cover the essential workflow for evidence gathering without being excessive or insufficient. Each tool earns its place.
The set covers the full lifecycle: launch, navigate, interact (click, fill, wait), capture (screenshot), and finalize. Minor omissions like scroll or keyboard input are not critical for the primary use case.
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
Launch, inspect, control, and share isolated cloud browsers for your agents.
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
