LogRocket

Use this to query LogRocket analytics data. This tool translates your natural language query into a LogRocket metric (e.g., timeseries, table, conversion funnel) that is then used to find relevant data. It's best used for performing aggregate analysis (e.g., session totals over time, browser or country breakdowns, conversion rates between steps). Returns an object with a `metricDefinition` field indicating the LogRocket metric that was used to find the data and a `metricQueryResult` field containing the corresponding analytics data. The result may also contain a `sessionDefinitions` field listing a sample of relevant sessions. Queries can reference the project's saved user segments and definitions by name. Example queries include: - "How many sessions in the last 24 hours?" - "Session count by browser over the last 30 days" - "Conversion rate from landing page to checkout in the last 7 days" - "Timeseries of sessions where users clicked "Start free trial" and then saw an error in the last week" - "Top countries by session count in the last 30 days" - "Sessions from my Enterprise Users segment that reached checkout in the last 7 days"

build_metric

Use this to list a LogRocket project's issues. This includes error signals detected in session recordings, specifically JavaScript exceptions, network errors, rage clicks, dead clicks, frustrating network requests, error states, and mobile crash reports. Issues can be filtered by severity, triage status, issue type, and time range, and optionally refined with a natural language query. Returns an object with an `issues` field listing matching issues, each with its issue type, platform, event count (an approximation of the number of affected sessions), first/last seen dates, `triageStatus` ("untriaged", "highImpact", "lowImpact", or "ignored"), a `url` linking to the issue's detail page in the LogRocket dashboard, and an AI-generated `issueDescription` when one exists. If a LogRocket AI issue analysis already exists for an issue, it is attached inline in the issue's `issueAnalysis` field with the analysis' summary, severity verdict, user impact, reproduction steps, and suggested next steps. Example uses: - "List the severe untriaged issues from the last week" - "Show high impact network errors this month" - "Any checkout-related exceptions in the last 24 hours?"

find_issues

Use this to find LogRocket sessions matching a natural language query. This tool translates your natural language query into LogRocket filters that are then used to find relevant sessions. It's best used for filtering sessions based on user ID or email, custom user traits, visited page or URL, custom events, text inputs, clicked on text or CSS selector, network errors, IP address, user location (e.g., country), and/or other basic metadata, in addition to over a specific date range (e.g., last week). Returns an object with a list of relevant sessions in the `sessionDefinitions` field, each with recording ID, session ID, session URL, date of recording as a Unix timestamp in milliseconds, and other basic metadata. The returned object will also include a `metricDefinition` field indicating which LogRocket filters were used to find the sessions. Example queries include: - "Sessions where user email ends with @example.com in the last 7 days" - "Sessions where users visited /checkout and clicked "Place order" in the last 24 hours" - "Sessions from Chrome on Windows in the last 14 days" - "Sessions from users in Germany who hit a network error on /api/payment this week" - "Sessions where users submitted the signup form but did not reach /welcome in the last 3 days" - "Sessions for user ID abc123 that include rage clicks on pricing pages this month"

find_sessions

Use this to fetch the data for an existing, saved LogRocket metric (timeseries, funnel, table, retention, or session count) over a specific time range. Unlike build_metric, this runs the saved metric's own definition rather than generating one from a natural language query, so results are deterministic. Prefer this tool whenever the user provides a link to a saved metric. Heatmap and path analysis metrics are not supported. Returns an object with: - `metricDefinition`: the saved metric's configuration (name, type, filters, grouping, time interval, and, for funnels, the ordered steps in `funnel.steps`), with its time range replaced by the requested one. - `metricQueryResult`: the metric's data. Timeseries return `buckets` keyed by time bucket (and `fullRangeValues` or `fullRangeUniqueUsers` when values can't be summed across buckets). Funnels return `sessionCountTotal` and `funnelStepSessionCounts`, one count per step in `funnel.steps` order (users rather than sessions for cross-session funnels), or `groupedFunnelStepSessionCounts` when the funnel is grouped. Tables return ranked `buckets` with `totalBucketCount`. Retention returns `buckets` per retention interval. Session metrics return `sessionCountTotal`. - `sessionDefinitions`: when `sessionLimit` is set, a sample of sessions behind the metric, each with a `sessionURL` linking to its replay. For timeseries and session count metrics these are sessions matching the metric's filters; for funnels they are sessions in the cohort selected by `funnelStep` and `funnelSessions`. Always null for table and retention metrics, and when `sessionLimit` is omitted.

