Skip to main content
Glama
Sign In

Anry

by io.anry.mcp
OverviewDiscussionsAdmin

Get session replay facts

get_session_replay
Read-onlyIdempotent

The recording of one session (a session id from list_sessions or get_session) as facts, never as content: a timeline of pages, pointer dwell over elements, clicks with the element clicked, field focus and typed lengths, text selection, scroll depth and idle gaps, plus signals (repeated clicks, browser machine-translation of the page, a per-field form summary, long hovers on buttons and short links, back-and-forth between pages, how the session ended, and seconds, scroll depth and longest idle per page). Call it after get_session when the page journey alone does not explain the behaviour. Not available for reduced-mode sessions or before the recording is stored.

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>",
      "session_id": "<session_id>"
    },
    "name": "get_session_replay"
  }
}

Input Schema

NameRequiredDescriptionDefault
site_idYesSite id from list_sites (UUID)
session_idYesSession id from list_sessions or get_session

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioural facts: the output is facts rather than raw page content, and the tool fails for reduced-mode sessions and before recording storage. It does not discuss pagination, size limits, or latency on large recordings, so it stops short of a 5.

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?

It is front-loaded with the resource and the 'facts, never content' framing before the long enumeration, so the reader gets the point immediately. The parenthetical catalogue of signals is long but each item is substantive rather than filler; only the nested list of signals could be tightened.

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?

There is no output schema, so the description carries the full burden of describing what comes back, and it does so comprehensively: timeline elements, interaction types, derived signals, and per-page aggregates. Availability limits and the sibling dependency are also covered, leaving nothing an agent needs before calling it.

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

Parameters3/5

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

Schema description coverage is 100%, so both site_id and session_id are already documented, and the description's mention of 'a session id from list_sessions or get_session' largely restates the schema. It adds no format, provenance, or constraint detail for site_id. Baseline 3 applies when the schema carries the parameter burden.

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?

The description names a specific verb and resource ('get the recording of one session ... as facts') and enumerates exactly what facts are returned: page timeline, pointer dwell, clicks, field focus/typed lengths, scroll depth, idle gaps and derived signals. It also distinguishes the tool from get_session by framing itself as the detailed layer beneath the page journey, which the sibling list makes necessary.

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?

It gives an explicit trigger ('Call it after get_session when the page journey alone does not explain the behaviour') and explicit exclusions ('Not available for reduced-mode sessions or before the recording is stored'). Both the when and the when-not are stated, with the ordering constraint relative to a named sibling.

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