Utilisez Replay MCP avec Sokko.

Inspect the annotations in a recording. Annotations are timestamped records attached by the runtime and integrations (e.g. Cypress, Playwright, React DevTools, network, localStorage). Call with no arguments to list all annotation kinds in the recording with their counts. Pass a 'kind' to return the annotation data for that kind (paginated, optionally filtered by text). For WebSocket traffic (DOMWebSocket annotations), use the WebSocketMessages tool instead.

Show console API messages (console.log, console.warn, console.error, etc.). Note: console errors are distinct from runtime exceptions — use UncaughtException and ReactException for those. Start with mode 'summary' for an overview with message counts and the last errors/warnings. Use 'messages' to browse the full paginated list (filter by level, text, node_modules visibility). Use 'message-detail' with a point reference for full detail on a single message including stack trace. Call RecordingOverview first for broader context.

Describes the application state at a code execution point. Shows the containing function with executed/not-executed annotations, variable values, and timestamps. Use dependencyChain=true to trace the full causal chain back to the origin event. Get execution points from other tools (ConsoleMessages, ReactRenders, ReduxActions, Logpoint, etc.).

Evaluates an expression at a code execution point. Use for ad-hoc value inspection beyond what DescribePoint shows. Expressions must be synchronous and immediately inspectable. Do not use async functions or promises; replay cannot inspect their eventual results. Defaults to frame scope; use global scope explicitly when needed. String results are returned in full up to maxStringLength characters (default 100000); longer strings end with a truncation notice giving the stringOffset to read the next part. String results longer than about 8,000 characters are read by evaluating the expression a second time, so use a single, side-effect-free expression to get the full text.

Computes execution delays for functions based on their source length and the delay before the first breakpoint in each function executes. Each breakpoint is attributed to the innermost function covering it, and each function's weight is computed as its source length minus the sum of its children's lengths.

Gets the React component being rendered at a code execution point.

Generates an app.replay.io link for users to inspect a given execution point.

Gets the call stack at a code execution point. Use to understand execution context. Pair with DescribePoint for full state.

Get size, layout, ancestry and render point information for a DOM element. Find relevant code before inspecting elements. Only use this tool sparingly — expensive, requires full DOM layout computation. Prefer ReactComponentTree for component structure.

List the sources in the recording.

Describe all the accesses made to localStorage. Start with mode 'summary' (default) for a grouped overview: keys with access counts, final values, and timing. Use 'operations' to browse the full chronological access list with pagination. Use keyFilter to narrow by key name (substring match). For large apps, consider filtering by key pattern in results.

Evaluates an expression at breakpoint hits for a given path and line number. Returns up to 20 hits with their expression evaluation results. Use beginPoint/endPoint to narrow the range. Use column to target a specific statement on the line. Find source paths with ListSources or SearchSources first.

Analyze network requests in the recording. Start with mode 'summary' (default) for high-level stats: total count, failed/slow counts, status code distribution, and top domains. Use 'requests' to browse a paginated table of all requests (filterable by urlFilter, startTime, endTime). Use 'detail' with requestId (from the ID column in the 'requests' table) for full request/response headers, body content, event timeline, and backend function analysis. RECOMMENDED workflow: summary → requests → detail. Call RecordingOverview first for broader context about the recording.

Show all steps taken by Playwright in the recording. Start with mode 'summary' for a test overview with pass/fail status and duration. Use 'steps' with testIndex to see the step list for a specific test (get indices from 'summary'). Use 'step-detail' with stepNumber for inspector protocol commands of a single step (get step numbers from 'steps'). Use 'test-source' with testIndex to read the test source code. For failed tests, use failedOnly=true in 'steps' mode to focus on failures. Call RecordingOverview first for broader context.

Profiles dependency graph entry execution between two points in a recording. Enumerates all dependency graph entries including React fiber renders and effect calls, computes the execution associated with each by progress counter differences, traces each entry back to its source via the dependency chain, and groups results by source ordered by execution amount.

Profiles the native C++ replay engine using stack sampling between two execution points. Runs the replay engine from the begin point to the end point while collecting periodic stack samples, then analyzes the samples to produce a flat profile of where time is spent in native code.

Profiles JS statement execution between two points in a recording. Fetches all breakpoint hits between the points, breaks them down by function, resolves function names, and computes a flat profile and call tree showing statement hits per function and its callees.

Get the structure of the committed/mounted React component tree at a point in time. Start with mode='summary' for an overview of component counts and top-level structure. Use mode='tree' to see a paginated, depth-limited hierarchy with collapse markers. Use mode='subtree' with 'component' to focus on a specific component's ancestors and descendants. Use 'nameFilter' to search for components by name. Use 'hideFilter' to remove noise (e.g. Provider, Consumer). For render-level analysis (timing, waste, causes), use ReactRenders instead.

Describe any exceptions thrown which caused React to unmount. This finds React error boundary crashes and render-phase exceptions. For non-React uncaught exceptions, use UncaughtException instead. RecordingOverview includes an error summary — call that first for context.

Run all deterministic React performance checks on a recording and return prioritized findings. Each finding includes user-visible impact, specific timing, affected components, and suggested actions. Use this for a comprehensive performance audit — it detects heavy commits (>50ms), render loops, expensive state updates, and more. Call RecordingOverview first for broader context.

