MCP-сервер, покадровый шаг и лимиты, совпадающие с тарифом

22 августа 2026 года вышло пять вещей, и самая крупная из них такая: агент теперь может читать ваши отчёты об ошибках напрямую.

Ваш агент может читать очередь

Session Replay говорит на Model Context Protocol. Точка входа одна, POST /mcp, и устанавливать ничего не нужно: агенту дают адрес и один раз выдают доступ, ровно так же, как его направили бы на любой другой сервер, с которым он работает.

За этой точкой стоят пять инструментов. Четыре читают, один пишет:

• list_domains не принимает ничего и отвечает списком всех доменов, которые заявил аккаунт, с командой, которой домен принадлежит, и признаком, подтверждён ли он. С него начинает тот, кто читает, потому что всё остальное привязано к домену.
• list_reports принимает домен и, по желанию, поисковую строку, статус, диапазон дат и страницу. Отвечает от новых к старым.
• get_report принимает токен доступа к отчёту и отвечает отчётом целиком.
• get_frame принимает токен и смещение в миллисекундах и отвечает кадром из записи, картинкой, на которую агент действительно может посмотреть.
• set_status принимает токен и статус и двигает отчёт по разбору. То, что он пишет, доходит до человека, который отчёт отправил.

Поиск, стоящий за list_reports, теперь захватывает и комментарий самого отправителя, а не только адрес страницы и её заголовок, и это разница между тем, чтобы найти отчёт про капчу, и тем, чтобы услышать, что такого отчёта нет. Всё это опирается теперь на индекс, а не читает таблицу.

Авторизация идёт по OAuth 2.1 с PKCE, и токену нужна область mcp:read. Сама поверхность доступна только на Professional, и команде на более низком тарифе отказывают ещё до того, как прочитано хоть одно сообщение; в отказе названы тариф, на котором команда находится на самом деле, и место, где его сменить. Последнее важнее, чем кажется: агент может передать только то, что ему вручили, а общий отказ по пути к человеку превращается в “ошибок у вас нет”.

В панели для этого есть отдельная страница, рядом с Интеграцией: на ней адрес, что требуется для выдачи доступа, какие из ваших доменов подтверждены, и три разобранных сообщения в том порядке, в каком их отправил бы агент. Она видна на любом тарифе. Ниже Professional приглушён только адрес.

Двух вещей она сознательно не делает. Области mcp:write пока нет, поэтому set_status пишет под той же областью чтения, которой пользуется всё остальное; разделение этих двух начинается с экрана согласия, способного объяснить разницу, а это работа сама по себе. И ничто на этой поверхности ничего не удаляет, не переносит отчёт между командами и не трогает оплату.

Покадровый шаг и скорость воспроизведения

Чтобы найти тот единственный кадр, где сломалась вёрстка, приходилось таскать ползунок, промахиваться и таскать обратно. На странице со ссылкой были только собственные элементы управления браузера, а настройка скорости, которую Chrome держит в дополнительном меню, закопана там, где она вообще есть.

Теперь под видео есть узкая полоса с двумя элементами, которых браузер не даёт: пять скоростей воспроизведения - 0.25×, 0.5×, 1×, 1.5× и 2× - и шаг назад и вперёд. , и . шагают по кадрам, < и > перебирают скорости. Собственный набор кнопок браузера остался нетронутым ниже, потому что заменить его значило бы заново заслужить работу с клавиатуры, обработку фокуса и полный экран на странице, которая открыта всем и до которой доходят люди, никуда не регистрировавшиеся.

Шаг честен насчёт того, что он умеет. Эти записи делает собственный рекордер браузера, поэтому у них переменная частота кадров и никакой частоты они не объявляют, и правильного числа кадров в секунду, которое можно было бы дописать, попросту нет. Там, где браузер соглашается сказать, какой кадр он показывает, шаг попадает на настоящий кадр. Там, где не соглашается, а это сейчас Firefox, шаг равен условной тридцатой доле секунды, и кнопки говорят об этом прямо на себе, а не заявляют точность, которой у них нет.

