Skip to main content
Glama
lekt9

OpenReplay MCP Server

by lekt9

search_sessions

Search and filter user sessions in OpenReplay by date, criteria, and pagination to analyze behavior patterns.

Instructions

[Requires userId with API key auth] Search and filter sessions. Full search requires JWT authentication.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userIdNoRequired: User ID to search sessions for
startDateNoStart date in ISO format
endDateNoEnd date in ISO format
filtersNoFilters (limited with API key auth)
limitNoNumber of sessions to return
offsetNoOffset for pagination
sortNo

Implementation Reference

  • The handler function that executes the search_sessions tool logic, querying OpenReplay API for user sessions with date filtering.
    private async searchSessions(args: any) {
      // Note: The v1 API with API keys has limited endpoints
      // For full session search, JWT authentication is required
      // This uses the user sessions endpoint as an alternative
      if (!args.userId) {
        return {
          content: [
            {
              type: "text",
              text: "Session search requires a userId when using API key authentication. For full search capabilities, JWT authentication is needed.",
            },
          ],
        };
      }
      
      const response = await this.api.get(`/api/v1/${OPENREPLAY_PROJECT_KEY}/users/${args.userId}/sessions`, {
        params: {
          start_date: args.startDate ? new Date(args.startDate).getTime() : Date.now() - 7 * 24 * 60 * 60 * 1000,
          end_date: args.endDate ? new Date(args.endDate).getTime() : Date.now()
        }
      });
    
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(response.data, null, 2),
          },
        ],
      };
    }
  • The tool schema definition including name, description, and input schema for search_sessions.
    {
      name: "search_sessions",
      description: "[Requires userId with API key auth] Search and filter sessions. Full search requires JWT authentication.",
      inputSchema: {
        type: "object",
        properties: {
          userId: { type: "string", description: "Required: User ID to search sessions for" },
          startDate: { type: "string", description: "Start date in ISO format" },
          endDate: { type: "string", description: "End date in ISO format" },
          filters: {
            type: "array",
            description: "Filters (limited with API key auth)",
            items: {
              type: "object",
              properties: {
                type: { type: "string", description: "Filter type" },
                operator: { type: "string", description: "Operator" },
                value: { type: ["string", "number", "array"], description: "Filter value" }
              }
            }
          },
          limit: { type: "number", description: "Number of sessions to return" },
          offset: { type: "number", description: "Offset for pagination" },
          sort: {
            type: "object",
            properties: {
              field: { type: "string", description: "Field to sort by" },
              order: { type: "string", enum: ["asc", "desc"], description: "Sort order" }
            }
          }
        },
        required: []
      }
    },
  • src/index.ts:278-279 (registration)
    The switch case that registers and dispatches to the search_sessions handler.
    case "search_sessions":
      return await this.searchSessions(args);
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context about authentication requirements (API key vs JWT) and functional limitations ('filters (limited with API key auth)'), which are crucial behavioral traits. However, it doesn't mention rate limits, pagination behavior beyond parameters, or what happens with missing parameters, leaving some gaps.

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?

The description is extremely concise with just two sentences that are front-loaded with essential information. Every sentence earns its place by covering authentication requirements and functional scope. There's zero waste or redundancy.

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

Completeness3/5

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

Given the complexity (7 parameters, nested objects) and lack of both annotations and output schema, the description is incomplete. It covers authentication needs but doesn't explain return values, error conditions, or how parameters interact (e.g., what happens if startDate is missing). For a search tool with rich parameters, more context about results and behavior would be helpful.

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 high at 86%, so the baseline is 3 even though the description adds no parameter-specific information beyond what's in the schema. The description mentions authentication constraints that affect parameters (e.g., filters being limited with API key auth), but this is more about behavioral context than parameter semantics. The schema already documents all parameters well.

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 the tool's purpose as 'Search and filter sessions' which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'get_user_sessions' or 'get_session_details', which likely have overlapping functionality. The description is clear but lacks sibling differentiation.

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

Usage Guidelines3/5

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

The description provides some usage context by mentioning authentication requirements ('Requires userId with API key auth' and 'Full search requires JWT authentication'), which implies when certain features are available. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_user_sessions' or 'aggregate_sessions', nor does it provide clear exclusions or prerequisites beyond authentication.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lekt9/openreplay-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server