An MCP Server, Frame Stepping, and Limits That Match the Plan

Five things landed on 22 August 2026, and the largest of them is that an agent can now read your bug reports directly.

Your agent can read the queue

Session Replay speaks the Model Context Protocol. There is one endpoint, POST /mcp, and nothing to install: an agent is given the address and authorized once, the same way it would be pointed at any other server it works with.

Five tools sit behind it. Four read and one writes:

• list_domains takes nothing and answers with every domain the account has claimed, the team that holds it, and whether it has been verified. It is where a reader starts, because everything below it is keyed by a domain.
• list_reports takes a domain and, optionally, a search term, a status, a date range and a page. It answers newest first.
• get_report takes a report’s share token and answers with the whole report.
• get_frame takes a token and a millisecond offset and answers with a still from the recording, as an image the agent can actually look at.
• set_status takes a token and a status, and moves the report through triage. What it writes reaches the person who filed the report.

The search behind list_reports now covers the reporter’s own comment as well as the URL and the page title, which is the difference between finding the report about a captcha and being told there isn’t one. The whole thing sits on an index now rather than reading the table.

Authorization is OAuth 2.1 with PKCE, and the token needs the mcp:read scope. The surface is Professional only, and a team below it is refused before any message is read, with the refusal naming the plan the team is actually on and where to change it. That last part matters more than it sounds: an agent can only relay what it was handed, and a generic refusal turns into “you have no bugs” by the time it reaches a person.

There is a page for it in the dashboard, beside Integration, giving the address, what authorizing takes, which of your domains are verified, and three worked messages in the order an agent would send them. It is visible on every plan. Only the address is dimmed below Professional.

Two things it deliberately will not do. There is no mcp:write scope yet, so set_status writes under the same read scope everything else uses; splitting the two starts with a consent screen that can explain the difference, and that is its own piece of work. And nothing on this surface deletes anything, moves a report between teams, or touches billing.

Frame stepping and playback speed

Finding the one frame where the layout broke used to mean scrubbing, overshooting, and scrubbing back. The share page carried the browser’s own controls and nothing else, and the speed setting Chrome keeps in an overflow menu is buried where it is not missing altogether.

There is now a slim band under the video with the two controls the browser does not give you: five playback rates - 0.25×, 0.5×, 1×, 1.5× and 2× - and a step backward and forward. , and . step, < and > walk the rates. The browser’s own control set is untouched below it, because replacing it would mean re-earning keyboard support, focus handling and full screen on a page that is public and reached by people who never signed up for anything.

Stepping is honest about what it can do. These recordings come from the browser’s own recorder, so they are variable frame rate and declare no rate at all, and there is no correct number of frames per second to add. Where the browser will say which frame it is presenting, a step lands on a real frame. Where it will not - Firefox, currently - a step is a nominal thirtieth of a second, and the buttons say so on their own faces rather than claiming an accuracy they do not have.

The console, network and interaction panels follow a step the same way they follow a seek, so the row belonging to the new frame is marked without doing anything else.

Retention answers from the plan you are on

A domain’s retention window was stamped when the domain was claimed and then never moved. A team that upgraded kept getting the window its old plan sold, on reports filed after the upgrade rather than only on the ones that predated it.

Retention is now asked of the plan at the moment a report is filed, and an upgrade brings reports already filed up to the new window by taking the later of the two dates. A downgrade moves nothing, and a longer retention set on a domain is never shortened by a plan change. A domain set to keep its reports forever keeps them forever.

The ceilings now match what each plan sells

This one was a mistake of ours, and it is worth writing down rather than burying.

Professional advertises thirty minutes of recording and Starter ten. The number of bytes each tier would actually accept had been set separately from the number of minutes it offers, and nobody had put the two figures beside each other. A capture runs at roughly 18.7 MB a minute, so Professional’s 250 MB ceiling was thirteen minutes, Starter’s 100 MB was nine, and the free defaults’ 50 MB was four against the five they offer. Every tier sold a length its own limit refused.

The ceilings are now 600 MB for Professional, 200 MB for Starter and 100 MB for the free defaults, which covers the length each one advertises with room to spare. The other half of it - the panel recording for the length its plan sells, rather than a flat ten minutes for everybody - shipped the next day in extension 1.5.0, so a Professional capture now runs to thirty minutes at both ends.

The integration library says who hit the bug

Version 0.3.1 of the library is published and served from our own pages. It carries identify(), a push-only context API: your page tells us who was looking and what they were looking at, and a report made afterwards carries it.

SessionReplay.identify({ email: 'ada@example.com', release: '2026.08.18' });

Five keys and no others - email, plan, orderId, release, requestId. Repeat calls merge, so a single-page application can add to it as it learns more rather than repeating everything; a key given as null is dropped, which is what a sign-out wants.

The library never goes looking for any of it. It reads nothing out of your DOM: no scraping a header for an email address, no guessing a plan from a badge. It holds what you pushed and hands it over only when the extension asks. A page that never calls identify() says nothing at all, and calling it never starts a recording.

The same release rewrote what a visitor on Safari or Firefox sees when they press the button. It used to say the browser could not run the extension, offer the page link, and stop. That reader is the least informed and most asked-of audience this library has, and they were being asked to go and find another browser on the strength of nothing. They now get what the report would carry, that it costs nothing, and where to read more - all of it already written and already translated, and withheld by a state check.

Smaller things in the same week

• The API answers in the language the caller asks for.
• The typefaces are served from our own machines. The three webfont CDNs are gone.
• The sitemap no longer dates every page by whenever the nightly job last ran.
• The features page had been denying we have an MCP server, which was true when it was written.