Tools Reference

This page documents every tool exposed by the Replay MCP server at https://dispatch.replay.io/nut/mcp, the server that lets a coding agent inspect a Replay recording. To connect an agent to it, see Connect the Replay MCP server. This is a different server from the Replay QA MCP server, which manages QA projects and bugs; that one is documented under Replay QA API and MCP tools.

Agents discover these tools automatically once connected. You do not need to memorize them, but knowing what is available helps you write better prompts and follow what your agent is doing during an investigation. Tools are grouped by category below, with a typical investigation workflow for each.

Most tools take a recordingId and many take a mode. Where a tool has modes, summary is the starting point and the other modes drill into detail. Every tool that returns events also returns execution points, which the Code Inspection tools accept as input.

Start here

Tool	Purpose
RecordingOverview	One-call summary of a recording: test results, errors, environment, network activity, React render performance, a key screenshot timestamp, and suggested next steps. Agents call this first on any recording.

Source Code & Console

These tools help agents orient themselves within a recording — browsing files, reading code, viewing output, and seeing what the app looked like.

Tool	Purpose
ListSources	List the source files in the recording, with optional glob filtering.
ReadSource	Read up to 50 lines of source centered on a line, annotated with which statements executed during the recording.
SearchSources	Regex search across all source files, with results annotated to show which matches are in code that ran. Playwright test runner code runs in Node and is not in the browser recording; use PlaywrightSteps for it.
ConsoleMessages	Console output (log, warn, error, and so on). summary mode gives counts and the last errors and warnings; messages mode browses the full list with level and text filters. Console errors are not exceptions.
UserInteractions	Clicks and key presses. summary mode gives counts, time range, and an activity timeline; interactions mode lists them chronologically with execution points.
Screenshot	List available screenshot timestamps, or fetch a screenshot at a timestamp with mouse position and recent movement. RecordingOverview suggests a key timestamp.
Annotations	Timestamped records attached by the runtime and integrations (Cypress, Playwright, React DevTools, network, localStorage). Call with no arguments to list kinds and counts; pass a kind to read them.

Typical workflow

After RecordingOverview, an agent checks ConsoleMessages for errors or unexpected output, uses UserInteractions to reconstruct what the user did, then SearchSources to find the relevant code and ReadSource to examine it. Screenshot correlates code behavior with what the user saw. ListSources helps when source paths in the recording differ from local paths because of source maps and build tools.

Code Inspection

These tools inspect application state at specific moments during execution — variables, expressions, and call paths.

Tool	Purpose
DescribePoint	Describe application state at an execution point: the containing function with executed and not-executed lines marked, variable values, and timestamps. dependencyChain=true traces the causal chain back to the originating event.
Evaluate	Evaluate a synchronous JavaScript expression at an execution point. Like the DevTools console, but at any moment in the recording. Promises and async functions cannot be inspected.
GetStack	Get the call stack at an execution point.
Logpoint	Evaluate an expression at every hit of a source line (up to 20), optionally narrowed to a point range or a column. Shows how a value changes across executions of the same code.
InspectElement	Size, layout, DOM ancestry, and render point for a DOM element. Expensive; agents use it sparingly and prefer ReactComponentTree for structure.

Typical workflow

After finding suspicious code with SearchSources, an agent uses Logpoint to see how values change at that location. When a hit looks wrong, it uses DescribePoint for full context, Evaluate to test hypotheses ("what would this expression return here?"), and GetStack to see how execution arrived there. InspectElement is for layout or rendering bugs where DOM structure matters.

Error Analysis

Quick ways to find what went wrong. RecordingOverview already includes an error summary; these give the detail.

Tool	Purpose
UncaughtException	Uncaught runtime exceptions (errors not caught by try/catch), with stack traces and execution points.
ReactException	Exceptions that caused React to unmount: error boundary crashes and render-phase errors.

Typical workflow

These are often the first tools an agent reaches for when debugging a crash. UncaughtException covers any unhandled error; ReactException finds errors that broke the React tree. Both return execution points for the Code Inspection tools.

Network & Storage

Inspect external communication and client-side persistence.

Tool	Purpose
NetworkRequest	summary mode gives totals, failed and slow counts, status distribution, and top domains. requests mode browses a paginated table filterable by URL and time range. Request detail includes headers, body, status, and timing.
LocalStorage	summary mode groups localStorage accesses by key with counts, final values, and timing. operations mode lists every access chronologically.

Typical workflow

For data bugs, an agent checks NetworkRequest for API calls that failed, were slow, or returned unexpected data, filtering by URL to focus on an endpoint. LocalStorage reveals stale cached values, missing keys, and unexpected overwrites.

React Analysis

