Skip to main content
Glama
nks-hub

rybbit-mcp

by nks-hub

Metric Breakdown

rybbit_get_metric
Read-onlyIdempotent

Retrieve website analytics metric breakdown by dimension such as page, browser, country, or campaign. Filter by date range and apply conditions. Returns sorted data with counts, percentages, bounce rate, and session duration for analysis.

Instructions

Get metric breakdown by dimension. Use parameter='pathname' for top pages, 'browser'/'operating_system'/'device_type' for tech stats, 'country'/'city' for geo, 'utm_source'/'utm_campaign' for marketing, 'referrer'/'channel' for traffic sources, 'entry_page'/'exit_page' for user flow. Returns sorted list with counts, percentages, bounce rate, and session duration.

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)
parameterYesMetric dimension to break down by. device_model and app_version apply only to app-type sites tracked via SDK.
pageNoPage number, 1-indexed (default: 1)
limitNoResults per page (default: 20-50 depending on endpoint, max 200)

Implementation Reference

  • The async handler function for rybbit_get_metric. It destructures args (siteId, parameter, page, limit, and analytics params), builds query params via client.buildAnalyticsParams, sets the 'parameter' dimension, calls GET /sites/{siteId}/metric, and returns the data (truncated if needed). On error, returns an error message with isError:true.
      async (args) => {
        try {
          const { siteId, parameter, page, limit, ...rest } = args as {
            siteId: string;
            parameter: z.infer<typeof metricParameterSchema>;
            page?: number;
            limit?: 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 });
          params.parameter = parameter;
    
          const data = await client.get<MetricEntry[]>(
            `/sites/${siteId}/metric`,
            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,
          };
        }
      }
    );
  • metricParameterSchema — a Zod enum defining all valid dimensions for the 'parameter' input field: browser, browser_version, operating_system, operating_system_version, language, country, region, city, device_type, device_model, app_version, dimensions, referrer, hostname, pathname, page_title, querystring, event_name, channel, utm_source, utm_medium, utm_campaign, utm_term, utm_content, entry_page, exit_page, timezone, company, company_type, asn_org, asn_type.
    export const metricParameterSchema = z
      .enum([
        "browser",
        "browser_version",
        "operating_system",
        "operating_system_version",
        "language",
        "country",
        "region",
        "city",
        "device_type",
        "device_model",
        "app_version",
        "dimensions",
        "referrer",
        "hostname",
        "pathname",
        "page_title",
        "querystring",
        "event_name",
        "channel",
        "utm_source",
        "utm_medium",
        "utm_campaign",
        "utm_term",
        "utm_content",
        "entry_page",
        "exit_page",
        "timezone",
        "company",
        "company_type",
        "asn_org",
        "asn_type",
      ])
      .describe(
        "Metric dimension to break down by. device_model and app_version apply only to app-type sites tracked via SDK."
      );
  • analyticsInputSchema — shared input schema providing siteId, startDate, endDate, timeZone, filters (array of filter objects), pastMinutesStart, pastMinutesEnd. Combined with metricParameterSchema and paginationSchema in the tool's inputSchema.
    export const analyticsInputSchema = {
      siteId: siteIdSchema,
      startDate: z
        .string()
        .optional()
        .describe("Start date in ISO format (YYYY-MM-DD)"),
      endDate: z
        .string()
        .optional()
        .describe("End date in ISO format (YYYY-MM-DD)"),
      timeZone: z
        .string()
        .optional()
        .describe("IANA timezone (e.g., Europe/Prague). Default: UTC"),
      filters: z
        .array(filterSchema)
        .optional()
        .describe("Array of filters. Example: [{parameter:'browser',type:'equals',value:['Chrome']},{parameter:'country',type:'equals',value:['US','DE']}]"),
      pastMinutesStart: z
        .number()
        .optional()
        .describe("Alternative to dates: minutes ago start (e.g., 60 = last hour)"),
      pastMinutesEnd: z
        .number()
        .optional()
        .describe("Alternative to dates: minutes ago end (default 0 = now)"),
    };
    
    export const bucketSchema = z
      .enum([
        "minute",
        "five_minutes",
        "ten_minutes",
        "fifteen_minutes",
        "hour",
        "day",
        "week",
        "month",
        "year",
      ])
      .optional()
      .describe("Time bucket granularity (default: day). Use 'hour' for last 24h, 'week'/'month' for long ranges");
    
    export const paginationSchema = {
      page: z.number().int().min(1).optional().describe("Page number, 1-indexed (default: 1)"),
      limit: z
        .number()
        .int()
        .min(1)
        .max(200)
        .optional()
        .describe("Results per page (default: 20-50 depending on endpoint, max 200)"),
    };
  • paginationSchema — optional page (1-indexed integer) and limit (1-200 integer) for paginated results.
    export const paginationSchema = {
      page: z.number().int().min(1).optional().describe("Page number, 1-indexed (default: 1)"),
      limit: z
        .number()
        .int()
        .min(1)
        .max(200)
        .optional()
        .describe("Results per page (default: 20-50 depending on endpoint, max 200)"),
    };
  • Registration of the tool via server.registerTool('rybbit_get_metric', ...) with title, description, annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint), and inline inputSchema built from spread schemas.
    server.registerTool(
      "rybbit_get_metric",
      {
        title: "Metric Breakdown",
        description:
          "Get metric breakdown by dimension. Use parameter='pathname' for top pages, 'browser'/'operating_system'/'device_type' for tech stats, 'country'/'city' for geo, 'utm_source'/'utm_campaign' for marketing, 'referrer'/'channel' for traffic sources, 'entry_page'/'exit_page' for user flow. Returns sorted list with counts, percentages, bounce rate, and session duration.",
        annotations: {
          readOnlyHint: true,
          idempotentHint: true,
          openWorldHint: true,
          destructiveHint: false,
        },
        inputSchema: {
          ...analyticsInputSchema,
          parameter: metricParameterSchema,
          ...paginationSchema,
        },
      },
      async (args) => {
        try {
          const { siteId, parameter, page, limit, ...rest } = args as {
            siteId: string;
            parameter: z.infer<typeof metricParameterSchema>;
            page?: number;
            limit?: 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 });
          params.parameter = parameter;
    
          const data = await client.get<MetricEntry[]>(
            `/sites/${siteId}/metric`,
            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 already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral detail by specifying the sorted return format with counts, percentages, bounce rate, and session duration. No contradictions. However, it doesn't discuss pagination behavior or rate limits, which are partially covered by schema.

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 a single paragraph of 4 sentences, front-loaded with the core purpose. Every sentence adds value—examples, return fields. No wasted words.

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?

Despite 10 parameters and no output schema, the description covers purpose, parameter usage guidance, and return structure. It addresses the tool's complexity well. The only minor gap is a lack of explicit guidance on when to use this vs other get_* tools, but the comprehensive examples implicitly differentiate it.

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% (all parameters have descriptions), so baseline is 3. The description adds value by explaining how the 'parameter' field is used in practice (e.g., 'pathname for top pages') and noting that device_model and app_version only apply to app-type sites. This goes beyond the schema.

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 clearly states 'Get metric breakdown by dimension' and provides specific examples (top pages, tech stats, geo, marketing, traffic sources, user flow). This distinguishes it from sibling tools like get_overview or get_performance.

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?

The description gives explicit guidance on which dimension values to use for different analysis purposes (e.g., 'Use parameter='pathname' for top pages'). It doesn't explicitly say when not to use this tool, but the level of detail allows the agent to infer appropriate usage.

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