Loading ToolBench
MCP server for Mixpanel analytics integration with AI assistants
The server defines 4 tools with explicit schemas and basic descriptions, but falls short of production-grade quality. All tools have descriptions (10-70 chars, below ideal 50-200 range), and schemas are present but lack depth in parameter documentation and output specification. No tool annotations (readOnlyHint/destructiveHint) despite all tools being WRITE operations. No output schema documentation. Parameter descriptions exist but are minimal and generic. Error handling returns basic text rather than structured recovery guidance. This is a typical community-grade server: functional but not polished.
Update a user's profile properties in Mixpanel
Track a custom event in Mixpanel
Track a page view event in Mixpanel
Track a signup event and create a user profile in Mixpanel
No tool annotations despite destructive operations. All 4 tools modify Mixpanel state (write events, track users, update profiles), but none declare destructiveHint=true or idempotentHint. LLMs cannot determine retry safety or warn users of irreversible consequences.
Output schemas not documented. Tools return unstructured text results like 'Successfully tracked event...'. LLMs cannot parse response structure, chain results to downstream tools, or extract actionable data. Compare to pattern: return structured objects with typed fields.
Minimal parameter descriptions. 'properties' param in track_event and set_user_profile described as 'Additional properties...' and 'Profile properties...' respectively, vague and generic. LLMs need specific guidance on valid property names, types, and constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No error recovery guidance. Error responses are plain text (e.g., 'Missing required parameter: event_name'). LLMs receive no actionable next step. Pattern requires: 'Error responses must tell the LLM what to do next.'
Implicit default for distinct_id. track_event and track_pageview default missing distinct_id to 'anonymous'. This silent behavior is dangerous, users may unintentionally associate events with an anonymous user instead of the intended person. No warning in description.
No distinction between optional and required parameters in descriptions. 'distinct_id' marked optional in schema but treated as optional with a fallback in implementation. No clear guidance on when to omit vs. provide.