MCP Server for Chat BullQ — dashboard indicators (read-only) via Claude Code
Server provides 9 read-only dashboard tools with consistent naming (chat_dashboard_*) and reasonable descriptions (avg ~120 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the source code, parameter descriptions lack format/constraint details (e.g., date format examples), and error handling guidance is minimal. No tool annotations (readOnlyHint) despite all being read-only. Naming is clear but generic (dashboard-heavy); descriptions explain WHAT but not WHEN to use each tool relative to others.
Per-agent performance: total/closed conversations, current load, resolution rate, avg first response, avg resolution time.
Daily series for hero KPIs: active conversations, first response time, SLA %, resolution %.
Hero KPIs: active conversations (with breakdown), TMR, SLA compliance, resolution rate, totals + trends vs previous period.
Heatmap of conversation creation: 7 (day of week) × 24 (hour) matrix. Returns the busiest day/hour.
Conversation volume grouped by channel (WhatsApp, Instagram, etc.).
Conversation volume per day (count of conversations created).
Output schemas not documented. LLMs cannot infer what fields each dashboard tool returns, forcing them to guess at response structure and risking failed downstream reasoning.
Date parameters lack format specification. Descriptions say 'ISO 8601 or YYYY-MM-DD' but do not clarify which is preferred, whether time is required, or timezone handling. LLMs frequently miscalculate date conversions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Snapshot of conversations grouped by current status (PENDING, BOT, OPEN, WAITING, CLOSED).
Created vs closed conversations per day (flow into and out of the queue).
Identifies the API key holder (user + organization). Useful as a sanity check.
No tool annotations despite all tools being read-only. Missing readOnlyHint metadata prevents clients from optimizing caching and retry logic.
Error handling not documented. No guidance on what errors each tool can return, whether they are retryable, or what the LLM should do next (e.g., 'Invalid date range' or 'API rate limit exceeded').
Overlapping tool purposes not disambiguated. 'chat_dashboard_volume_by_day' vs 'chat_dashboard_volume_flow' both show volume over time but with different semantics (created only vs created+closed). Descriptions do not explain when to use each.