Um servidor MCP, avanço fotograma a fotograma e limites que correspondem ao plano

A 22 de agosto de 2026 chegaram cinco coisas, e a maior delas é que um agente já consegue ler diretamente os seus relatórios de bugs.

O seu agente consegue ler a fila

O Session Replay fala o Model Context Protocol. Há um único endpoint, POST /mcp, e nada para instalar: dá-se o endereço ao agente e autoriza-se uma vez, tal como se o apontaria a qualquer outro servidor com que trabalhe.

Por trás estão cinco ferramentas. Quatro leem e uma escreve:

• list_domains não recebe nada e responde com todos os domínios que a conta reivindicou, a equipa que os detém e se estão verificados. É por aí que começa quem lê, porque tudo o que vem a seguir é indexado por domínio.
• list_reports recebe um domínio e, opcionalmente, um termo de pesquisa, um estado, um intervalo de datas e uma página. Responde do mais recente para o mais antigo.
• get_report recebe o token de partilha de um relatório e responde com o relatório inteiro.
• get_frame recebe um token e um deslocamento em milissegundos, e responde com uma imagem fixa da gravação, como imagem que o agente consegue mesmo olhar.
• set_status recebe um token e um estado, e move o relatório pela triagem. O que escreve chega à pessoa que submeteu o relatório.

A pesquisa por trás de list_reports cobre agora também o comentário de quem reportou, além do URL e do título da página, que é a diferença entre encontrar o relatório sobre um captcha e ouvir dizer que não há nenhum. Tudo isto assenta agora num índice em vez de ler a tabela.

A autorização é OAuth 2.1 com PKCE, e o token precisa do âmbito mcp:read. Esta superfície é só para Professional, e uma equipa abaixo desse plano é recusada antes de qualquer mensagem ser lida, com a recusa a nomear o plano em que a equipa está de facto e onde o mudar. Essa última parte conta mais do que parece: um agente só pode transmitir o que lhe foi entregue, e uma recusa genérica transforma-se em “não tem nenhum erro” quando chega a uma pessoa.

Há uma página para isto no painel, ao lado de Integração, com o endereço, o que a autorização exige, quais dos seus domínios estão verificados e três mensagens trabalhadas pela ordem em que um agente as enviaria. É visível em todos os planos. Só o endereço aparece esbatido abaixo do Professional.

Duas coisas que ela deliberadamente não faz. Ainda não existe um âmbito mcp:write, por isso o set_status escreve com o mesmo âmbito de leitura que tudo o resto usa; separar os dois começa por um ecrã de consentimento capaz de explicar a diferença, e isso é um trabalho por si só. E nada nesta superfície apaga o que quer que seja, muda um relatório de equipa ou mexe na faturação.

Avanço fotograma a fotograma e velocidade de reprodução

Encontrar o único fotograma em que o layout se partiu era arrastar, passar ao lado e arrastar de volta. A página de partilha trazia os controlos do próprio navegador e mais nada, e a definição de velocidade que o Chrome guarda num menu de overflow está enterrada onde não falta de todo.

Há agora uma faixa estreita por baixo do vídeo com os dois controlos que o navegador não lhe dá: cinco velocidades de reprodução - 0.25×, 0.5×, 1×, 1.5× e 2× - e um passo para trás e um para a frente. , e . avançam um fotograma, < e > percorrem as velocidades. O conjunto de controlos do próprio navegador fica intacto por baixo, porque substituí-lo significaria voltar a ganhar o suporte de teclado, o tratamento do foco e o ecrã inteiro numa página que é pública e à qual chegam pessoas que nunca se inscreveram em nada.

O avanço é honesto quanto ao que consegue fazer. Estas gravações vêm do gravador do próprio navegador, por isso têm taxa de fotogramas variável e não declaram taxa nenhuma, e não há um número correto de fotogramas por segundo a acrescentar. Onde o navegador diz que fotograma está a apresentar, um passo cai num fotograma real. Onde não diz, hoje o Firefox, um passo vale nominalmente um trigésimo de segundo, e os botões dizem-no na sua própria face em vez de reclamarem uma precisão que não têm.