Панели консоли, сети и взаимодействий следуют за шагом так же, как следуют за перемоткой, поэтому строка, относящаяся к новому кадру, отмечается сама, без каких-либо дополнительных действий.

Срок хранения отвечает по тому тарифу, на котором вы сейчас

Окно хранения для домена фиксировалось в момент, когда домен заявляли, и дальше не двигалось никогда. Команда, перешедшая на тариф выше, продолжала получать окно, которое продавал её старый тариф, причём на отчётах, отправленных уже после перехода, а не только на тех, что были до него.

Срок хранения теперь спрашивается у тарифа в момент отправки отчёта, а переход на тариф выше подтягивает уже отправленные отчёты к новому окну, беря более позднюю из двух дат. Переход на тариф ниже не двигает ничего, а более длинный срок хранения, выставленный на домене, никогда не сокращается сменой тарифа. Домен, которому велено хранить отчёты вечно, хранит их вечно.

Потолки теперь совпадают с тем, что продаёт каждый тариф

Это была наша ошибка, и её стоит записать, а не закопать.

Professional обещает тридцать минут записи, Starter десять. Число байтов, которое каждый уровень на самом деле принимал, задавалось отдельно от числа минут, которое он предлагает, и никто не положил две эти цифры рядом. Запись идёт примерно по 18,7 МБ в минуту, так что потолок Professional в 250 МБ был тринадцатью минутами, 100 МБ у Starter девятью, а 50 МБ у бесплатных настроек по умолчанию четырьмя против пяти, которые они предлагают. Каждый уровень продавал длину, которую его же собственный лимит не пропускал.

Потолки теперь такие: 600 МБ для Professional, 200 МБ для Starter и 100 МБ для бесплатных настроек по умолчанию, и этого хватает на обещанную каждым длину с запасом. Вторая половина дела, то есть запись в панели ровно на ту длину, которую продаёт её тариф, а не десять минут для всех подряд, приехала на следующий день в расширении 1.5.0, так что запись на Professional теперь доходит до тридцати минут с обоих концов.

Библиотека интеграции говорит, кто наткнулся на ошибку

Версия 0.3.1 библиотеки опубликована и раздаётся с наших собственных страниц. В ней появился identify(), контекстный API только на запись: ваша страница сообщает нам, кто смотрел и на что смотрел, а сделанный после этого отчёт несёт это с собой.

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

Пять ключей и никаких других - email, plan, orderId, release, requestId. Повторные вызовы сливаются, так что одностраничное приложение может дополнять по мере того, как узнаёт больше, вместо того чтобы повторять всё целиком; ключ, переданный как null, убирается, а это ровно то, что нужно при выходе из аккаунта.

Библиотека никогда сама ничего из этого не ищет. Из вашего DOM она не читает ничего: не выскребает адрес почты из шапки, не угадывает тариф по значку. Она держит то, что вы ей передали, и отдаёт это только тогда, когда расширение спросит. Страница, которая ни разу не вызвала identify(), не сообщает вообще ничего, а сам вызов никогда не запускает запись.

Тот же выпуск переписал то, что видит посетитель на Safari или Firefox, когда нажимает кнопку. Раньше там говорилось, что браузер не может запустить расширение, давалась ссылка на страницу, и на этом всё. Этот читатель у библиотеки самый неосведомлённый и при этом тот, от кого просят больше всех, и его просили пойти и найти другой браузер, не дав ни одного довода. Теперь он получает то, что нёс бы отчёт, что это ничего не стоит, и куда пойти читать дальше, причём всё это давно написано и давно переведено, а держала его проверка состояния.

Более мелкое, из той же недели

• API отвечает на том языке, о котором просит вызывающая сторона.
• Шрифты раздаются с наших собственных машин. Три CDN веб-шрифтов ушли.
• Sitemap больше не датирует каждую страницу тем, когда в последний раз прошла ночная задача.
• Страница возможностей утверждала, что MCP-сервера у нас нет, и это было правдой, когда её писали.