Loading ToolBench
The Routine Model Context Protocol server, allowing AI clients to interact with Routine
The server defines 12 tools for Routine calendar/contact management with consistent Zod-based schema registration. However, quality is hampered by: (1) nearly all tool descriptions are extremely terse (3 - 21 characters), far below the 10 - 1024 char baseline and insufficient for LLM decision-making; (2) input parameter descriptions are either missing entirely or minimal (e.g., 'calendar-id' instead of 'The unique identifier for the calendar'); (3) output schemas are not documented, LLMs cannot infer what fields to expect from responses; (4) naming conventions are inconsistent (verb_noun for some, but eventDay uses camelCase instead of event_get pattern); (5) error handling returns a generic 'Error fetching auth id' message on all failures, which does not guide recovery and contains a copy-paste bug (all errors say 'auth id' regardless of tool); (6) no parameter validation beyond type constraints, ranges, patterns, and format expectations are undescribed; (7) taskCreateSimple is poorly named and its description is unclear about what fields are actually required vs optional. The codebase shows structured Zod schemas for input validation, which is positive, but the tool definitions themselves lack the contextual depth needed for reliable LLM invocation.
Main user identity.
All calendars.
A calendar.
The events on a given day.
An event.
Agenda view for a day.
All pages.
Descriptions are critically terse (median ~15 chars, many <20). Rubric baseline is 10 - 1024 chars with a target of ~194 chars for signal-rich definitions. All descriptions fail the baseline adequacy test.
Input parameter descriptions are missing or minimal. 'calendar-id' and 'event-id' are schema IDs, not descriptions. LLMs cannot infer what a 'calendar-id' is, how to obtain it, or what format is expected without a human-readable description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get a page.
The potential contact owning this email address.
The contact with the given id.
Complete a task.
Create a task (simplified for MCP). Usually you only need to pass the title. Do not try to pass the integration_id or distant_task_id.
Output schemas are not documented. LLMs cannot infer what fields are returned (e.g., does calendarGet return {id, name, owner, color}?), making it impossible to plan downstream tool calls or extract relevant data.
Error handling is generic and identical across all tools. All errors return 'Error fetching auth id: <message>' (copy-paste bug). Errors do not guide recovery (pattern:recovery-guide). LLMs receive no actionable guidance on retry, user correction, or alternative tools.
Destructive operations (taskComplete, taskCreateSimple) do not clearly state in their descriptions that they modify state. Pattern:command-tool requires 'If the tool modifies state (creates, updates, deletes, sends), the description must say so.' LLMs need to know which calls are safe to retry.
Naming conventions are inconsistent. eventDay and eventTimeline use camelCase instead of verb_noun convention (event_day, event_timeline). taskCreateSimple mixes 'Create' with 'Simple' suggesting multiple responsibilities; should be 'task_create'. Inconsistent naming increases LLM confusion when selecting among 12 tools.
taskCreateSimple has a broken parameter design: exposes 'ignored', 'completed', 'integration_id', 'distant_task_id' fields, then tells LLMs not to pass them in the description. This is an anti-pattern (pattern:constrained-input). Remove fields you don't want LLMs to use; do not expose and then forbid them.
Parameter types are declared via Zod but lack constraints. Date parameters accept 3-element arrays but no validation of month (1 - 12?) or day (1 - 31?) bounds. 'filter' enum is well-defined, but most numeric/string parameters lack format, length, or range documentation in descriptions.
No pagination support documented or exposed. Tools like pageAll and calendarAll may return large lists but provide no limit, offset, or cursor parameters.