Anry

List sessions

list_sessions

Read-onlyIdempotent

Screen recordings (session replays) for a site over a date window (max 31 days), newest first. Every session listed has a recording, and its replay_url opens it in the player: use this tool whenever the user asks for replays or recordings to watch. Each row carries the entry page, duration, landing utm tags and source. Filter by entry_pathname (where the session started), pathname (a page visited at any point), min_duration_seconds, source (the name get_traffic_sources returns), utm tag, or campaign_id / ad_id (the ids get_campaign_spend returns) to see the sessions an ad brought. Meta ads: source is the app the visitor clicked in (Facebook, Instagram or Threads), while utm_source keeps what the ad URL carried, often facebook for every placement, so filter on source=Instagram for an Instagram placement; sessions recorded before this attribution existed show every Meta placement as Facebook. Paginate with the returned next_cursor (pass cursor and cursor_id back verbatim) to collect every match. Each session_id opens with get_session (the page journey), get_session_replay (what the visitor did, as facts) and, where available, get_session_frames (what the pages looked like).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_id": "<site_id>"
    },
    "name": "list_sessions"
  }
}

Input Schema

Name	Required	Description
`ad_id`	No	Only sessions whose landing URL carried this ad id (an ad_id from get_campaign_spend with grain=ad)
`limit`	No	Max rows to return (default 20)
`cursor`	No	next_cursor.cursor from the previous page
`source`	No	Only sessions from this traffic source, as get_traffic_sources names it (e.g. Instagram, Facebook, Threads, Google); direct traffic has no source to filter on
`site_id`	Yes	Site id from list_sites (UUID)
`end_date`	No	ISO date (YYYY-MM-DD). Defaults to today.
`pathname`	No	Only sessions that visited this pathname at any point, e.g. /checkout (use entry_pathname for the page a session started on)
`referrer`	No	Only sessions with exactly this referrer URL
`cursor_id`	No	next_cursor.cursor_id from the previous page
`start_date`	No	ISO date (YYYY-MM-DD). Defaults to 30 days before end_date.
`utm_medium`	No	Only visits whose landing URL carried this utm_medium value (exact match)
`utm_source`	No	Only visits whose landing URL carried this utm_source value (exact match)
`campaign_id`	No	Only sessions whose landing URL carried this campaign id (a campaign_id from get_campaign_spend)
`utm_campaign`	No	Only visits whose landing URL carried this utm_campaign value (exact match)
`entry_pathname`	No	Only sessions that started on this pathname (their entry_pathname), e.g. / or /products/blue-shirt
`min_duration_seconds`	No	Only sessions that lasted at least this many seconds (their duration_seconds, first to last recorded event)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 29, 2026

addedInput schema / properties / entry_pathname

Added value: +{
+  "description": "Only sessions that started on this pathname (their entry_pathname), e.g. / or /products/blue-shirt",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / min_duration_seconds

Added value: +{
+  "description": "Only sessions that lasted at least this many seconds (their duration_seconds, first to last recorded event)",
+  "maximum": 86400,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / pathname / description

Previous value: -"Only sessions that visited this pathname, e.g. /checkout"New value: +"Only sessions that visited this pathname at any point, e.g. /checkout (use entry_pathname for the page a session started on)"

changedInput schema / properties / source / description

Previous value: -"Only sessions from this traffic source, as get_traffic_sources names it (e.g. Instagram, Google); direct traffic has no source to filter on"New value: +"Only sessions from this traffic source, as get_traffic_sources names it (e.g. Instagram, Facebook, Threads, Google); direct traffic has no source to filter on"

First observedOct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavior on top: the 31-day cap, newest-first ordering, the invariant that listed sessions always have a replay, pagination via next_cursor/cursor_id returned verbatim, and the Meta-ads attribution caveat including how pre-attribution sessions are labeled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the primary use case, then filters, then pagination, then follow-on tools — a sensible order. It is dense, with long multi-clause sentences (particularly the Meta ads explanation) that could be split, but every clause carries information an agent would otherwise have to guess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter read tool with no output schema, the description covers return fields (entry page, duration, landing utm tags, source, replay_url, next_cursor), pagination mechanics, defaults, and the sibling hand-offs. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description earns more by resolving the ambiguity the schema leaves: source is the app the visitor clicked in while utm_source is what the ad URL carried, and campaign_id/ad_id tie back to get_campaign_spend output. It also clarifies entry_pathname vs pathname in behavioral terms.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Screen recordings (session replays) for a site over a date window') and pins the scope with 'newest first', a max 31-day window, and the guarantee that every row has a recording. An agent can distinguish it from get_session, get_session_replay and list_notable_sessions without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit routing rule ('use this tool whenever the user asks for replays or recordings to watch') and names the follow-on siblings (get_session, get_session_replay, get_session_frames) per session_id. It also states which filter to use for each intent (entry_pathname vs pathname, source vs utm tag, campaign_id/ad_id for ad-driven sessions).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Anry tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?