Loading ToolBench
MCP server for managing recurring tasks and events with calendar synchronization
The server defines 7 tools with complete input schemas and basic descriptions. Tool naming follows verb_noun patterns (list_items, get_item, create_item, etc.), which is good. However, parameter descriptions are largely absent, most input parameters lack descriptions explaining what they control or their constraints. The create_item and update_item tools accept 13 optional parameters with complex interdependencies (e.g., event_time only applies when all_day=false, reminder_offsets accepts both string and array formats) but these dependencies are not documented in parameter descriptions. Output schemas are partially documented in code (_serialize_event, _serialize_history functions) but not explicitly exposed in tool definitions. Error handling returns structured responses with 'ok' and 'error' fields, but lacks recovery guidance. The parse_import tool is unique but underdocumented, what format does it expect? The reminder_offsets parameter is particularly problematic: it accepts 'Either a comma-separated string like -14,-7,0 or an integer array' but the description includes an example value that LLMs may reuse literally.
Mark the current round complete. Clears future scheduled reminders and adds a same-day (Completed) record.
Create a new recurring tracker item. Only title is strictly required; omitted fields use tracker defaults.
Get one recurring tracker item by event_id.
List all non-deleted recurring tracker items.
Parse a pasted import block into structured recurring tracker fields without creating an item.
Restore a completed item to open state and automatically sync the next round of reminders.
Update an existing recurring tracker item. Omitted fields reuse current stored values.
Parameter descriptions are largely absent. Of 13 parameters in create_item/update_item, none have descriptions. LLMs cannot infer meaning from names alone, a 'status' parameter could mean many things without clarification.
Undocumented parameter interdependencies. event_time is only valid when all_day=false, reminder_offsets works as both string and array, event_time format is HH:MM, none of these constraints are documented in parameter descriptions. LLMs will guess wrong.
parse_import tool lacks clarity. Description does not specify the expected import block format, structure, or examples. What does 'pasted import block' mean? JSON? CSV? Custom format?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Example values appear in parameter descriptions (e.g., 'like -14,-7,0', 'YYYY-MM-DD', 'HH:MM'). These should be replaced with formal constraints: enums for known sets, regex patterns for formats, or min/max for ranges. LLMs latch onto example values and may reuse them literally.
No output schema documentation in tool definitions. While _serialize_event and _serialize_history functions exist in code, they are not exposed to the tool schema. LLMs cannot plan downstream tool calls without knowing what fields to expect.
reminder_offsets parameter accepts two distinct types (string and array) with oneOf schema. This creates ambiguity, LLMs may choose the wrong branch. A single normalized input type (always array or always string) would reduce confusion.
Error messages are basic (e.g., 'Invalid input') without recovery guidance. When validation fails, the LLM does not know what to try next. Errors should include the invalid value, the constraint violated, and next steps.