Tools for understanding React application behavior, from component tree structure down to why a single fiber re-rendered.

Tool	Purpose
ReactComponentTree	The mounted component tree at a point in time. summary gives counts and top-level structure; tree is a paginated, depth-limited hierarchy; subtree focuses on one component's ancestors and descendants. Filters by name and hides noise such as providers.
GetPointComponent	The React component being rendered at an execution point.
ReactRenders	Multi-mode render analysis (see below).
ReactPerformanceInsights	Runs every deterministic React performance check and returns prioritized findings with user-visible impact, timing, affected components, and suggested actions. Detects heavy commits (over 50ms), render loops, expensive state updates, and more.

ReactRenders: deep render analysis

ReactRenders is the most feature-rich tool in the MCP server. Its modes let agents drill progressively into render behavior:

• summary — a recording-wide overview of commits and render time. The starting point for any React performance investigation.
• waste-rank — components ranked by wasted renders (renders that produced no visible change). Directly identifies optimization targets.
• commits — a paginated chronological list of every React commit (batch of renders).
• commit — detail for one commit: which components rendered and why.
• trigger-detail — the dependency chain (click, network response, dispatch) that triggered a commit.
• component — one component's render history across all commits.
• fiber — every render of one fiber instance, optionally with prop values at each render.
• commit-fibers — all fiber instances of a component within one commit.
• fiber-cause — the deepest level: why one fiber instance re-rendered — which prop changed, which state update fired, which context value shifted.

A typical React performance investigation flows summary → waste-rank → component → commit-fibers → fiber-cause. All modes accept time and execution point ranges.

Typical workflow

For a performance audit, agents start with ReactPerformanceInsights and follow its findings into ReactRenders. For a rendering bug, ReactComponentTree shows the structure at the moment in question, ReactRenders in component mode shows that component's history, and trigger-detail or fiber-cause shows what set the render off.

State Libraries

Instrumented analysis of common state management libraries. Each tool's summary mode lists what the recording contains; the other modes step through events and inspect state at a specific event.

Tool	Purpose
ReduxActions	Redux and Redux Toolkit dispatches. summary gives action type frequency; actions browses dispatches; action-detail shows timing, selector stats, component render timings, and dispatch origin; impact reports render impact with recommendations; state-shape lists the state tree's keys and types; action-state shows state values at a dispatch, narrowed with a path such as auth.user.
ZustandStores	Zustand stores. summary lists stores and setState counts; store-events browses calls chronologically; store-state shows the updater, incoming changes, merged result, and previous state at one call.
TanStackQueries	TanStack Query (React Query) cache events. summary gives lifecycle stats per query; query-events shows one query's timeline; query-timeline shows all queries chronologically; query-state shows cached data at an event.

Typical workflow

For a "the UI shows the wrong data" bug in a Redux app, an agent runs ReduxActions state-shape to learn the tree, actions to find the dispatch near the symptom, then action-state with a path to see what the store held. impact turns a slow interaction into a list of the renders a dispatch caused. The same pattern applies to ZustandStores and TanStackQueries.

Test Analysis

Tools for investigating Playwright test recordings.

Tool	Purpose
PlaywrightSteps	summary gives each test's pass/fail status and duration; steps lists a test's steps (use failedOnly=true to focus on failures); step-detail shows the inspector protocol commands for one step; test-source reads the test's source.

Typical workflow

For a failed Playwright test, the agent uses PlaywrightSteps to find the failing step and its error, reads the test with test-source, uses Screenshot to see the page at the failure, and switches to the Code Inspection tools to understand why the expected element or condition was not met.

Performance Profiling

Tools for understanding where execution time is spent. Each accepts begin and end execution points to focus on a range.

Tool	Purpose
ProfileStatements	Profile JavaScript statement execution between two points: a flat profile and call tree of statement hits per function.
ProfileGraph	Profile dependency graph entries (React fiber renders, effect calls) between two points, grouped by source and ranked by execution amount. Shows what React work dominated.
ExecutionDelay	Per-function execution delays within one source file, computed from source length and the delay before each function's first breakpoint executes.
ProfileSampling	Stack sampling of the native replay engine itself between two points. This profiles the Replay runtime, not the recorded application; it is mainly for internal debugging of replay performance.

Typical workflow

For JavaScript performance issues, ProfileStatements identifies hot code paths. ProfileGraph is the React-specific view of which renders and effects consumed the most execution. ExecutionDelay gives a per-function view within one file. For React apps, ReactPerformanceInsights is usually the faster first step.

Utility

Tool	Purpose
GetPointLink	Generate a shareable app.replay.io URL for an execution point, so a person can open Replay DevTools at the exact moment the agent is investigating.