Peek MCP Server

Exposes recorded browser sessions (rrweb DOM, console, network) to AI coding agents, fully local. Exposed over MCP by the peek mcp server, that capability becomes something an assistant can invoke while it works, not something you go and do afterwards.

What it actually does

Two OSS products on one rrweb-based substrate. Both ship as npm packages today.

• 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

Adding it to your client

@tracelane/cli on npm is all you need. Most clients run it directly, so configuration is a few lines and a restart.

Its toolset

Everything the assistant can do here goes through one of these:

• Product — One line
• Package — Status
• tracelane — The tracelane tool exposed by this server
• peek — The peek tool exposed by this server

Caveats

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the peek mcp server does with a few real requests.

When to reach for it

Plenty of browser automation servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Peek's toolset — Product, Package, tracelane and 1 more — is a fair guide to whether it matches your workflow. It is maintained by Cubenest; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.