The Todoist MCP server provides 47 tools with consistent naming conventions and documented schemas. Strengths include verb-based tool names (add-, complete-, find-, update-), type definitions for parameters, and a comprehensive toolkit covering task, project, section, comment, reminder, label, and filter management. However, there are significant gaps: (1) parameter descriptions are minimal or missing for many tools, most array-type parameters use generic descriptions like 'Array of tasks to create' without specifying the required structure of each array element; (2) output schemas are not visible in the provided source code, making it impossible to verify whether responses include necessary chaining IDs and are properly shaped for downstream tool use; (3) error handling and recovery guidance are not evident in tool descriptions; (4) several high-risk tools (delete-object, project-management, fetch) lack detailed parameter constraints and safety mechanisms. Tool names follow verb_noun patterns well (add-tasks, complete-tasks, find-tasks), but descriptions are uniformly brief (10-50 chars) and lack context for when to use each tool or what distinguishes it from similar tools. The 'fetch' tool (tool 47) is particularly concerning, it exposes raw API access, which violates the principle of abstraction and invites hallucinated endpoints. Per-tool averages: naming 78/100, description 35/100, schema 55/100, overall tool average 56/100, rounded to 62 after adjusting for the breadth and practical utility of the toolkit.

• Expand all parameter descriptions to include structure details. For array-type params (tasks, projects, comments), explicitly list required and optional fields with types and constraints. Example: 'tasks: Array of task objects. Each object requires: {content: string, project_id?: string, due_date?: string (ISO 8601)}.'
• Document output schemas for every tool. Include field names, types, and whether results are paginated. Example: 'Returns {tasks: Task[], total: number, next_cursor?: string}. Task schema: {id: string, content: string, due_date: string|null, completed: boolean, ...}.'
• Add safety mechanisms to destructive tools. Implement a dry-run or confirmation pattern: 'Call delete_object with dry_run=true to preview what will be deleted. Omit dry_run or pass dry_run=false to execute. This operation is permanent.'
• Eliminate the 'fetch' tool or severely restrict it. Replace raw API access with discrete tools for each endpoint. This prevents hallucinated calls and ensures type safety.
• Expand tool descriptions to 100-150 characters. Include: (1) what the tool does; (2) when to use it instead of similar tools; (3) side effects; (4) what it returns. Example: 'Reschedule one or more tasks to different due dates. Use when bulk-moving tasks (e.g., postponing all overdue items). Returns updated task list with new due dates applied.'
• Add enum constraints to type/operation parameters. For delete-object, document: 'type must be one of: task, project, section, comment, label, filter, reminder, location_reminder.' For project-management, specify: 'operations must be one of: archive, unarchive, delete, share.' Include these in the schema as enums, not just descriptions.