Loading ToolBench
Model Context Protocol server for EzStat — let AI agents push and read your metrics natively.
EzStat MCP server demonstrates solid tool design with clear naming, comprehensive parameter schemas, and good descriptions. All 7 tools have explicit Zod schemas with type constraints and descriptions. Naming follows verb_noun convention (track_metric, ask_ezstat, read_stat, list_stats, create_alert, list_alerts, delete_alert). Descriptions are substantive (100-250 chars typical), explaining WHAT the tool does and WHEN to use it. Parameter descriptions include format hints and constraints. However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Error handling guidance is absent; tools do not explain recovery paths. Some parameter relationships are undocumented (e.g., threshold behavior differs by condition_type but this is not explicitly stated in parameter descriptions). Tool composition is sound, each tool has one responsibility, and naming makes distinctions clear (read_stat vs ask_ezstat vs list_stats).
Ask a natural-language question about the account's metrics. This is the agent-read path: send a question like "what spiked yesterday?" or "compare signups vs cancellations last 7 days" and EzStat returns a grounded answer plus the underlying data it used.
Create an alert that fires when a metric crosses a threshold, moves too fast, or goes quiet. Webhook delivery is available; email delivery is coming soon.
Delete an alert by ID.
List all alerts configured on this account.
List the account's metrics — names and types. Call this first when you don't know what stats exist in the account.
Read a single stat: latest value, recent series, and basic summary (count/min/max/avg/sum). Use this for a structured read of one metric — prefer `ask_ezstat` for free-form questions over many stats.
Output schemas not documented. LLMs cannot see what fields track_metric, ask_ezstat, read_stat, list_stats, create_alert, list_alerts, or delete_alert return. This forces agents to guess at response structure and breaks tool chaining when downstream tools need IDs or references.
Error handling guidance missing. Tools do not explain what to do on failure (e.g., 'stat not found, call list_stats() first', 'invalid webhook, must be HTTPS'). Agents receive raw errors with no recovery path.
Parameter relationships undocumented. create_alert's threshold, window_minutes, and consecutive_required have different meanings depending on condition_type, but this dependency is not stated in parameter descriptions. LLMs may pass invalid combinations.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Record a metric point your app "produced". Use this whenever the surrounding code emits a counter or gauge — e.g. on a page view, a successful checkout, or a measured latency. Counters are +N (default +1), values are gauges (e.g. 42.5 ms).
list_alerts and delete_alert have minimal descriptions (60 - 65 chars). Descriptions should explain when to call list_alerts (e.g., 'Call this first to see configured alerts before deleting') and what delete_alert does (e.g., 'Permanently remove an alert by ID, this cannot be undone').
No pagination or result limits documented. ask_ezstat and read_stat may return large datasets (e.g., 'Top 5 fastest growing stats this week' could return hundreds of stats). No limit parameter or guidance on expected result size.