Skip to main content
Glama
mendeel

Mixpanel MCP

by mendeel

aggregated_event_property_values

Analyze event property value distributions in Mixpanel to understand user behavior patterns and identify common values across specified date ranges.

Instructions

Analyze specific event properties and their values. Useful for understanding property distributions and identifying common values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoThe Mixpanel project ID. Optional since it has a default.
eventYesThe event name to analyze properties for
propertyYesThe property name to get values for
from_dateYesThe date in yyyy-mm-dd format to begin querying from (inclusive)
to_dateYesThe date in yyyy-mm-dd format to query to (inclusive)
limitNoMaximum number of property values to return

Implementation Reference

  • The handler function that executes the tool: queries Mixpanel API endpoint /events/properties/values for the specified event and property values within date range, handles auth with Basic auth, returns JSON data or error.
    async function handleAggregatedEventPropertyValues(args: any, config: any) {
      const { project_id = config.DEFAULT_PROJECT_ID, event, property, from_date, to_date, limit = 100 } = args;
      
      try {
        const credentials = `${config.SERVICE_ACCOUNT_USER_NAME}:${config.SERVICE_ACCOUNT_PASSWORD}`;
        const encodedCredentials = Buffer.from(credentials).toString('base64');
        
        const url = `${config.MIXPANEL_BASE_URL}/events/properties/values?project_id=${project_id}&event=${encodeURIComponent(event)}&name=${encodeURIComponent(property)}&from_date=${from_date}&to_date=${to_date}&limit=${limit}`;
        
        const options = {
          method: 'GET',
          headers: {
            'accept': 'application/json',
            'authorization': `Basic ${encodedCredentials}`
          }
        };
        
        const response = await fetch(url, options);
        
        if (!response.ok) {
          const errorText = await response.text();
          throw new Error(`HTTP error! status: ${response.status} - ${errorText}`);
        }
        
        const data = await response.json();
        
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(data)
            }
          ]
        };
      } catch (error: unknown) {
        console.error("Error fetching event property values:", error);
        const errorMessage = error instanceof Error ? error.message : String(error);
        return {
          content: [
            {
              type: "text",
              text: `Error fetching event property values: ${errorMessage}`
            }
          ],
          isError: true
        };
      }
    }
  • Input schema defining parameters for the tool: project_id (opt), event, property, from_date, to_date (req), limit (opt). Used for validation.
    type: "object",
    properties: {
      project_id: {
        type: "string",
        description: "The Mixpanel project ID. Optional since it has a default."
      },
      event: {
        type: "string",
        description: "The event name to analyze properties for"
      },
      property: {
        type: "string",
        description: "The property name to get values for"
      },
      from_date: {
        type: "string",
        description: "The date in yyyy-mm-dd format to begin querying from (inclusive)"
      },
      to_date: {
        type: "string",
        description: "The date in yyyy-mm-dd format to query to (inclusive)"
      },
      limit: {
        type: "number",
        description: "Maximum number of property values to return"
      }
    },
    required: ["event", "property", "from_date", "to_date"]
  • src/index.ts:310-342 (registration)
    Tool registration in the tools list provided to server.setRequestHandler for ListToolsRequestSchema, including name, description, and inputSchema.
    {
      name: "aggregated_event_property_values",
      description: "Analyze specific event properties and their values. Useful for understanding property distributions and identifying common values.",
      inputSchema: {
        type: "object",
        properties: {
          project_id: {
            type: "string",
            description: "The Mixpanel project ID. Optional since it has a default."
          },
          event: {
            type: "string",
            description: "The event name to analyze properties for"
          },
          property: {
            type: "string",
            description: "The property name to get values for"
          },
          from_date: {
            type: "string",
            description: "The date in yyyy-mm-dd format to begin querying from (inclusive)"
          },
          to_date: {
            type: "string",
            description: "The date in yyyy-mm-dd format to query to (inclusive)"
          },
          limit: {
            type: "number",
            description: "Maximum number of property values to return"
          }
        },
        required: ["event", "property", "from_date", "to_date"]
      }
  • src/index.ts:615-616 (registration)
    Dispatch case in the main tool call handler switch statement that routes calls to this tool to its handler function.
    case "aggregated_event_property_values":
      return await handleAggregatedEventPropertyValues(args, { SERVICE_ACCOUNT_USER_NAME, SERVICE_ACCOUNT_PASSWORD, DEFAULT_PROJECT_ID, MIXPANEL_BASE_URL });
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is for analysis, implying it's likely a read-only operation, but doesn't confirm this or describe other traits like rate limits, authentication needs, error handling, or what the output looks like (e.g., format, pagination). For a tool with 6 parameters and no annotations, this leaves significant gaps in understanding how it behaves.

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

Conciseness4/5

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

The description is concise with two sentences: the first states the purpose, and the second provides usage context. It's front-loaded with the core function and wastes no words. However, it could be slightly more structured by explicitly naming the tool's output or limitations to enhance clarity without losing conciseness.

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 (6 parameters, no annotations, no output schema), the description is minimally adequate. It covers the purpose and high-level usage but lacks details on behavioral traits, output format, and differentiation from siblings. For a data analysis tool with multiple parameters, more context is needed to fully guide an agent, but it meets a basic threshold without being misleading.

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?

The input schema has 100% description coverage, providing clear details for all 6 parameters (e.g., 'event' as 'The event name to analyze properties for'). The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. With high schema coverage, the baseline score is 3, as the schema adequately documents parameters without extra help from the description.

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: 'Analyze specific event properties and their values.' It specifies the verb 'analyze' and the resource 'event properties and their values.' However, it doesn't explicitly differentiate from siblings like 'query_segmentation_report' or 'aggregate_event_counts,' which might also analyze event data but with different scopes or outputs.

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: 'Useful for understanding property distributions and identifying common values.' This suggests the tool is for statistical analysis of property values. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'query_segmentation_report' for segmentation or 'aggregate_event_counts' for event counts), nor does it mention prerequisites or exclusions.

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/mendeel/mixpanel-mcp'

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