Un server MCP, l'avanzamento fotogramma per fotogramma e limiti all'altezza del piano

Il 22 agosto 2026 sono arrivate cinque cose, e la più grande è che ora un agente può leggere direttamente le tue segnalazioni di bug.

Il tuo agente può leggere la coda

Session Replay parla il Model Context Protocol. C’è un solo endpoint, POST /mcp, e niente da installare: all’agente si dà l’indirizzo e lo si autorizza una volta, come lo si punterebbe verso qualunque altro server con cui lavora.

Dietro ci sono cinque strumenti. Quattro leggono e uno scrive:

• list_domains non prende nulla e risponde con ogni dominio rivendicato dall’account, il team che lo detiene e se è stato verificato. È da lì che parte chi legge, perché tutto quello che viene dopo è indicizzato per dominio.
• list_reports prende un dominio e, facoltativamente, un termine di ricerca, uno stato, un intervallo di date e una pagina. Risponde dal più recente.
• get_report prende il token di condivisione di una segnalazione e risponde con la segnalazione intera.
• get_frame prende un token e uno scostamento in millisecondi, e risponde con un fermo immagine della registrazione, come immagine che l’agente può davvero guardare.
• set_status prende un token e uno stato, e fa avanzare la segnalazione nel triage. Quello che scrive arriva alla persona che ha inviato la segnalazione.

La ricerca dietro list_reports ora copre anche il commento di chi segnala, oltre all’URL e al titolo della pagina, ed è la differenza fra trovare la segnalazione sul captcha e sentirsi dire che non ce n’è nessuna. Il tutto ora poggia su un indice invece di leggere la tabella.

L’autorizzazione è OAuth 2.1 con PKCE, e il token ha bisogno dell’ambito mcp:read. La superficie è solo Professional, e un team su un piano inferiore viene rifiutato prima che venga letto un qualsiasi messaggio, con il rifiuto che nomina il piano su cui il team si trova davvero e dove cambiarlo. Quest’ultima parte conta più di quanto sembri: un agente può riferire solo quello che gli è stato consegnato, e un rifiuto generico diventa “non hai nessun bug” quando arriva a una persona.

Nella dashboard c’è una pagina dedicata, accanto a Integrazione, che dà l’indirizzo, cosa serve per autorizzare, quali dei tuoi domini sono verificati e tre messaggi svolti nell’ordine in cui un agente li invierebbe. È visibile su ogni piano. Solo l’indirizzo è attenuato al di sotto di Professional.

Due cose che di proposito non fa. Non esiste ancora un ambito mcp:write, quindi set_status scrive con lo stesso ambito di lettura che usa tutto il resto; separare i due comincia da una schermata di consenso capace di spiegare la differenza, ed è un lavoro a sé. E niente su questa superficie cancella qualcosa, sposta una segnalazione da un team a un altro o tocca la fatturazione.

Avanzamento fotogramma per fotogramma e velocità di riproduzione

Trovare l’unico fotogramma in cui il layout si è rotto voleva dire trascinare, andare oltre e tornare indietro trascinando. La pagina di condivisione portava i controlli del browser e nient’altro, e l’impostazione della velocità che Chrome tiene in un menu di overflow è sepolta dove non manca del tutto.

Ora sotto il video c’è una fascia sottile con i due controlli che il browser non ti dà: cinque velocità di riproduzione - 0.25×, 0.5×, 1×, 1.5× e 2× - e un passo indietro e uno avanti. , e . avanzano di un fotogramma, < e > scorrono le velocità. Il set di controlli del browser resta intatto lì sotto, perché sostituirlo vorrebbe dire riguadagnarsi il supporto da tastiera, la gestione del focus e lo schermo intero su una pagina che è pubblica e a cui arrivano persone che non si sono mai iscritte a niente.

L’avanzamento è onesto su ciò che sa fare. Queste registrazioni vengono dal registratore del browser stesso, quindi hanno frequenza di fotogrammi variabile e non dichiarano alcuna frequenza, e non esiste un numero corretto di fotogrammi al secondo da aggiungere. Dove il browser dice quale fotogramma sta presentando, un passo cade su un fotogramma reale. Dove non lo dice, oggi Firefox, un passo vale nominalmente un trentesimo di secondo, e i pulsanti lo scrivono sulla propria faccia invece di rivendicare una precisione che non hanno.

