Menu
Use Replay MCP to inspect the contents of https://replay.io recordings.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Set up and run Playwright tests with Replay Browser to record test executions for debugging and performance analysis.
Record your application to gather performance data and debug issues. It enables users to install Replay ClI, record a session, upload and manage them.
Set up and configure Replay for recording Cypress tests with time-travel debugging.
| name | replay-mcp |
| description | Use Replay MCP to inspect the contents of https://replay.io recordings. |
| allowed-tools | Bash(replayio:*), mcp__replay |
This document provides an overview of the tools available when using Replay MCP and how to use these tools to investigate recordings.
Replay MCP is used to inspect the contents of https://replay.io recordings. These recordings perfectly capture everything that happened when a browser visited an app or other web page. You can explore and investigate the app's behavior as if you are a detective with a time machine.
Any question about the app behaved can be answered precisely using data from the recording. The most important thing to remember when using Replay MCP to investigate a recording is to not jump to conclusions:
The recording is essentially a gigantic database containing everything that happened while the app executed. A couple terms are useful for understanding this database:
Point: A specific point in the execution of the app. There is a unique point created for every time a JS statement executes or any other interesting event with potential side effects on the app's state.
Element: A reference for a particular DOM element that is independent of any particular point. Each DOM element has a lifetime for some portion of the recording.
Exploratory tools are used to discover what happened in the recording and when.
Error tools identify major errors that occurred in the app which may cause it to break.
Timeline tools describe sequences of events for what happened across the recording.
Source tools get information about the JS sources in the app and what code executed. When showing source code in these and other tools, hit counts are shown for each line. A blank value is used for lines that have no breakpoints.
Explanatory tools are used to understand why particular things happened in the recording.
Dependency tools track happens-before relationships between events in the recording. This is useful to understand why particular events happened or didn't happen.
Detail tools show additional details about the app's state at particular points.
When understanding JS behavior it is a good idea to find code relevant to the question being answered, see whether that code executed at all, and get details about the times when it executed. The Logpoint tool is extremely useful for this: see the value of the same expression whenever a statement executed, look for anything unexpected, and continue investigating from there.
When understanding the timing around a particular event (e.g. why it happened later than desired), find a point in the recording associated with the event and use the ControlDependency tool to explore the events that had to happen first and any associated delays.
