Skip to main content
Glama
nks-hub

rybbit-mcp

by nks-hub

List Sessions

rybbit_list_sessions
Read-onlyIdempotent

Retrieve and filter website user sessions with details like duration, pages visited, and location. Supports date ranges, pagination, and client-side IP filtering for analytics review.

Instructions

List sessions for a site with filtering and pagination. Returns session ID, user info, device, location, pages visited, duration, bounce status, and IP address (if site has trackIp enabled). Supports client-side IP filtering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteIdYesSite ID (numeric ID or domain identifier)
startDateNoStart date in ISO format (YYYY-MM-DD)
endDateNoEnd date in ISO format (YYYY-MM-DD)
timeZoneNoIANA timezone (e.g., Europe/Prague). Default: UTC
filtersNoArray of filters. Example: [{parameter:'browser',type:'equals',value:['Chrome']},{parameter:'country',type:'equals',value:['US','DE']}]
pastMinutesStartNoAlternative to dates: minutes ago start (e.g., 60 = last hour)
pastMinutesEndNoAlternative to dates: minutes ago end (default 0 = now)
pageNoPage number, 1-indexed (default: 1)
limitNoResults per page (default: 20-50 depending on endpoint, max 200)
ipNoFilter sessions by IP address (exact or partial match, client-side). Requires site to have trackIp enabled.
identifiedOnlyNoOnly return sessions from identified users. Default: false.
minDurationNoMinimum session duration in seconds.

Implementation Reference

  • The implementation and registration of the 'rybbit_list_sessions' tool.
    server.registerTool(
      "rybbit_list_sessions",
      {
        title: "List Sessions",
        description:
          "List sessions for a site with filtering and pagination. Returns session ID, user info, device, location, pages visited, duration, bounce status, and IP address (if site has trackIp enabled). Supports client-side IP filtering.",
        annotations: {
          readOnlyHint: true,
          idempotentHint: true,
          openWorldHint: true,
          destructiveHint: false,
        },
        inputSchema: {
          ...analyticsInputSchema,
          ...paginationSchema,
          ip: z
            .string()
            .optional()
            .describe("Filter sessions by IP address (exact or partial match, client-side). Requires site to have trackIp enabled."),
          identifiedOnly: z
            .boolean()
            .optional()
            .describe("Only return sessions from identified users. Default: false."),
          minDuration: z
            .number()
            .optional()
            .describe("Minimum session duration in seconds."),
        },
      },
      async (args) => {
        try {
          const { siteId, page, limit, ip, identifiedOnly, minDuration, ...rest } = args as {
            siteId: string;
            page?: number;
            limit?: number;
            ip?: string;
            identifiedOnly?: boolean;
            minDuration?: number;
            startDate?: string;
            endDate?: string;
            timeZone?: string;
            filters?: Array<{ parameter: string; type: string; value: (string | number)[] }>;
            pastMinutesStart?: number;
            pastMinutesEnd?: number;
          };
    
          const params = client.buildAnalyticsParams({ ...rest, page, limit });
          if (identifiedOnly) params.identified_only = "true";
          if (minDuration !== undefined) params.min_duration = String(minDuration);
    
          if (ip) {
            // IP filtering: fetch multiple pages and filter client-side
            const allSessions: Record<string, unknown>[] = [];
            let fetchPage = 1;
            const batchSize = 200;
            const maxSessions = 2000;
            const ipLower = ip.toLowerCase();
    
            while (allSessions.length < maxSessions) {
              const batchParams = { ...params, page: String(fetchPage), limit: String(batchSize) };
              const batch = await client.get<{ data: Record<string, unknown>[] }>(
                `/sites/${siteId}/sessions`,
                batchParams
              );
              const rows = batch?.data ?? (Array.isArray(batch) ? batch : []);
              if (rows.length === 0) break;
    
              for (const s of rows) {
                const sessionIp = String(s.ip || "");
                if (sessionIp && sessionIp.toLowerCase().includes(ipLower)) {
                  allSessions.push(s);
                }
              }
              if (rows.length < batchSize) break;
              fetchPage++;
            }
    
            return {
              content: [
                {
                  type: "text" as const,
                  text: truncateResponse({ data: allSessions, filteredBy: `ip=${ip}`, scannedPages: fetchPage }),
                },
              ],
            };
          }
    
          const data = await client.get<SessionSummary[]>(
            `/sites/${siteId}/sessions`,
            params
          );
    
          return {
            content: [
              {
                type: "text" as const,
                text: truncateResponse(data),
              },
            ],
          };
        } catch (err) {
          const message = err instanceof Error ? err.message : String(err);
          return {
            content: [{ type: "text" as const, text: `Error: ${message}` }],
            isError: true,
          };
        }
      }
    );
Behavior4/5

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

Annotations declare readOnly/idempotent hints. The description adds valuable behavioral context beyond annotations: it discloses the exact return fields (session ID, user info, device, etc.) and critically notes the conditional availability of IP addresses based on site configuration. This helps the agent understand data availability without calling the tool.

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 consists of two dense, information-rich sentences. The first establishes scope (list + filtering/pagination), while the second details return values and IP conditional logic. Every clause earns its place with zero 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 tool has 12 parameters including complex filtering options and no output schema, the description adequately covers return fields but misses guidance on parameter relationships (e.g., date vs pastMinutes alternatives) and doesn't mention the identifiedOnly or minDuration filtering capabilities.

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?

With 100% schema description coverage, the baseline is 3. The description adds minor semantic value by specifying 'client-side IP filtering' for the ip parameter and implying the purpose of filters/pagination, but most parameter semantics are already well-documented in the schema.

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 'List sessions for a site' with specific functionality 'filtering and pagination', which implicitly distinguishes it from the sibling 'rybbit_get_session' (singular). However, it doesn't explicitly name the sibling alternative to clarify when to use which.

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 noting IP addresses are only returned 'if site has trackIp enabled' and mentions 'client-side IP filtering'. However, it lacks explicit guidance on when to use date parameters vs pastMinutes parameters, or when to choose this over the singular get_session tool.

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/nks-hub/rybbit-mcp'

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