Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get Browser Session Replay

getBrowserSessionReplay
Read-only

Retrieve a browser session recording as compressed rrweb segments to replay visitor interactions and debug issues; data is masked and retained for 72 hours.

Instructions

Returns the session's recording as compressed rrweb segments, masked in the visitor's browser. Recordings are kept for 72 hours, apart from the app's other logs, so queryAppLogs cannot read them. A long session can return several megabytes. Needs the developer role, since recordings show what the app's visitors saw.

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": {
      "workspaceSlug": "<workspaceSlug>",
      "appSlug": "<appSlug>",
      "sessionId": "<sessionId>"
    },
    "name": "getBrowserSessionReplay"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
sessionIdYes
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses the response payload format (compressed rrweb segments), a privacy property (masked in the visitor's browser), a retention window of 72 hours, an auth requirement (developer role), and a size warning that a long session can return several megabytes. Those are exactly the operational facts an agent needs before invoking this.

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

Conciseness5/5

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

Four short sentences, front-loaded with the return format, then constraints, then size, then permissions. Every sentence contributes a distinct operational fact and there is no filler.

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?

For a read-only tool with no output schema, the description covers return format, payload size, retention, privacy masking, and required role, which is strong. The remaining gap is the undocumented env/region parameters and no guidance on how to source a sessionId, which matters for a five-parameter call.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters, yet the description only gestures at 'the session' and never explains workspaceSlug, appSlug, sessionId semantics or how to obtain a session id, nor what env and region do (the one enum parameter). With the schema carrying no descriptions, this leaves the parameter surface largely unexplained.

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: returns the session's recording as compressed rrweb segments. It also explicitly differentiates from the sibling queryAppLogs by saying recordings live apart from other logs and cannot be read there, so an agent can route correctly without inspecting 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 Guidelines4/5

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

Gives a clear selection signal (use this rather than queryAppLogs for what visitors saw) and a hard constraint (72-hour retention), which effectively scopes when the call can succeed. It stops short of naming a when-not or a sibling alternative for live monitoring, e.g. getBrowserMonitor, so it is not a full 5.

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

Deploy Server

Other Tools