TodoServer has basic tool definitions but significant quality gaps. All 4 tools have descriptions and schemas, but descriptions are minimal (10-50 chars, well below the 194-char baseline). Parameters lack depth: 'task' and 'city' have minimal context; 'task_number' lacks range constraints. No output schemas documented. Error handling is present but generic ('Invalid task number' provides no recovery guidance). The get_weather tool is out-of-scope (weather forecasting unrelated to todo management) and uses fake data, signaling incomplete implementation. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Schemas are present but minimal, no enums, ranges, or format constraints.

• Expand all descriptions to 100-200 chars. Example: 'add_todo' → 'Add a new task to your to-do list. Returns confirmation with updated task count. Use this when the user wants to create a new task.'
• Add parameter constraints: task_number should document 'integer between 1 and the current list length (inclusive)'. Add validation error: 'Invalid task number: got X, must be 1 - N where N is the list size.'
• Document output schemas for all tools. E.g. add_todo returns {message: string, task_count: integer}. This enables LLMs to extract and chain data.
• Remove get_weather or replace with a real weather API. If kept, add city validation (enum of supported cities or regex pattern) and document the data source.
• Add tool annotations: mark remove_todo with destructiveHint=true, list_todos with readOnlyHint=true, add_todo with idempotentHint=true (safe to retry).