Keydler has 14 tools with schemas and descriptions present, but quality is inconsistent. Most tool descriptions are extremely terse (4-20 chars), violating the 10-1024 char baseline and failing to explain WHEN/WHY to use each tool. Many parameters lack descriptions entirely (e.g., resume_task, read_task_detail, what_changed have empty input objects). Write operations expose mutation_id and based_on_version as required params, which are implementation details that should be abstracted. No output schemas documented. Error handling exists but is generic. Tool naming is verb-first (good), but composition is unclear, ask_human, request_approval, and reject_approach overlap semantically without clear distinction.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and what it returns. Example: 'Resume a paused task. Call this after the human approves a pending action. Returns the updated task state and next required step.'
• Document output schemas for all tools. Specify returned fields (task_id, version, step_id, status, etc.), types, and which fields are needed for downstream tool calls.
• Abstract mutation_id and based_on_version: make them optional or server-managed. If required for idempotency, move them to a separate internal API layer. Expose only user-facing parameters (title, action, decision, etc.).
• Add parameter descriptions to all tools with empty input schemas. Even if a tool takes no user-facing params, document what it operates on (e.g., 'Operates on the currently active task in browser storage').
• Clarify the interaction model: document when ask_human blocks vs. queues, when request_approval requires explicit human response vs. auto-approval, and when reject_approach rolls back state vs. logs a decision.