Tido demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive parameter descriptions, and structured output. All 8 tools have descriptions and input schemas. However, output schemas are not explicitly documented in the visible code, parameter constraints lack formal enum declarations in some cases, and error handling guidance is minimal. Tool names are action-oriented (todo_write, todo_list, todo_update, todo_delete, todo_add_note, todo_get_notes, todo_diff, ping), and descriptions are detailed (avg ~150 chars). Parameters are well-described with format hints (e.g., 'unix ms 数字串 或 RFC3339 字符串'), but lack explicit type constraints in JSON Schema. Composition is strong, tools are single-responsibility and chainable (e.g., todo_write returns IDs that todo_update accepts).

• Add explicit JSON Schema output definitions to each tool. Document the structure of 'compact item', 'cursor', 'counts', and 'notes' objects so LLMs know what fields are available for chaining.
• Convert parameter constraints to formal enum declarations in JSON Schema. For 'status', 'priority', 'difficulty', 'view', 'sort', declare enum: ['value1', 'value2', ...] instead of relying on description text.
• Implement structured error responses with actionable guidance. E.g., return {error: 'Invalid status', got: 'archived', valid: ['pending', 'in_progress', 'completed', 'cancelled']} so LLMs can self-correct.
• Add a dry-run or confirmation mode to todo_delete. Support a 'confirm' parameter or a separate 'preview_delete' tool that shows what would be deleted without executing.
• Document mutually exclusive parameter groups in JSON Schema using oneOf or allOf constraints, not just description text. This prevents LLMs from passing conflicting parameters.