Loading ToolBench
Todoist MCP Server Extended, made to be efficient to use for an LLM's like Claude.
This server has well-structured tool definitions with comprehensive parameter schemas and clear descriptions. All three tools are explicitly registered with proper JSON Schema input definitions. However, there are significant gaps in output schema documentation, error handling guidance, and composition clarity. The tool designs lack recovery paths for common failure modes and do not provide sufficient guidance to LLMs on which tool to choose when multiple could apply. Parameter descriptions are generally good (70-90 chars on average), but several lack actionable constraints (e.g., 'filter' parameter accepts arbitrary natural language with no examples or guidance on valid syntax). The batch operation overlap between tools (todoist_create_task and todoist_update_task both support single and batch modes) creates ambiguity that could confuse LLMs during tool selection. Output schemas are not documented in the code, forcing LLMs to infer response structure.
Create one or more tasks in Todoist with full parameter support
Get a list of tasks from Todoist with various filters - handles both single and batch retrieval
Update one or more tasks in Todoist with full parameter support
Output schemas completely undocumented across all tools. LLMs cannot infer response structure, cannot plan downstream tool calls, and cannot extract necessary fields for chaining (e.g., task_id returned by create_task needed by update_task).
Parameter 'filter' in todoist_get_tasks and 'due_string' in todoist_create_task accept natural language with no formal syntax specification, grammar, or error guidance. LLMs may pass invalid syntax (e.g., 'priority high' instead of 'priority 1') with no recovery hint.
todoist_create_task and todoist_update_task both accept single-task and batch parameters at the root level (dual schemas: 'content' + batch 'tasks' array). This creates two valid call signatures for the same intent and forces LLMs to reason about which parameter set to use. Should split into separate tools (create_task and batch_create_tasks) or clarify which mode is preferred.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling or recovery guidance. Descriptions do not state what errors are possible (API rate limits, invalid project_id, task not found, etc.) or what LLMs should do next. Missing pattern:recovery-guide.
todoist_update_task accepts optional 'task_id' and 'task_name', with ambiguous matching semantics for task_name (substring? case-sensitive?). LLMs may pass both when unsure, or fail silently if task_name matches multiple tasks. Violates pattern:tool-chain (output of prior tool should feed directly into next without fuzzy matching).
todoist_get_tasks documents 'limit' with default=10 but does not state maximum result count or pagination mechanism. If total tasks exceed limit, how do LLMs fetch the next page? No next_cursor or offset parameter visible.
Parameters 'assignee_id', 'project_id', 'section_id', 'parent_id' require opaque system IDs but accept no human-friendly alternatives (names, email addresses). Forcing users to know or look up internal IDs creates friction. Pattern:natural-identifiers suggests accepting display names or emails and resolving inside the tool.
Tool descriptions do not state which operations modify state. LLMs need to know which tools are safe to retry (idempotent) and which risk duplicate side effects. todoist_create_task and todoist_update_task should explicitly state 'This modifies state' or 'Creates/updates task in Todoist' for clarity.