Skip to main content
Glama
nks-hub

rybbit-mcp

by nks-hub

Analyze Funnel

rybbit_analyze_funnel
Read-onlyIdempotent

Analyze user conversion funnels by defining custom steps (pages or events) to track visitor counts and drop-off rates across your website.

Instructions

Analyze a custom funnel by defining steps (page visits or events). Returns visitor counts and drop-off rates at each step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteIdYesSite ID (numeric ID or domain identifier)
startDateNoStart date (YYYY-MM-DD)
endDateNoEnd date (YYYY-MM-DD)
timeZoneNoIANA timezone (default UTC)
filtersNoFilters to apply
pastMinutesStartNoMinutes ago start
pastMinutesEndNoMinutes ago end
stepsYesFunnel steps to analyze (minimum 2)

Implementation Reference

  • The handler function for 'rybbit_analyze_funnel' which takes funnel steps and filters, builds the analytics parameters, and POSTs to the analysis endpoint.
    async (args) => {
      try {
        const { siteId, steps, ...rest } = args as {
          siteId: string;
          steps: FunnelStep[];
          startDate?: string;
          endDate?: string;
          timeZone?: string;
          filters?: Array<{
            parameter: string;
            type: string;
            value: (string | number)[];
          }>;
          pastMinutesStart?: number;
          pastMinutesEnd?: number;
        };
    
        const params = client.buildAnalyticsParams(rest);
    
        const data = await client.post<FunnelAnalysisResult>(
          `/sites/${siteId}/funnels/analyze`,
          { steps },
          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,
        };
      }
    }
  • Input schema definition for the 'rybbit_analyze_funnel' tool, defining siteId, optional date/time range filters, and the required array of funnel steps.
    inputSchema: {
      siteId: siteIdSchema,
      startDate: z
        .string()
        .optional()
        .describe("Start date (YYYY-MM-DD)"),
      endDate: z
        .string()
        .optional()
        .describe("End date (YYYY-MM-DD)"),
      timeZone: z
        .string()
        .optional()
        .describe("IANA timezone (default UTC)"),
      filters: z
        .array(filterSchema)
        .optional()
        .describe("Filters to apply"),
      pastMinutesStart: z
        .number()
        .optional()
        .describe("Minutes ago start"),
      pastMinutesEnd: z
        .number()
        .optional()
        .describe("Minutes ago end"),
      steps: z
        .array(
          z.object({
            value: z.string().describe("Page path or event name"),
            type: z.enum(["page", "event"]).describe("Step type"),
            name: z
              .string()
              .optional()
              .describe("Display name for the step"),
          })
        )
        .min(2)
        .describe("Funnel steps to analyze (minimum 2)"),
    },
  • Registration of the 'rybbit_analyze_funnel' tool on the McpServer.
    server.registerTool(
      "rybbit_analyze_funnel",
      {
        title: "Analyze Funnel",
        description:
          "Analyze a custom funnel by defining steps (page visits or events). Returns visitor counts and drop-off rates at each step.",
        annotations: {
          readOnlyHint: true,
          idempotentHint: true,
          openWorldHint: true,
          destructiveHint: false,
        },
        inputSchema: {
          siteId: siteIdSchema,
          startDate: z
            .string()
            .optional()
            .describe("Start date (YYYY-MM-DD)"),
          endDate: z
            .string()
            .optional()
            .describe("End date (YYYY-MM-DD)"),
          timeZone: z
            .string()
            .optional()
            .describe("IANA timezone (default UTC)"),
          filters: z
            .array(filterSchema)
            .optional()
            .describe("Filters to apply"),
          pastMinutesStart: z
            .number()
            .optional()
            .describe("Minutes ago start"),
          pastMinutesEnd: z
            .number()
            .optional()
            .describe("Minutes ago end"),
          steps: z
            .array(
              z.object({
                value: z.string().describe("Page path or event name"),
                type: z.enum(["page", "event"]).describe("Step type"),
                name: z
                  .string()
                  .optional()
                  .describe("Display name for the step"),
              })
            )
            .min(2)
            .describe("Funnel steps to analyze (minimum 2)"),
        },
      },
Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by disclosing what the analysis returns (visitor counts and drop-off rates), which compensates partially for the missing output schema. However, it omits additional behavioral context like caching behavior, performance characteristics, or the relationship between date filters and results.

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 efficient sentences with zero redundancy. The first sentence defines the action and mechanism; the second specifies return values. Every word earns its place in guiding tool selection.

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?

Given the tool's complexity (8 parameters including flexible filtering and step definitions), 100% schema coverage, and absence of an output schema, the description provides adequate context by explaining the return format (counts and drop-off rates). It appropriately relies on the comprehensive schema for parameter details while conveying the core value proposition.

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 mentions 'defining steps (page visits or events)' which aligns with the steps parameter structure, but adds no semantic detail beyond what the schema already provides regarding the 8 parameters (siteId, date ranges, filters, etc.).

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 analyzes custom funnels by defining steps (page visits or events) and specifies the returned metrics (visitor counts and drop-off rates). It implicitly distinguishes from siblings like rybbit_list_funnels (which lists saved funnels) by emphasizing 'custom' funnel analysis, though it doesn't explicitly name alternatives.

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 implied usage guidance through the phrase 'custom funnel' (suggesting dynamic, ad-hoc analysis versus pre-saved funnels), but lacks explicit when-to-use/when-not-to-use guidance or comparison with related analytics tools like rybbit_get_journeys or rybbit_get_metric.

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