The Todo MCP server defines 15 tools with consistent verb-noun naming (get_, list_, create_, update_, delete_). All tools have descriptions and input schemas are present with type definitions. However, there are significant gaps: (1) descriptions are generic and lack actionable context for LLM selection, they don't explain WHEN to use each tool or what distinguishes similarly-named operations; (2) parameter descriptions are minimal ('The workspace ID', 'The list ID') and lack guidance on format, constraints, or dependencies; (3) output schemas are not documented, LLMs cannot predict what fields to expect from responses, hampering chaining and context management; (4) no error handling guidance is visible, tools lack recovery paths for common failures; (5) no indication of idempotency, retry safety, or side-effect scope despite 4 destructive tools; (6) parameter ranges and formats are undocumented (e.g., priority is an integer with no bounds specified). The tool set is well-scoped (each does one thing) and uses clear names, but the definitions lack the LLM-optimized depth needed for robust agent planning.

• Document output schemas for all tools. For get_workspace, specify: {workspace_id: string, name: string, created_at: ISO8601, owner_id: string, item_count: integer}. For list_workspaces, specify: {workspaces: [{id, name, created_at, owner_id}], total: integer, hasMore: boolean}.
• Expand parameter descriptions to include format and constraints. E.g., 'workspace_id: The workspace ID (UUID v4 format)' and 'priority: Priority level (integer 1-5, where 1=low, 5=critical)'.
• Add pagination to list_* tools. Introduce limit (default 20, max 100) and offset (default 0) parameters. Return total count and hasMore flag to guide LLM pagination logic.
• Rewrite descriptions to guide LLM selection and explain when to use each tool. E.g., 'Create a new workspace: Use this to initialize a new container for lists and items. Returns workspace_id needed for all list operations. User must be authenticated.'
• For destructive tools, add confirmation_required field or document a confirm_delete pattern. E.g., 'delete_workspace requires confirmation via a separate confirm_delete_workspace call with a confirmation token returned from a dry-run.'
• Add idempotency and retry safety documentation to update and create tools. E.g., 'create_todo_item is idempotent: calling twice with the same parameters and idempotency_key returns the same item ID without duplication.'
• Document common error scenarios and recovery guidance for each tool. E.g., 'delete_workspace fails with 404 if workspace not found. Try list_workspaces to verify the ID. Returns 403 if user lacks delete permission, ask the user to check ownership.'