MCP server for AI agents

Replayfy runs a hosted MCP server at https://replayfy.com/mcp. An AI agent connects with one API key in a header — for a client that speaks HTTP, there is nothing to install. It can search your recordings, read a digest of any one of them, group a backlog by JavaScript error and, with the write scope, record a review verdict.

Available on every plan, Free included, with a limit of 600 per hour per key. The same key works with the REST API.

Connect

An owner or admin creates a key at Settings → API keys. The screen that shows the new key also prints the Claude Code command with it filled in.

Claude Code

claude mcp add --transport http replayfy https://replayfy.com/mcp --header "Authorization: Bearer rfk_YOUR_KEY"

Then ask, for example, “List my Replayfy sites”, or “Group last week's recordings on my store by JavaScript error and tell me which one to fix first.”

Cursor

In ~/.cursor/mcp.json, or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "replayfy": {
      "url": "https://replayfy.com/mcp",
      "headers": { "Authorization": "Bearer ${env:REPLAYFY_API_KEY}" }
    }
  }
}

${env:REPLAYFY_API_KEY} reads the key from the environment Cursor starts in, which keeps it out of the file.

VS Code

In .vscode/mcp.json. VS Code asks for the key the first time the server starts:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "replayfy-key",
      "description": "Replayfy API key",
      "password": true
    }
  ],
  "servers": {
    "replayfy": {
      "type": "http",
      "url": "https://replayfy.com/mcp",
      "headers": { "Authorization": "Bearer ${input:replayfy-key}" }
    }
  }
}

n8n

Add an MCP Client Tool node, point it at the endpoint above, and use Bearer authentication with your key. Replayfy speaks Streamable HTTP only, so pick that transport where the node offers a choice; a version that can only use the older SSE transport cannot connect.

Clients that only run local servers

A client that can only start a local (stdio) server reaches Replayfy through the open-source mcp-remote bridge, which npx fetches and runs on your machine. This is the one setup here that installs something:

{
  "mcpServers": {
    "replayfy": {
      "command": "npx",
      "args": ["mcp-remote", "https://replayfy.com/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer rfk_YOUR_KEY" }
    }
  }
}

The header is passed through an environment variable because some clients do not escape a space inside args. Replayfy does not offer OAuth sign-in, so a client that can connect to a remote server only through OAuth cannot connect to it directly.

Tools

5 tools. A key sees only the tools its scopes allow, and each tool checks the scope again when it runs. recordings:content unlocks no MCP tool: no tool returns raw recorded data.

Rate limit

• 600 per hour per API key. Every request counts: the handshake, the tool list and each tool call. The count covers the last hour, so it refills gradually.
• Past it, the endpoint answers HTTP 429 with a JSON-RPC error and Retry-After: 60.
• Tools also bound their own work per call — how many rows a search returns, how many new recordings an error grouping analyses. The bounds are in each tool's arguments above.

Protocol details

• Streamable HTTP, stateless. Requests are POST https://replayfy.com/mcp; GET and DELETE answer 405. There is no separate SSE endpoint.
• The only credential is Authorization: Bearer rfk_…. A Replayfy login cookie is never read. A missing or bad key answers 401.
• A key with neither recordings:read nor reviews:write is refused with 403: there would be nothing it could do.
• A browser request from another website is refused; MCP clients send no Origin and are unaffected.
• Call https://replayfy.com directly. Another host answers 400 rather than redirecting, because most clients drop the Authorization header across a redirect.

What an agent cannot do

• Watch anything. Replayfy records the DOM, not video. An agent reads a derived digest: click targets as CSS selectors, counts and timings. It never receives the recorded DOM or what a visitor typed into a form field; the recorder masks form fields before anything leaves the browser. It does receive text the page produced: the landing URL (with known secret-carrying query values masked), page paths, JavaScript error messages and the label your site passes to __sr.identify. Element labels such as aria-label are left out unless text labels are switched on for the site, which they are not by default.
• Delete, change settings, bulk-tag or invent labels. A verdict is written on one recording per call, with labels from the list your team curates, and every change is in the workspace audit log under the key's name.
• Call a partial recording reviewed by accident. Marking a recording with unrecorded stretches reviewed needs an explicit acknowledge_partial.

That text is attacker-controlled: the recording endpoint is public, so it holds whatever a visitor's browser sent. The digest fences it in an untrusted block and the tool descriptions tell the model never to follow it. That lowers the risk of a recorded page steering an agent; it does not remove it, which is why the write tool is limited to one verdict on one recording.

Next: the REST API reference, for scripts and automations.