Loading ToolBench
MCP server for querying Hardal (usehardal.com) analytics data via its Analytics API
Three well-named, read-only analytics tools with comprehensive parameter schemas and strong descriptions. All tools follow verb_noun naming (get_*, list_*). Descriptions are detailed (150-250 chars) and include usage guidance ('prefer this over more specialised tools'). Parameters are typed with enums, defaults, and ranges. However, output schemas are not documented in the source, LLMs cannot see what fields to expect from responses. Error handling is absent from tool definitions. No tool annotations (readOnlyHint) despite all being read-only. Composition is sound: tools chain via target_signal_id parameter.
Fetch aggregated event counts (event count, sessions, visitors) per event name over a date range, sorted by count descending. Use this to answer "which events fire, and how often" — for a broad overview of a period, `get_analytics_overview` is usually the better first call.
Fetch the aggregated analytics dashboard snapshot for a date range: summary totals, the top event names, top pages/referrers/locations, browser/device/OS distribution, and a time series. This is the best starting point for any "what happened" question — prefer it over the more specialised tools. Note: a wide date range at `interval: "minute"` or `"hour"` returns a very large response; leave `interval` unset (daily) unless the question genuinely needs finer granularity.
Rank marketing campaigns/channels by a chosen metric over a date range, from the Analytics API Campaign Report.
Output schemas not documented. LLMs cannot see what fields responses contain, forcing them to guess downstream field names and risking broken tool chains.
No tool annotations despite all tools being read-only. Missing readOnlyHint would help agents understand these are safe to call without side effects.
No error handling guidance in tool definitions. If an invalid date range or signal_id is passed, LLMs have no recovery path documented.
Large result sets not capped in tool descriptions. get_analytics_overview with minute/hour interval over wide date ranges could return thousands of rows, exhausting context.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Parameter 'interval' defaults to 'day' but description warns that minute/hour over wide ranges produce 'very large responses', no explicit cap or pagination mechanism offered.