get_metric

Use this to retrieve raw network request and response pairs recorded during a single LogRocket session, identified by its recording ID and session ID, as a HAR 1.2 document. Prefer this tool over watch_sessions when you only need network data. To gather network data across many sessions (e.g., all sessions that called a given endpoint over a date range), first locate sessions with find_sessions, then call this tool for each session. The response is an object with `total` (the number of entries matching your filters), `offset`, `limit`, and `har`. Entries are sorted by request start time and paginated: if `offset + limit < total`, call the tool again with a higher offset to fetch the next page. The `har` value is a HAR document that can be written directly to a .har file; its `log.entries` contain the request method, URL, query string, headers, and body, and the response status, headers, and body. Multi-tab sessions are merged into one log: `log.pages` has one entry per browser tab and each entry's `pageref` identifies its tab. Large bodies and header values may be truncated (denoted by "[TRUNCATED]"), cookies and timing breakdowns are not collected by the LogRocket SDK, and headers and bodies are omitted entirely if the caller lacks the required permissions - none of this indicates a problem with the recorded application.

get_network_entries

List organizations the user has access to. Returns organization IDs and their human-readable names.

list_organizations

List projects the user has access to. Returns project IDs and their human-readable names.

list_projects

Run a natural language query against LogRocket. Use this to query sessions, metrics, issues, or other app data unless dedicated tools that would be a better fit are available. If the user references a specific session by providing a session URL, include the full URL in your query, not just part of it. Optionally pass a chatID to continue an existing conversation. Queries may take as long as 10 minutes to complete. If the result you get back has status: completed, the query is done. If the result you get back has status: thinking, the query is still running in the background. In this case, any messages in the result are meant to convey progress and should be shared with the user so they know work is still being done. You should then continue calling this tool with the chatID from the result and pollForResult: true until the query completes. Completed results may include links to specific sessions, metrics, issues, or other app data. These act as citations. Include them in your reply so the user can trace any claim back to the underlying LogRocket data.

use_logrocket

Use this to analyze one or more LogRocket sessions, each identified by its recording ID and session ID. You can use this tool to understand user behavior in the session or to extract additional information about the session (e.g., metadata, console logs, network requests and responses). Provide a separate natural language query describing what you want to know for each session to be analyzed. Sessions are analyzed in parallel, independently of each other. The tool returns an object with two properties, pendingResults and completedResults. The contents of pendingResults indicate which of your session watching requests are still running in the background, if any. Session watching can take several minutes to complete. When session watching requests are submitted - each combo of query, recordingID, and sessionID is treated as separate request - the requests are each assigned a unique fingerprint identifying the request. If there are entries in pendingResults, continue calling this tool with pollForResults: true and any pending fingerprints until all requests are complete. The contents of completedResults indicate which of your session watching requests have completed. Each object in completedResults will contain an `ok` field indicating whether the request succeeded or failed. Objects for successful requests will also contain a `content` field with the response to your query about the session and a `keyFrames` field citing specific frames from the session that ground the response. Cite relevant key frames in your own response to the user to provide evidence for your statements. You can choose to link to provided screenshots, fetch and display screenshot image content inline, and/or use the `videoTime` field to construct links to specific moments in the corresponding session (LogRocket session URLs have the structure `https://app.logrocket.com/<organizationID>/<projectID>/s/<recordingID>/<sessionID>?t=<videoTime>`; the `t` param is where you put the video time value you want to jump to).

watch_sessions