Loading ToolBench
Slack check-in analysis service and MCP agent for monitoring team daily check-ins, engagement metrics, and attendance
The server defines 4 tools with basic functionality, but has significant gaps in descriptions, parameter documentation, and output schema definition. Tool descriptions are present but minimal (10-20 chars for most). Parameter descriptions are mostly absent or trivial. No output schemas are documented. The server appears to use FastMCP framework correctly for registration, but the definitions themselves lack the rigor needed for production LLM agents. Naming is reasonable (verb_noun pattern), but description quality and schema completeness fall well below the median baseline of 194 chars for tool descriptions and 72 chars for parameter annotations.
Return the list of users who did not submit a check-in for the date.
Return aggregate engagement metrics for the requested period.
Return today's check-ins.
Return a specific user's check-in for the given date.
Tool descriptions are too brief (10-30 chars) to guide LLM selection. 'Return today's check-ins' does not explain when to use this vs get_user_checkin, what a 'check-in' is, or what fields are returned. Baseline: 194 chars average for A+ tools.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., user_id, check-in text, quality metric) without knowing the response structure. Missing return type documentation prevents proper tool composition.
get_daily_checkins accepts no parameters and has no pagination support. For active Slack workspaces with dozens of daily check-ins, returning all results at once will bloat token usage. No limit, page, or cursor parameters to control result size.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Parameter 'date' in get_absentees and get_user_checkin has description 'Optional date in YYYY-MM-DD format. Defaults to today if not provided.' but lacks explicit format constraint or enum validation. No error message documented for invalid dates (e.g., '2024-13-45'). LLMs will guess format and may pass invalid values.
No error handling patterns documented. No guidance for LLMs on what to do if a user_id is invalid, date is out of range, or database query fails. A 500 error or missing user will not be actionable.
Parameter descriptions are minimal or absent. 'user_id' is labeled 'The Slack user ID' but no guidance on format (is it 'U12345' or 'john@example.com'?), whether lookup tools exist, or how to resolve from a display name. 'period' enum is documented but no description of what 'month', 'week', 'day' aggregate or how they differ.
No idempotency guarantees documented. If get_daily_checkins is called twice in a retry loop, does it return the same result? Are concurrent requests to the same endpoint safe? No mention of idempotent hints or retry safety.