LogNroll MCP Server: Connect AI Agents to Your Session Data
Your sessions already hold the answers—the agent just needs a way to read them. LogNroll's MCP server gives Cursor and other AI agents direct, scoped access to raw session data, so a natural-language question becomes a query over events, errors, network calls, and heatmaps.
TL;DR
LogNroll runs a public MCP server at https://mcp.lognroll.com/mcp that exposes nine read-only tools over the raw data behind every session. Connect it in Cursor with a streamable-HTTP server entry, authorize with your LogNroll email and a six-digit code, and start asking questions like "which sessions ended in checkout errors?". Every call is scoped to your team's companies; nothing is ever mutated.
LogNroll Team
Product & Analytics
This article covers the LogNroll MCP server: what it exposes, how to connect Cursor, example prompts, and how authentication and scoping keep raw session data private.
Why an MCP server for session data?
Session replay answers what happened in the browser, but the answer lives in raw data: protobuf event streams, error records, network requests, heatmap aggregates. MCP (Model Context Protocol) is the standard that lets an AI agent read that data the same way a browser reads a database—through a small, typed set of tools instead of unstructured copy-paste.
Without a connection, an agent can only reason about what you paste into the prompt: one stack trace, one screenshot, one network log. With it, the same agent can pull the session list, drill into a specific replay, and cross-reference errors against network failures on its own. LogNroll's MCP server exposes the raw session data—the same decrypted, unzipped event stream the player renders—directly to your chat or coding agent.
What the LogNroll MCP server exposes
The server reads the same Mongo collections and S3 archives as the player API, and it packages that access into nine read-only tools. Everything the dashboard can show you, an agent can query:
| Tool | What it returns |
|---|---|
list_companies | Companies the signed-in user belongs to (scoped to active team memberships) |
list_sessions | Sessions with filters on status, time range, user, and device |
search_sessions | Substring search across user email, user name, device id, and page URL |
get_session | Full detail for one session, including metadata and user identity |
get_session_stats | Full-archive analysis: per-event-type counts, duration, errors, network summary |
get_session_events | Raw JSON events in order (heavy event types excluded unless requested) |
get_session_errors | The sessionErrors recorded for a session |
get_session_network | Backend requests plus a request/response summary |
get_session_heatmap | HeatMapClicks and scroll-heat (v2) aggregates for a session |
Large payloads are truncated with an explicit "truncated": true marker so the agent never silently analyzes partial JSON, and high-frequency event types (mouse moves, DOM mutations, styles) are excluded from event reads unless you ask for them with a types= filter. The tools are designed for analysis, not for drowning the model in raw telemetry.
Connecting an MCP client (Cursor) in three steps
Add the server in your MCP client
In Cursor, open Settings → MCP and add a new server with type "streamable HTTP" and URL https://mcp.lognroll.com/mcp. Claude Desktop and other clients use the same URL via the SSE or HTTP transport.
Authorize with your work email
The browser opens an OAuth flow: enter the email you use in LogNroll, receive a six-digit code from [email protected], and paste it. That is the whole login—no API keys to copy, no tokens to paste into config files.
Ask questions about your sessions
Once connected, the agent lists the available tools and can answer questions like "which sessions yesterday ended in checkout errors?" directly from raw session data. Access tokens last 12 hours and refresh tokens rotate for 30 days, so reconnection is rare.
Engineering note
The network endpoint authenticates with standard OAuth 2.0 (authorization code + PKCE, public client). The browser flow asks for your LogNroll email, sends a one-time six-digit code by email, and exchanges it for a 12-hour access token with a rotating 30-day refresh token. The legacy SSE transport (/sse) uses the same gate; a helper CLI (mcp-login) can mint a token for clients without browser-OAuth support.
Example prompts against your sessions
Once connected, treat your MCP client like an analyst who can read every replay. Prompts that work well:
- List sessions from the last 24 hours that had a rage click, and tell me which pages they happened on.
- Summarize session <id>: what did the user do, which network requests failed, and what errors were recorded?
- Which errors occurred during checkout this week, and show me one session I should replay first?
- Compare scroll depth and dwell time for the pricing page this week versus last week.
- Find sessions from a specific test user or device and show their event timeline in order.
The value compounds when prompts chain tools: search_sessions finds the sessions, get_session_stats summarizes each one, and get_session_errors narrows to the failures. What used to be a half-hour of dashboard clicking becomes a conversation.
Scoping and auth on the MCP endpoint
Every call is scoped to your account
The server identifies the user from the OAuth token and restricts every tool call to companies where that user is an active team member. list_companies returns only your companies, and the session tools require membership in the session's company.
Read-only by design
The tools expose raw session data for analysis, but nothing on the server can mutate sessions, replay archives, or settings. An agent with a bad prompt cannot break anything—the worst case is a question that returns no data.
Local stdio stays fully private
The command-line (stdio) transport is intended for local development and keeps full access without authentication, because it runs on your machine. The network endpoint is where the OAuth gate and company scoping apply.
What this means in practice
A teammate's MCP session sees only the companies they belong to, and only the sessions inside those companies. If someone leaves the team, their active membership drops and the server stops returning data for that company on the next request—no token revocation needed, because authorization is re-checked per call.
Where LogNroll fits
This endpoint is the same pipeline as the player, exposed as tools. The data an agent reads is byte-for-byte what the replay renders: the same decryption, the same archive layout, the same event ordering. So when an agent says a session had a failed checkout, you can open that exact replay and watch it—the conversation and the visual evidence agree.
For the capture pipeline that produces this data, see our session replay architecture guide. To build your own endpoints on top of internal systems, read Turning a Bitbucket server into an MCP endpoint, and to turn the data into debugging sessions, When Error Logs Lie: Reproducing Production Failures with Session Replay.
Conclusion
An MCP connection turns session data from a dashboard you browse into a corpus your agents can read. The connection takes three steps—add the server URL, authorize with your email, ask a question—and the scoping model keeps it safe for real production data. The next time you want to know what really happened in checkout, ask the agent instead of opening twenty replays.