This server lets you query recorded browser sessions, debug errors, reconstruct DOM states, generate Playwright test scripts, and—with explicit user consent—control the live browser.
Session Discovery & Overview
List recent sessions: Browse recorded sessions (newest-first), filtered by origin or limit, to get session IDs for further queries.
Summarize a session: Get a narrative summary including pages visited, interaction counts, and error tallies.
Error & Network Debugging
List console errors: Retrieve error messages and stack traces from a session.
List failed network requests: Find failed HTTP requests (4xx/5xx or transport errors) within a session.
Trace actions before an error: Reconstruct the sequence of user actions (clicks, typing, navigation) that preceded a specific console error.
DOM Inspection & History
Reconstruct DOM snapshots: Replay the page DOM as it existed at any recorded timestamp, optionally scoped to a CSS selector.
Track DOM changes over time: Get a timeline of attribute/text changes for a specific element across a session.
Test Generation
Generate a Playwright repro: Produce a runnable TypeScript Playwright test reproducing user actions from a session, optionally within a time window.
Live Browser Control (Consent-Gated)
Request authorization: Ask the user to approve a browser action via a side-panel banner, returning a one-shot token on approval.
Execute browser actions: Perform clicks, typing, navigation, scrolling, screenshots, and more in the live browser, subject to a per-origin permission model (read-only → suggest-only → confirm-required → auto-allow). Destructive actions always prompt the user regardless of permission level.
Two OSS products on one rrweb-based substrate. Both ship as npm packages today.
Product | One line | Install |
The recorder for your WebdriverIO and Playwright tests — Cypress on the roadmap. Self-contained HTML for every run — replay failures, audit successes, attach to any bug tracker. No SaaS, no dashboard, no signup. |
| |
Your real browser, exposed to your AI coding agent over MCP — the agent reads recorded sessions and, with your explicit consent, drives the live page. Never leaves your machine. |
|
Above: npx @tracelane/cli init in a real WebdriverIO project — detect runner, install, edit wdio.conf.ts, ignore reports dir.
Above: peek sessions list then peek sessions show ... --format markdown — a recorded browser session as queryable structured output, AI-ready.
Package | Status | What it does |
alpha | WebdriverIO Service — capture + write HTML report | |
alpha | Playwright Reporter + auto-fixture — capture + write HTML report | |
planned | JSON-output adapter (no Test Replay overlap) | |
alpha | Framework-agnostic capture engine — depended on by the adapters | |
alpha | Self-contained HTML report builder |
Docs: tracelane.cubenest.in (source under apps/tracelane-docs/). The tracelane-wdio README is the right starting point.
Package | Status | What it does |
alpha |
| |
alpha | stdio MCP server — exposes captured sessions, plus consent-gated live read + act tools, to Claude Code, Cursor, Cline, Windsurf | |
alpha · on the Chrome Web Store | Chrome MV3 extension — the real browser, recorded |
Docs: peek.cubenest.in (source under apps/peek-docs/).
peek requires Node.js ≥ 22. Its native
better-sqlite3dependency only ships prebuilt binaries for Node 22+; on older Node (notably Windows, which has no C/C++ toolchain by default) the install falls back to compiling from source and fails.
Related MCP server: Comet ML MCP Server
@cubenest/rrweb-core — vendored PostHog rrweb fork, PII masking primitives, large-DOM throttling, screenshot fallback, network/console capture abstractions, compression helpers. Used by both products. The fork is pinned by SHA + the substrate's NOTICE attributes both PostHog's plugin lineage and the upstream rrweb roots.
Same recording engine, same trust model, two different consumer surfaces:
tracelane ships test-time captures into a self-contained HTML artifact your team and AI agents can read offline.
peek ships live-browser captures into an MCP server your AI coding agent can query — and, with your explicit per-origin consent, drive the live page through.
peek's live read + act tools are gated by a five-level per-origin permission model (0 Off → 1 Read-only → 2 Suggest-only → 3 Act-with-confirm → 4 YOLO, the default is Level 1) with a destructive-action blocklist that always prompts. No telemetry, no cloud — everything stays in ~/.peek.
Shared upstream means one fork to track, one masking surface to harden, one license + DCO + security policy.
Pre-1.0. Alpha packages live on npm. Branch protection is on main (PR + CI + DCO + linear history). All workflows use Trusted Publishing OIDC + SLSA provenance. Renovate runs with a 7-day cooldown (21 days for the @posthog/rrweb lineage) and config:best-practices. tracelane has publicly launched (npm alpha + a live demo report); peek is alpha on npm and its Chrome MV3 extension is available on the Chrome Web Store.
Report a vulnerability via SECURITY.md. The shared threat model for both products lives in docs/SECURITY-NOTES.md.
Apache-2.0. See LICENSE.
Apache 2.0. DCO sign-off required on all contributions. See CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md.
GitHub Sponsors — github.com/sponsors/harry-harish (opening for launch)
The work is open-source and sustainable; sponsorship keeps it that way. See docs/SUSTAINABILITY.md for the maintenance cadence.
Execute an action (click/type/navigate/...) in the user's live browser. Requires per-origin permission Level 3+: Level 3 raises a confirm banner unless a valid confirmToken from request_authorization is passed; Level 4 auto-allows non-destructive actions; Level <3 denies. The destructive-action override (delete/remove/transfer/send/pay/purchase/buy/confirm/subscribe/logout/sign out/unsubscribe/cancel subscription/wire/withdraw) always prompts, even at Level 4. Every call is recorded to ~/.peek/audit.log.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id (origin context) from list_recent_sessions; determines the per-origin permission level. | |
| action | Yes | The browser action to execute (e.g. click/type/navigate; see the action schema). | |
| confirmToken | No | One-shot token from a prior request_authorization Allow, to skip the Level-3 banner. Omit to trigger the banner (Level 3) or rely on Level-4 auto-allow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description expands on annotations (destructiveHint=true) by explaining the destructive override prompt. It also adds that every call is recorded to an audit log, which is not in annotations. No contradiction with annotations.
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 paragraph that efficiently covers the core purpose, permission model, and audit logging. It is front-loaded with action types. Some minor restructuring could improve readability, but it remains concise.
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 tool's complexity (multiple action types, permission levels), the description covers the necessary behavioral context. It does not detail each action type, but the schema handles that. Output schema is absent but not critical. The coverage is adequate.
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%, but the description adds context beyond schema: sessionId comes from list_recent_sessions, confirmToken is from request_authorization. This enhances parameter understanding slightly above baseline.
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 purpose: 'Execute an action (click/type/navigate/...)' in the user's live browser. It uses a specific verb+resource and lists examples, distinguishing it from sibling read-only or analysis tools like get_dom_snapshot.
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 provides explicit usage guidance: it details permission levels (3+, 4), behavior of confirmToken banner vs auto-allow, and the destructive-action override always prompting. This helps the agent decide when and how to use the tool, including prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a runnable Playwright test (TypeScript) reproducing the user actions in a session: clicks, typing, navigation, and changes. Optionally limit to a [startTs, endTs] epoch-ms window. Returns the test source as text. Note: only single-value is represented (rrweb captures one value per input).
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. | |
| startTs | No | Only include actions at or after this epoch-ms timestamp. Omit to start at the session beginning. | |
| endTs | No | Only include actions at or before this epoch-ms timestamp. Omit to run through the session end. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the tool returns test source as text and notes the limitation that only single-value <select> is represented. This adds useful behavioral context not covered by annotations.
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 two sentences long, front-loading the core purpose and then adding optional details and a note. Every sentence is informative and there is no redundancy.
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?
For a tool with 3 parameters and no output schema, the description adequately explains what it does, what it returns, and a key limitation. It does not mention the source of sessionId but the schema references list_recent_sessions. Overall sufficient.
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%, so the schema already documents the parameters. The description reiterates the optional timestamp filtering but does not add significant new meaning beyond what the schema provides.
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 generates a runnable Playwright test reproducing user actions, specifying exactly which actions are included (clicks, typing, navigation, <select> changes). This distinguishes it from sibling tools like execute_action or get_dom_snapshot.
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 the tool is used to generate test code from session data but does not explicitly mention when to use it over alternatives or provide exclusions. The use case is inferable from the nature of the tool, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconstruct the page DOM as it existed at a timestamp (or a selector subtree within it) and return it as HTML. Applies structural/attribute/text mutations on top of the nearest full snapshot at or before ts. Returns JSON { baseSnapshotTs, mutationsApplied, html }; html clipped to 24000 chars. Fails if no full snapshot exists at or before ts.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. | |
| ts | Yes | Epoch-ms timestamp to reconstruct the DOM at. Use timestamps from get_session_summary, error rows, or get_user_action_before_error. | |
| selector | No | CSS selector to return only that subtree. Omit to return the full document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description does not contradict. The description adds behavioral traits beyond annotations: it applies mutations on top of the nearest full snapshot, returns JSON with specific fields (baseSnapshotTs, mutationsApplied, html), clips HTML to 24000 chars, and fails if no full snapshot exists. This provides useful context for agent decision-making.
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 two sentences, front-loaded with the main action, and includes essential details: timestamp usage, mutation application, return format, clipping limit, and failure condition. Every sentence adds value with no wasted words.
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 tool has 3 parameters, no output schema, and annotations provide readOnly hint, the description adequately covers the return structure and limits. It could mention behavior for invalid selectors, but overall it is complete enough for typical use cases.
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% for all three parameters. The description adds meaning: for ts, it specifies 'Epoch-ms timestamp' and suggests sources (get_session_summary, error rows, get_user_action_before_error). For selector, it clarifies behavior ('return only that subtree. Omit to return the full document'). This adds value beyond the schema 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 tool's purpose: 'Reconstruct the page DOM as it existed at a timestamp (or a selector subtree within it) and return it as HTML.' This is a specific verb (reconstruct) and resource (DOM at a timestamp), and it distinguishes from siblings like get_session_summary (metadata) or query_dom_history (likely different).
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 provides clear context: it uses timestamps from get_session_summary, error rows, or get_user_action_before_error, and mentions failure condition if no full snapshot exists. However, it does not explicitly state when not to use this tool or suggest alternatives, though the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List console error messages recorded in a session, oldest first. Each row has a numeric id to pass to get_user_action_before_error. Returns JSON rows ({ id, ts, level, message, stack }); message clipped to 500 and stack to 800 chars. For error counts at a glance, use get_session_summary first.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. | |
| since | No | Only return errors with ts >= this epoch-ms timestamp (to page forward through a long session). Omit to start from the beginning. | |
| limit | No | Maximum errors to return (1-200, oldest first; default 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only. The description adds details on return format (JSON rows with fields), clipping limits, and paging via 'since'. No contradictions.
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 purpose, efficient in conveying key details without waste.
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 purpose, output format, clipping, paging, and links to a sibling tool. Lacks explicit return value description, but enough given no output schema.
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%. The description adds context for 'since' (paging) and 'limit' (max 200, default 50), providing meaning beyond the schema.
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 it lists console error messages from a session, oldest first, and distinguishes from sibling tools like get_session_network_errors and get_session_summary.
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?
It explicitly suggests using get_session_summary for error counts, providing an alternative. However, it does not cover when not to use this tool in other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List failed or notable network requests in a session (HTTP status >= statusGte, or a transport-level network error), oldest first. Returns JSON rows ({ id, ts, method, url, status, statusText, resourceType, durationMs, errorText }); url and errorText clipped to 300 chars.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. | |
| statusGte | No | Minimum HTTP status treated as notable (100-599; default 400, i.e. 4xx/5xx). Transport-level errors are always included regardless. | |
| limit | No | Maximum requests to return (1-200, oldest first; default 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses output format (JSON rows with specific fields) and clipping of url and errorText to 300 chars. Annotations already set readOnlyHint=true, and the description adds detail about ordering (oldest first) and inclusive transport errors. No contradictions.
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: first defines scope and ordering, second describes return format and clipping. Every word adds value; no redundancy or unnecessary details. Properly front-loaded with key information.
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?
Without an output schema, the description provides sufficient structure of returned rows. Covers filtering, ordering, and limit. Lacks mention of error conditions or performance, but for a list tool, it is adequately 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 coverage is 100%, so parameters are well-described in schema. The description adds context about default values and transport errors always being included, but these are also present in the schema descriptions. Minimal additional meaning beyond schema.
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?
Title 'List failed network requests' and description 'List failed or notable network requests...' clearly state the verb (list) and resource (network requests in a session). It distinguishes from sibling tools like get_session_console_errors by specifying network failures with HTTP status thresholds and transport errors.
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 explains the filtering condition (status >= statusGte, transport errors always included) and defaults, but does not explicitly state when to use this tool versus alternatives like get_session_console_errors. Usage context is implied by name and siblings, not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an LLM-readable narrative summary of one session: pages visited, click/input/navigation counts, and error counts. Use this first for an overview before drilling into get_session_console_errors / get_session_network_errors. Returns a structured JSON summary.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description doesn't need to restate. It adds that the tool returns a structured JSON summary, which is helpful beyond annotations.
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-load the purpose and usage guidance, with zero wasted words. Efficient and well-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?
Despite no output schema, the description covers the main output fields (pages, clicks, errors). It references sibling tools and provides a complete picture for a simple tool.
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 a clear description for sessionId. The description's mention of 'one session' adds context but no new semantic details beyond the schema.
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?
Clearly states the tool gets a narrative summary of a session, listing specific data points (pages, counts, errors). Distinguishes from siblings by positioning as an overview tool before drilling into error-specific tools.
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 advises using this first for an overview before drilling into get_session_console_errors or get_session_network_errors, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconstruct what the user did right before a console error: returns the last window user actions (click/type/navigate) preceding the error, to explain how it was triggered. Returns JSON { errorId, errorTs, actions }. Get errorId from get_session_console_errors first.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. | |
| errorId | Yes | Console error id from get_session_console_errors. | |
| window | No | How many preceding user actions to return (1-50; default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description does not contradict. Beyond annotations, the description discloses the return format (JSON with errorId, errorTs, actions) and behavioral details: actions are the last N (default 10, max 50) preceding the error and include click/type/navigate. This adds meaningful 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?
The description is three sentences, front-loaded with core purpose, then details on usage and output format. Every sentence adds information without redundancy. No wasted words.
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?
Despite lacking an output schema, the description explicitly outlines the return JSON structure. It covers inputs (sessionId, errorId, window) and their origins. The tool is straightforward, and the description adequately prepares an agent to use it correctly. Minor omission: no mention of rate limits or potential errors, but readOnlyHint mitigates this.
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%, so the schema already documents all three parameters. The description adds value by explaining that 'window' refers to the number of preceding user actions to return, and that errorId comes from a specific sibling tool (get_session_console_errors). It also implicitly clarifies sessionId's origin via sibling context.
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 reconstructs user actions (click/type/navigate) right before a console error, specifying the resource and purpose. It distinguishes from siblings like get_session_console_errors (which gets error IDs) and generate_playwright_repro (another reconstruction tool) by focusing on the 'window' of actions preceding the error.
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 explicitly instructs to get errorId from get_session_console_errors first, providing a clear prerequisite. It implies when to use: after obtaining a console error and wanting to understand its trigger. While it doesn't explicitly list alternatives, the context of sibling tools makes it clear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's recorded browser sessions, newest first — the entry point for the get_session_* and DOM tools. Returns compact JSON rows ({ sessionId, origin, url, title, startedAt, ... }); free-text fields are clipped (origin 100, url 300, title 200 chars). If the MCP client scoped roots to specific origins and no origin filter is given, results are restricted to the client's scoped origins. Start here to obtain a sessionId, then call get_session_summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum sessions to return (1-50, newest first; default 10). | |
| origin | No | Filter to one origin, e.g. 'https://app.example.com'. Omit to list across all recorded origins (subject to client roots scoping). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description confirms read-only listing. Adds behavioral details: free-text field clipping (origin 100, url 300, title 200 chars) and origin scoping under client roots. No contradiction. Provides useful behavioral context beyond annotations.
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?
Extremely concise and well-structured: starts with action, then output format, then key behavioral notes, then usage recommendation. Every sentence is informative without redundancy.
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, but description sufficiently explains return format and fields. Covers key behaviors (clipping, scoping) and positions the tool in the workflow. Complete for a read-only list tool.
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 100%, so baseline is 3. Description adds minor value: clarifies that omitting origin means 'across all recorded origins (subject to client roots scoping)' and that limit defaults to 10 with newest-first ordering.
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 identifies the tool's purpose: listing browser sessions, newest first. It specifies the output format (compact JSON rows with fields) and distinguishes itself from sibling tools by positioning as the entry point for session-related tools.
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?
Provides explicit guidance: start here to get a sessionId, then call get_session_summary. Mentions origin filtering and client-root scoping, suggesting when to use filters. Lacks explicit when-not or alternative conditions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Timeline of attribute and/or text changes over a session for the node matching a CSS selector - useful for tracking how one element evolved. Returns JSON { selector, changes }. Use op to restrict to attribute changes or innerText; omit for both.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from list_recent_sessions. | |
| selector | Yes | CSS selector for the node to track, e.g. '#status' or '.cart-count'. | |
| op | No | Restrict to 'attributeChanges' or 'innerText'. Omit to include both. | |
| limit | No | Maximum changes to return (1-500; default 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds the return format and session context without contradicting annotations.
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 two sentences: the first defines purpose and resource, the second provides a key usage instruction. No redundant 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?
The description covers the core function and return shape, but lacks detail on the structure of individual changes and ordering, though adequate for a focused tool.
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%, and the description adds extra guidance on using 'op' to filter changes, enhancing the parameter semantics beyond the schema.
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 provides a timeline of attribute and text changes for a DOM node matching a CSS selector, distinct from siblings like get_dom_snapshot or get_session_summary.
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 gives a usage hint for the 'op' parameter but does not explicitly contrast with sibling tools or state when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the user to authorize a browser action via the side-panel banner (Level-3 act-with-confirm). On Allow, returns a one-shot confirmToken to pass to execute_action; on Deny, returns the denial. Every call - allowed or denied - is recorded to ~/.peek/audit.log. Use before execute_action when the origin is at permission Level 3, or to pre-authorize.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id (origin context) from list_recent_sessions; determines the per-origin permission level. | |
| action | Yes | The browser action to authorize (e.g. click/type/navigate; see the action schema). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: logging to ~/.peek/audit.log on every call, return of one-shot token or denial, and the pre-authorization use case. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are not contradicted; the description adds valuable 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?
Two sentences that front-load the core function, mechanism, and usage. No wasted words; every sentence earns its place. The structure logical: what -> how -> when.
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 complexity (multiple action types, permission levels, logging, token concept), the description covers the essential points: authorization flow, token usage, logging, and context (Level-3 or pre-authorize). Lacking explicit mention of what happens on timeout or error, but overall sufficient for an agent to use it correctly.
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 individual parameter descriptions (e.g., sessionId description explains its origin and purpose). The tool description adds little beyond the schema, so baseline 3 is appropriate. It does not explain the action sub-schemas but the schema already handles that.
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 purpose: requesting user authorization for a browser action via a side-panel banner. It distinguishes itself from sibling execute_action by specifying it returns a token or denial, and it uses a specific verb ('authorize') on a specific resource ('browser action').
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 when to use the tool: 'Use before execute_action when the origin is at permission Level 3, or to pre-authorize.' This provides clear context and differentiation from siblings, and implies not to use it when permission level is lower or when direct execution is allowed.
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. Dates show when Glama detected each change.
v1.0.1execute_action1 field changedInput schema / properties / action / anyOf[
{
"additionalProperties": false,
"properties": {
"button": {
"default": "left",
"enum": [
"left",
"middle",
"right"
],
"type": "string"
},
"nth": {
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"type": {
"const": "click",
"type": "string"
}
},
"required": [
"type",
"selector"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"delay": {
"default": 40,
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"const": "type",
"type": "string"
}
},
"required": [
"type",
"selector",
"text"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "navigate",
"type": "string"
},
"url": {
"format": "uri",
"type": "string"
}
},
"required": [
"type",
"url"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "back",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "forward",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "reload",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "scroll",
"type": "string"
},
"x": {
"type": "integer"
},
"y": {
"type": "integer"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "screenshot",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"timeoutMs": {
"default": 5000,
"minimum": 0,
"type": "integer"
},
"type": {
"const": "waitFor",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
}
][
{
"additionalProperties": false,
"properties": {
"button": {
"default": "left",
"enum": [
"left",
"middle",
"right"
],
"type": "string"
},
"nth": {
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"type": {
"const": "click",
"type": "string"
}
},
"required": [
"type",
"selector"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"delay": {
"default": 40,
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"const": "type",
"type": "string"
}
},
"required": [
"type",
"selector",
"text"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "navigate",
"type": "string"
},
"url": {
"format": "uri",
"type": "string"
}
},
"required": [
"type",
"url"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "back",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "forward",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "reload",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "scroll",
"type": "string"
},
"x": {
"type": "integer"
},
"y": {
"type": "integer"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "screenshot",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"timeoutMs": {
"default": 5000,
"minimum": 0,
"type": "integer"
},
"type": {
"const": "waitFor",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "enter",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"nth": {
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"type": {
"const": "dblclick",
"type": "string"
}
},
"required": [
"type",
"selector"
],
"type": "object"
}
]request_authorization1 field changedInput schema / properties / action / anyOf[
{
"additionalProperties": false,
"properties": {
"button": {
"default": "left",
"enum": [
"left",
"middle",
"right"
],
"type": "string"
},
"nth": {
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"type": {
"const": "click",
"type": "string"
}
},
"required": [
"type",
"selector"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"delay": {
"default": 40,
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"const": "type",
"type": "string"
}
},
"required": [
"type",
"selector",
"text"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "navigate",
"type": "string"
},
"url": {
"format": "uri",
"type": "string"
}
},
"required": [
"type",
"url"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "back",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "forward",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "reload",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "scroll",
"type": "string"
},
"x": {
"type": "integer"
},
"y": {
"type": "integer"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "screenshot",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"timeoutMs": {
"default": 5000,
"minimum": 0,
"type": "integer"
},
"type": {
"const": "waitFor",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
}
][
{
"additionalProperties": false,
"properties": {
"button": {
"default": "left",
"enum": [
"left",
"middle",
"right"
],
"type": "string"
},
"nth": {
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"type": {
"const": "click",
"type": "string"
}
},
"required": [
"type",
"selector"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"delay": {
"default": 40,
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"text": {
"type": "string"
},
"type": {
"const": "type",
"type": "string"
}
},
"required": [
"type",
"selector",
"text"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "navigate",
"type": "string"
},
"url": {
"format": "uri",
"type": "string"
}
},
"required": [
"type",
"url"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "back",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "forward",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"type": {
"const": "reload",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "scroll",
"type": "string"
},
"x": {
"type": "integer"
},
"y": {
"type": "integer"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "screenshot",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"timeoutMs": {
"default": 5000,
"minimum": 0,
"type": "integer"
},
"type": {
"const": "waitFor",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"selector": {
"type": "string"
},
"type": {
"const": "enter",
"type": "string"
}
},
"required": [
"type"
],
"type": "object"
},
{
"additionalProperties": false,
"properties": {
"nth": {
"minimum": 0,
"type": "integer"
},
"selector": {
"minLength": 1,
"type": "string"
},
"type": {
"const": "dblclick",
"type": "string"
}
},
"required": [
"type",
"selector"
],
"type": "object"
}
]v1.0.0execute_actiongenerate_playwright_reproget_dom_snapshotget_session_console_errorsget_session_network_errorsget_session_summaryget_user_action_before_errorlist_recent_sessionsquery_dom_historyrequest_authorizationEach tool targets a distinct aspect of browser session recording: action execution, session listing, error retrieval, DOM snapshots, history tracking, authorization, and repro generation. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., execute_action, get_session_summary, list_recent_sessions), making them predictable and easy to understand.
With 10 tools, the server provides a comprehensive yet focused set for browser session analysis and interaction—enough to cover core workflows without being overwhelming or too sparse.
The tool surface covers session listing, detailed error/network analysis, DOM inspection, action execution, and repro generation. Minor gaps like session deletion or full error browsing are not critical for the primary use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
Headless browser primitives for AI agents when sites need real JS rendering.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cubenest/rrweb-stack'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
