WatchDock MCP server has 8 tools with consistent naming (verb_noun pattern) and descriptions present for all tools. Tool annotations are properly declared (read_only, destructive, idempotent hints). However, parameter descriptions are minimal or absent for most tools. Input schemas are present but sparse: most tools accept 0-2 parameters with minimal constraint documentation. Output schemas are not explicitly documented in the visible code. Error handling and recovery guidance are not evident. The server follows good naming conventions and includes tool annotations (a current spec pattern), but lacks the depth of parameter documentation and output schema clarity expected for production-grade tools.

• Add parameter descriptions with format constraints: file_path should specify 'absolute or relative path to a file within configured watched roots' and whether symlinks are resolved.
• Document the AgentResponse schema explicitly. Include sample output showing success/error structure, required fields (e.g., action_id, status, message), and field types.
• Add enum constraint to list_actions 'statuses' parameter with valid values (e.g., 'pending', 'failed', 'approved', 'rejected'). Document pagination: does limit=50 return 50 items or fewer? Is there a next_cursor or total_count?
• Add error handling guidance to tool descriptions: 'Returns error if file_path is outside watched roots or does not exist. Retry with a valid path inside a configured watched root.'
• Expand tool descriptions with WHEN/WHY context: 'Use analyze_file for a dry-run to preview changes without queuing. Use queue_file to queue the file for human review in WatchDock.'