Four tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (search, run, list, call), which is good. However, descriptions are minimal (10-40 chars), parameter descriptions are sparse or missing, and output schemas are not documented. No error handling guidance, no pagination support, and no indication of idempotency or destructiveness beyond the Risk field. The server exposes command execution (omarchy_run, omarchy_shell_call) with minimal input validation hints.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'omarchy_search_commands: Search the Omarchy command registry by name or keyword. Returns matching command names, routes, and brief descriptions. Use this to discover available commands before calling omarchy_run.'
• Document output schemas for all tools. Specify the structure of search results (e.g., array of {name, route, description}), command execution results (e.g., {success, output, error}), and shell targets (e.g., array of {target_name, available_methods}).
• Add parameter descriptions for 'args' and 'method'. Explain expected format (JSON object vs array), constraints (max size, allowed keys), and provide a brief example. E.g., 'args: JSON object with command-specific parameters. Example: {"key": "value"}.'
• Add error handling guidance. Document common failure modes (command not found, invalid args, timeout) and recovery steps. E.g., 'If command not found, call omarchy_search_commands to discover available commands.'
• Consider adding tool annotations (readOnlyHint, destructiveHint, idempotentHint) to clarify which tools are safe to retry and which modify state. This aligns with current MCP spec patterns.