Os painéis de consola, rede e interações seguem um passo tal como seguem um salto, por isso a linha que pertence ao novo fotograma fica marcada sem que seja preciso fazer mais nada.

A retenção responde a partir do plano em que está

A janela de retenção de um domínio era fixada quando o domínio era reivindicado e depois nunca mais se mexia. Uma equipa que subia de plano continuava a receber a janela que o plano antigo vendia, e isso em relatórios submetidos depois da subida, não apenas nos que a antecediam.

A retenção é agora perguntada ao plano no momento em que um relatório é submetido, e uma subida de plano traz os relatórios já submetidos para a nova janela, ficando com a mais tardia das duas datas. Uma descida de plano não mexe em nada, e uma retenção mais longa definida num domínio nunca é encurtada por uma mudança de plano. Um domínio configurado para guardar os relatórios para sempre guarda-os para sempre.

Os tetos passaram a corresponder ao que cada plano vende

Este foi um erro nosso, e vale mais escrevê-lo do que enterrá-lo.

O Professional anuncia trinta minutos de gravação e o Starter dez. O número de bytes que cada escalão aceitava de facto tinha sido definido em separado do número de minutos que oferece, e ninguém tinha posto os dois valores lado a lado. Uma captura corre a cerca de 18,7 MB por minuto, por isso o teto de 250 MB do Professional dava treze minutos, os 100 MB do Starter davam nove, e os 50 MB das predefinições gratuitas davam quatro contra os cinco que oferecem. Todos os escalões vendiam uma duração que o seu próprio limite recusava.

Os tetos são agora 600 MB para o Professional, 200 MB para o Starter e 100 MB para as predefinições gratuitas, o que cobre com folga a duração que cada um anuncia. A outra metade disto, o painel a gravar durante o tempo que o seu plano vende em vez de dez minutos fixos para toda a gente, chegou no dia seguinte na extensão 1.5.0, por isso uma captura Professional vai agora até trinta minutos nas duas pontas.

A biblioteca de integração diz quem apanhou o erro

A versão 0.3.1 da biblioteca está publicada e é servida a partir das nossas próprias páginas. Traz identify(), uma API de contexto só de envio: a sua página diz-nos quem estava a ver e o que estava a ver, e um relatório feito depois leva isso consigo.

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

Cinco chaves e mais nenhuma - email, plan, orderId, release, requestId. Chamadas repetidas juntam-se, por isso uma aplicação de página única pode ir acrescentando à medida que vai sabendo mais em vez de repetir tudo; uma chave passada como null é descartada, que é o que uma saída de sessão quer.

A biblioteca nunca vai à procura de nada disto. Não lê nada do seu DOM: não raspa um cabeçalho à procura de um endereço de e-mail, não adivinha um plano a partir de um distintivo. Guarda o que lhe enviou e só o entrega quando a extensão pergunta. Uma página que nunca chama identify() não diz absolutamente nada, e chamá-lo nunca inicia uma gravação.

A mesma versão reescreveu o que um visitante em Safari ou Firefox vê quando carrega no botão. Antes dizia que o navegador não conseguia correr a extensão, oferecia o link da página e ficava-se por aí. Esse leitor é o público menos informado e a quem mais se pede de todos os que esta biblioteca tem, e pedia-se-lhe que fosse procurar outro navegador sem lhe dar razão nenhuma. Passa agora a receber o que o relatório levaria, que não custa nada, e onde ler mais, tudo isso já escrito e já traduzido, e retido por uma verificação de estado.

Coisas mais pequenas da mesma semana

• A API responde na língua que quem chama pedir.
• Os tipos de letra são servidos a partir das nossas máquinas. As três CDN de webfonts desapareceram.
• O sitemap já não data todas as páginas pela última vez que o trabalho noturno correu.
• A página de funcionalidades andava a negar que temos um servidor MCP, o que era verdade quando foi escrita.