Server has 30 well-structured tools with consistent naming (verb_noun pattern: getTasks, createTask, etc.) and complete JSON schemas. All tools have descriptions and typed parameters with examples. However, descriptions are often generic (e.g., 'Getting a list of tasks' vs. actionable guidance on when to use), parameter descriptions lack constraint details (e.g., no mention of limit bounds 1-50), and output schemas are not documented. Error handling and recovery guidance are absent. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Pagination support exists (cursor, limit) but lacks documentation of total counts or next_cursor semantics.

• Document output schemas for all tools. For getTasks, specify: returns array of {id, content, description, projectId, sectionId, labels[], priority, dueDate, completed, createdAt}. For createTask, specify: returns {id, content, projectId, ...}. This enables LLMs to chain tools and extract IDs for follow-up calls.
• Expand parameter descriptions with constraint details and examples. E.g., 'limit (1-50, default 30): Maximum tasks per page. Use 50 for bulk operations, 10-20 for interactive chat.' For dueString: 'Natural language date (e.g., "tomorrow", "next Monday", "in 3 days", "2024-12-25"). Language set by dueLang parameter.'
• Add tool annotations to schema. Mark deleteTask, deleteProject, deleteLabel, deleteSection, deleteComment with destructiveHint=true. Mark getTasks, getTask, getProjects, etc. with readOnlyHint=true. Mark completeTask, uncompleteTask with idempotentHint=true. This enables MCP clients to apply safety policies.
• Enhance descriptions with actionable guidance. E.g., getTasks: 'Retrieve tasks with optional filtering. Call this first to discover available tasks, then use getTask for details. Supports pagination via cursor and limit (max 50). Returns task IDs needed for createTaskComment, updateTask, deleteTask.' For createTask: 'Create a new task. Returns task_id for use in moveTask, createTaskComment, completeTask. Supports natural language due dates via dueString (e.g., "tomorrow at 3pm").'
• Add error handling guidance to tool descriptions. E.g., createTask: 'Returns error if projectId is invalid (call getProjects to list valid IDs) or if priority is outside 1-4. If dueString is ambiguous, Todoist API may interpret differently, use dueDate (YYYY-MM-DD) for precision.' For deleteTask: 'Permanently deletes task. No undo. Confirm with user before calling.'