Analyze React renders in a recording. Start with mode 'summary' for a recording-wide overview of commits and render time. Use 'waste-rank' to find components with the most wasted renders. Use 'commits' to browse render commits chronologically. Use 'commit' with commitIndex for single commit detail (get indices from 'commits'). Use 'component' with componentName to see a component across all commits (get names from 'waste-rank'). Use 'fiber' with fiberId to see all renders for a specific fiber instance (add includeProps=true for prop values at each render). Use 'trigger-detail' with commitIndex to trace the dependency chain (click, network, dispatch) that triggered a commit. Use 'commit-fibers' and 'fiber-cause' for fiber-level causation analysis. Call RecordingOverview first for broader context.

Read up to 50 lines of code centered around the given line and see what statements executed.

Provides a comprehensive overview of a recording: test results, errors, environment info, network activity, React render performance, and suggested next investigation steps. Call this first to understand what happened in a recording before diving into specific tools. NOTE: The first call on a cold recording may take 3-4 minutes while initial data is computed. Set a longer timeout for this tool. Subsequent calls will be fast.

Analyze Redux actions in a recording. Currently covers Redux/RTK dispatches via source-level instrumentation. Start with mode 'summary' to see action type frequency and correlation stats. Use 'actions' to browse dispatches chronologically (filterable by actionType substring). Use 'action-detail' with actionIndex for full correlation data: timing breakdown, selector stats, component render timings, and dispatch origin location. Use 'impact' with actionIndex for a render impact report with optimization recommendations. Use 'state-shape' to see a lightweight key/type listing of the state tree (~200–400 tokens). RECOMMENDED: use state-shape FIRST to understand the state structure, then drill in. Use 'action-state' with actionIndex to see actual state values at a dispatch point. STRONGLY RECOMMENDED: use the 'path' param (e.g. path='auth.user') to drill into specific subtrees instead of dumping the entire state tree. Call RecordingOverview first for broader context about the recording.

Lists all screenshot timestamps in the recording, or fetches a screenshot at a given timestamp. Call without timestamp to list all available timestamps. Call with timestamp to get a screenshot URL with mouse position, movements, and time since last click. Set base64=true for raw image data. RecordingOverview suggests a key screenshot timestamp — call that first.

Search the sources in the recording and see which statements executed. Note: Playwright test runner code runs in Node outside the browser recording and won't appear here. Use PlaywrightSteps(mode: test-source) for Playwright test source.

Analyze TanStack Query (React Query) cache events in a recording. Start with mode 'summary' for an overview of all queries with lifecycle stats. Use 'query-events' with queryHash to see the event timeline for a specific query. Use 'query-timeline' for a chronological view across ALL queries. Use 'query-state' with queryHash + eventIndex to inspect cached data at a specific event point. Observer-internal events are filtered by default; use eventType filter to include them. Call RecordingOverview first for broader context about the recording.

Describe uncaught exceptions and unhandled promise rejections (runtime errors not caught by try/catch). Reports up to 5 distinct errors in time order. Each entry gives the throw site and the first non-library caller, or just the error text when the recording has no matching throw (e.g. script syntax errors). For React-specific exceptions that unmounted the app, use ReactException instead. RecordingOverview includes an error summary — call that first for context.

Show all user interactions (clicks and key presses) in the recording. Start with mode 'summary' (default) for interaction counts by type, time range, top keys pressed, and activity timeline. Use 'interactions' to browse a paginated chronological list with point references for DescribePoint, Evaluate, or GetStack. Use type filter ('click' or 'keypress') to narrow by interaction kind. Useful for understanding the sequence of user actions that led to a bug.

Starts processing a recording if needed and reports its status. Call this before other tools on a recording that may not be loaded yet. Returns state 'ready' when other tools will respond quickly, 'processing' with phase, progress counts, and an estimated time remaining (eta, may be null) while it is still loading, or 'crashed'/'failed' with an error when the recording cannot be analyzed. Safe to call repeatedly; call again while the state is 'processing'. msSinceLastProgress only indicates a stall in the 'starting' and 'scanning' phases; in 'analyzing' there are no progress updates while the instrument engine runs, so treat eta.exceeded as the sign that something is wrong. The eta is recomputed on every call and can go up, for example when the instrument engine starts; reset any deadline when phase or instrumentEngine.state changes. A crashed or failed server is shut down after a few minutes, and the next call starts a fresh one with a new startedAt; retry at most once since crashes often repeat. When a server replaced an earlier one for the same recording, previousRun says how the earlier one ended; previousRun.unexpected means it died without reporting a crash. That can be the recording (for example running out of memory) or the infrastructure (for example a node reclaimed without warning), so keep waiting on the new server and treat it as a crash only if the next server for the recording also ends unexpectedly.

Inspect the WebSocket connections in a recording and the messages sent and received on them. Default mode 'connections' lists each connection with its URL, status (open, open until the recording ended, still connecting, never connected, failed to connect, dropped, closed by client, closed) and message counts. Mode 'connection' lists the messages on a connection (paginated, filterable by direction and text); sent messages include a point reference for the send() call. Mode 'message' shows the contents of one message by messageId. JSON messages too large to show whole are shown as an outline of keys, types and sizes; pass path (e.g. 'result.items.3') to see one part. Unknown connectionId or messageId values are rejected with the list of valid IDs.

Analyze Zustand stores in a recording. Start with mode 'summary' to see all stores and their setState call counts. Use 'store-events' with a storeId to browse setState calls chronologically. Use 'store-state' with storeId and eventIndex to inspect the state at a specific setState call (shows the updater identity, incoming changes, merged result, and previous state). Call RecordingOverview first for broader context about the recording.