Anry

Get session frames

get_session_frames

Read-onlyIdempotent

What one session's pages looked like: images drawn from the recording at the moments get_session_replay names (each page, repeated clicks, the browser translation, clicks, field focus, scroll stops, idle starts), with the pointer marked. Without at it returns one contact sheet of up to 12 captioned thumbnails plus the index of every drawn moment; with at (offsets in seconds, as get_session_replay gives them) the full frames nearest those offsets. Use it when the question is visual (what was on screen, covered, below the fold) after get_session_replay. A session not drawn yet answers status rendering: retry after retry_after_seconds.

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

Input Schema

Name	Required	Description
`at`	No	Offsets in seconds from the session's start (as get_session_replay reports them); returns the full frame nearest each
`site_id`	Yes	Site id from list_sites (UUID)
`max_frames`	No	Most full frames to return with `at` (default 6)
`session_id`	Yes	Session id from list_sessions or get_session

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.5/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), and the description adds real behavior beyond them: the no-argument path returns a contact sheet of up to 12 thumbnails plus an index, the with-`at` path returns full frames, and an undrawn session returns status rendering with a retry hint. It does not describe image format or size, 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?

Front-loads the core purpose and keeps to a tight paragraph, but the parenthetical list of captured moments ('repeated clicks, the browser translation, clicks, field focus, scroll stops, idle starts') is repetitive and slows parsing. Some trimming would improve it without losing information.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does it reasonably well, describing both response shapes and the pending-rendering state. What is still thin is the visual payload itself (resolution, how thumbnails are captioned), but nothing an agent needs in order 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.

Parameters4/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 adds meaning the schema cannot: it explains the consequence of including `at` (full frames at those offsets) versus omitting it (one contact sheet plus index), and clarifies the offsets are in the same seconds scale get_session_replay reports. That is more than restating field types.

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 ('what one session's pages looked like: images drawn from the recording') and explicitly distinguishes itself from the sibling get_session_replay, which names moments rather than returning pictures. An agent can tell the two apart without opening either 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 trigger ('Use it when the question is visual (what was on screen, covered, below the fold)') and a prerequisite ordering ('after get_session_replay'). It also handles the not-ready case by telling the agent to retry after retry_after_seconds, which is genuine when-to-use guidance rather than none.

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?