Skip to main content
Glama
Sign In

Anry

by io.anry.mcp
OverviewDiscussionsAdmin

List notable sessions

list_notable_sessions
Read-onlyIdempotent

Which sessions of a window are worth opening, and how often each behaviour occurred across all of them. Anry reads every recording once and ranks; you write the story. Returns a summary (per behaviour: sessions, share, device split, top pages, the previous window of the same length) and four groups: friction (repeated clicks, a field left empty, browser translation, a long idle or a quiet exit on a key page, a long hover on a button or short link, back-and-forth between two pages, dead-end exploration), abandon (reached cart, checkout or the goal page without converting), paid (paid traffic that left within seconds or never scrolled) and converter (for contrast). Each session carries the reasons it was picked, with offsets in seconds for get_session_replay and get_session_frames, and whether its frames are already drawn. Defaults to the site's previous day; start here before opening recordings one by one.

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_notable_sessions"
  }
}

Input Schema

NameRequiredDescriptionDefault
groupNoOnly this group
limitNoSessions listed per group (default 5)
site_idYesSite id from list_sites (UUID)
end_dateNoISO date in the site's timezone. Defaults to yesterday. At most 31 days.
pathnameNoOnly sessions that viewed this page (exact pathname)
start_dateNoISO date in the site's timezone. Defaults to end_date (one day).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already establish that this is a safe, idempotent read. The description adds rich behavioural context: it returns a summary with per-behaviour sessions, share, device split, top pages and previous-window comparison, plus four ranked groups and per-session selection reasons with offsets and frame-drawn status.

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?

The description is front-loaded around the question of which sessions to open and is dense with relevant detail. It is somewhat lengthy and lists many criteria in a single flowing explanation, but nearly every clause adds useful selection or output information.

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?

Given six parameters, no output schema, and read-only annotations, the description does an unusually complete job of explaining the return shape, ranking logic, groups, session reasons, offsets, frame status and default time window. An agent has enough context to decide when to call it and how to interpret the result.

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

Parameters4/5

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

Schema coverage is 100%, so parameter documentation is already strong. The description still adds meaning by explaining what the four group values represent and why those groups are selected, which goes beyond the enum names alone.

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

Purpose4/5

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

The description clearly states that this tool ranks notable sessions and summarizes behaviour frequencies, with four named groups and default time range. It distinguishes itself from recording-by-recording tools by saying to start here before opening recordings, though it does not explicitly contrast with the sibling list_sessions.

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

Usage Guidelines4/5

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

It gives a clear starting-point recommendation ('start here before opening recordings one by one') and states the default window. It lacks explicit exclusions or direct comparisons with alternatives such as list_sessions or analytics overview tools.

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

All Anry toolsInspect
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