I pannelli console, rete e interazioni seguono un passo come seguono uno spostamento, così la riga che appartiene al nuovo fotogramma viene evidenziata senza fare altro.

La conservazione risponde in base al piano su cui sei

La finestra di conservazione di un dominio veniva fissata quando il dominio veniva rivendicato e poi non si spostava più. Un team che passava a un piano superiore continuava a ricevere la finestra venduta dal suo vecchio piano, e su segnalazioni inviate dopo il passaggio, non solo su quelle che lo precedevano.

La conservazione ora viene chiesta al piano nel momento in cui una segnalazione viene inviata, e un passaggio a un piano superiore porta le segnalazioni già inviate alla nuova finestra prendendo la più tarda delle due date. Un passaggio a un piano inferiore non sposta nulla, e una conservazione più lunga impostata su un dominio non viene mai accorciata da un cambio di piano. Un dominio impostato per tenere le sue segnalazioni per sempre le tiene per sempre.

I tetti ora corrispondono a quello che ogni piano vende

Questo è stato un errore nostro, e vale la pena scriverlo invece di seppellirlo.

Professional pubblicizza trenta minuti di registrazione e Starter dieci. Il numero di byte che ogni livello avrebbe davvero accettato era stato fissato separatamente dal numero di minuti che offre, e nessuno aveva messo le due cifre una accanto all’altra. Una cattura gira a circa 18,7 MB al minuto, quindi il tetto di 250 MB di Professional erano tredici minuti, i 100 MB di Starter erano nove, e i 50 MB delle impostazioni gratuite predefinite erano quattro contro i cinque che offrono. Ogni livello vendeva una durata che il suo stesso limite rifiutava.

I tetti ora sono 600 MB per Professional, 200 MB per Starter e 100 MB per le impostazioni gratuite predefinite, il che copre con margine la durata che ciascuno pubblicizza. L’altra metà della faccenda, il pannello che registra per la durata che il suo piano vende invece di dieci minuti fissi per tutti, è arrivata il giorno dopo nell’estensione 1.5.0, così una cattura Professional ora arriva a trenta minuti da entrambi i capi.

La libreria di integrazione dice chi ha incontrato il bug

La versione 0.3.1 della libreria è pubblicata e servita dalle nostre pagine. Porta con sé identify(), una API di contesto a senso unico: la tua pagina ci dice chi stava guardando e cosa stava guardando, e una segnalazione fatta dopo se lo porta dietro.

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

Cinque chiavi e nessun’altra - email, plan, orderId, release, requestId. Le chiamate ripetute si fondono, così un’applicazione a pagina singola può aggiungere man mano che impara di più invece di ripetere tutto; una chiave passata come null viene tolta, che è quello che serve a una disconnessione.

La libreria non va mai a cercarsi niente di tutto questo. Non legge nulla dal tuo DOM: nessuna raccolta di un indirizzo email da un’intestazione, nessun piano indovinato da un badge. Tiene quello che le hai passato e lo consegna solo quando l’estensione lo chiede. Una pagina che non chiama mai identify() non dice proprio niente, e chiamarlo non avvia mai una registrazione.

La stessa release ha riscritto quello che vede un visitatore su Safari o Firefox quando preme il pulsante. Prima diceva che il browser non poteva eseguire l’estensione, offriva il link alla pagina e finiva lì. Quel lettore è il pubblico meno informato e più sollecitato che questa libreria abbia, e gli si chiedeva di andare a cercare un altro browser sulla base di niente. Ora riceve che cosa conterrebbe la segnalazione, che non costa nulla, e dove leggere di più: tutta roba già scritta e già tradotta, e trattenuta da un controllo di stato.

Cose più piccole della stessa settimana

• L’API risponde nella lingua che chiede chi chiama.
• I caratteri sono serviti dalle nostre macchine. Le tre CDN di webfont non ci sono più.
• La sitemap non data più ogni pagina in base all’ultima esecuzione del job notturno.
• La pagina delle funzionalità negava che avessimo un server MCP, il che era vero quando è stata scritta.