Birdie

Grab console logs from a specific Birdie recording. Returned events include: - absolute timestamps (`timestamp_ms`) - recording-relative timing (`recording_time_ms`, `recording_timecode`) Supported filters: - log_level: error, warning, info, log, debug - limit: cap the number of returned results

get_console_logs

Read structured metadata and context for a specific Birdie recording. This includes: - core recording information such as date, duration, direction, and origin - people context such as who recorded it and who requested it - browser and device details - page and location context when available - custom metadata payloads and compatible legacy metadata when present Use this tool when the user wants general structured context about a recording. Do NOT use this tool for transcript text, console logs, network requests, or user-step analysis.

get_metadata

List network requests from a specific Birdie recording as JSON. Returned events include: - absolute timestamps (`timestamp_ms`) - recording-relative timing (`recording_time_ms`, `recording_timecode`) Supported filters: - status_code: 500 or "5xx" - content_type: for example application/json - host: for example api.example.com - limit Pass at_ms (a recording_time_ms value from a previous call) to inspect the request(s) at that moment in full detail: request/response headers, request payload, and response body (truncated), exactly as the recording stored them. Without an exact match the nearest request is returned and `hint` says how far away it was.

get_network_requests

Inspect a specific Birdie recording and return a normalized evidence bundle. Use this tool only when the user provides a single recording identifier directly. The identifier can be: - numeric id (e.g. 631060) - uuid - short public code (e.g. w2uqNMG) - or a full url whose last part is the identifier, uuid or short code This tool returns: - recording context - browser and environment details - transcript text when available - user steps - console events - network events - network summary - cookies (only for recordings that captured them — see below) Returned events include: - absolute timestamps (`timestamp_ms`) - recording-relative timing (`recording_time_ms`, `recording_timecode`) Cookies: a `cookies` field MAY be present depending on the recording. When the recording captured cookies it contains a timeline of the initial cookie snapshot (`change: "initial"` with a `cookies` array) plus per-cookie `set`/`changed`/`removed` events. It is OMITTED entirely for recordings that did not capture cookies (older recordings and Chrome extension recordings), so do not assume it is always present. Only own-domain, non-HttpOnly cookies are captured, and secret-looking values are masked. Use this tool when the AI should review all recording signals together and decide what is meaningful. Do NOT use this tool for searching, browsing, or listing multiple recordings.

get_recording_diagnostics

Extract a few still frames (screenshots) from a recording so you can SEE what was on screen. Returns interleaved content: a short text summary, then for each moment a text label ("t=00:08.000") followed by the frame image. Use this when structured signals are not enough or absent — a recording with no console/network/user-event logs, or a visual question such as "what did the error screen look like?" or "what page was the user on at 01:20?". How to drive it: 1. Prefer calling get_recording_scenes first to see where the screen changes. 2. Then call this with a time_range around the interesting window — you get frames sampled from that window. Without a time_range, it samples across the whole recording (a coarse overview). 3. Narrow the time_range and call again for a denser, sharper look. Parameters: time_range {from, to} in seconds; max_frames (default 8, max 12); min_width in pixels (default 1280). Keep max_frames small — each frame is an image and costs vision tokens. Do NOT use this for text signals — prefer get_console_logs / get_network_requests / get_repro_steps / get_recording_diagnostics when the answer is in the logs.

get_recording_frames

Read the precomputed VISUAL scene map of a recording: where on the timeline the screen changes, and which stretches are static. This is a cheap, text-only index you read FIRST to decide which moments are worth looking at — it contains no images. Returns: - duration_seconds, width, height - scenes: a list of {t, score} where t is seconds from the start and score is the magnitude of the on-screen change at that moment (higher = bigger change, e.g. a navigation or a modal opening; low = minor movement). Scores are relative WITHIN a recording — a low-motion screencast peaks lower than a page full of navigation. - quiet_spans: {from, to} intervals that are near-static (nothing is happening — usually safe to skip). Typical flow: 1. Call get_recording_scenes to see the shape of the recording. 2. Pick the interesting window(s) from the scenes / quiet_spans. 3. Call get_recording_frames with a time_range to actually SEE those moments. Use this for questions like "when does the screen change?", "is anything happening after 01:00?", or as the first step before extracting frames. It does NOT return transcript, logs, or network data — use the dedicated tools for those.

get_recording_scenes

Read the steps a user took in a Birdie recording — clicks, typing, selections and navigations, in order, in plain language — as reproduction steps. Each step carries absolute timestamps (`timestamp_ms`), recording-relative timing (`recording_time_ms`, `recording_timecode`, `delay_from_previous_ms`) and, where the recorder captured it, the identity a replay needs: the control that was acted on, its accessible name, a CSS selector with a confidence rating, a role+name locator, and the state it was in before and after. Two depths, chosen with `detail`: - `steps` (default) — the ordered steps alone. Use it to answer "what did they do?". - `full` — the same steps plus `preconditions` (starting url, viewport, browser) and `failure_signature`: the console errors and failed requests the session produced, each tied to the step it followed. Use it to answer "how do I reproduce this?" or when investigating a reported bug. `failure_signature` is absent when the session produced no errors.

get_repro_steps

DEPRECATED alias of `get_repro_steps`, kept only so clients installed under the old name keep working. Do not choose this tool: call `get_repro_steps` instead, which is identical and additionally accepts `detail: full` for reproduction context.

get_user_events

Get the spoken transcript from a specific Birdie recording. When timestamped captions are available, this tool returns WebVTT. Otherwise it returns the plain transcript text and clearly reports that WebVTT was not available.

get_video_transcript

List Birdie recordings. Use this tool when the user does NOT already know the exact recording identifier. Typical use cases: - find recordings by text, title, tag name, tag slug, or metadata - search by ticket id using the "ticket" parameter - search recordings from a specific email (user, requester, or contact) - narrow results by folder - narrow results by recording date - browse multiple recordings IMPORTANT: - If filtering by email, folder, date, or ticket only, DO NOT provide a query. - Do NOT use generic words like "video", "recording", "latest", or "*". - Only provide "query" when you have meaningful search text (e.g. error message, keyword, feature name, tag name, or tag slug). Examples: - GOOD: { "from_email": "john@company.com" } - GOOD: { "query": "checkout error" } - GOOD: { "query": "freshchat" } - GOOD: { "ticket": "12345" } - GOOD: { "ticket": "12345", "folder": "Customer Escalations" } - GOOD: { "query": "checkout error", "date": "2026-03-24" } - BAD: { "query": "video", "from_email": "john@company.com" } Query matching: - The "query" field can match recording title, uuid, metadata, tag name, and tag slug. - Tag matching is performed on both the human-readable tag name and the normalized tag slug. Ticket search: - If the user provides a ticket id, use the "ticket" field. - Do NOT prefix ticket ids with "#". - Example: user says "ticket 12345" → use { "ticket": "12345" } Folder search: - If the user mentions a folder, use the "folder" field. - Folder is normalized and matched against the folder slug. Date search: - Use the "date" field to narrow by recording date. - Accepted formats include: - YYYY-MM-DD - YYYY-MM-DD HH - YYYY-MM-DD HH:MM - ISO datetime strings Do NOT use this tool if the user provides a specific recording identifier (id, uuid, or shortlink like w2uqMNG). In that case, use get_recording_diagnostics instead.

list_recordings