get_console_logs
ChatGPTGrab 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_metadata
ChatGPTRead 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_network_requests
ChatGPTList 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
get_recording_diagnostics
ChatGPTInspect 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 Returned events include: - absolute timestamps (timestamp_ms) - recording-relative timing (recording_time_ms, recording_timecode) 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_frames
ChatGPTExtract 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_scenes
ChatGPTRead 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_repro_steps
ChatGPTRead 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_user_events
ChatGPTRead clicks, inputs, and page navigation changes from a specific Birdie recording in plain language. Returned events include: - absolute timestamps (timestamp_ms) - recording-relative timing (recording_time_ms, recording_timecode)
get_video_transcript
ChatGPTGet 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.
list_recordings
ChatGPTList 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.
