OmniRoute exposes 19 tools with severe definition gaps. Tool #3 (get-api-cli-tools-runtime-tool-id-) has a single parameter 'toolId' with type and description, but the remaining 18 tools accept no documented parameters despite being REST endpoints that likely require IDs, bodies, or filters. Descriptions are generic and under 50 chars on average, providing minimal LLM guidance on when to use each tool. Tool names follow REST conventions (get-/post-/put-/delete-) but lack verb_noun clarity, 'get-api-cli-tools-backups' is unclear whether it lists backups or retrieves a specific backup. No output schemas are documented. No error handling guidance. No parameter constraints or enums. This server is not production-ready for agent use.

• Add explicit input schemas to all 18 tools with empty {} schemas. For GET tools, document required path parameters (e.g., toolId). For POST/PUT tools, document the 'body' parameter with a schema reference or inline object definition.
• Expand tool descriptions from 20-30 chars to 80-150 chars. Include: (1) what the tool does, (2) when to use it vs similar tools, (3) what it returns. Example: 'List all CLI tool backups with timestamps and sizes. Use this to find a specific backup before restoring. Returns array of {id, created_at, size_bytes}.'
• Document output schemas for all tools. Specify the structure of successful responses (e.g., {backups: [{id: string, created_at: string, size_bytes: number}]}). Include pagination fields (total, next_cursor) for list endpoints.
• Rename tools from REST paths to verb_noun patterns: get-api-cli-tools-backups → list_cli_backups, post-api-cli-tools-backups → create_cli_backup, delete-api-cli-tools-antigravity-mitm → reset_antigravity_mitm_settings. This enables LLMs to infer intent from the name alone.
• Add error handling guidance to each tool description. Example: 'Returns 404 if toolId not found, try list_cli_tools() to find valid IDs. Returns 409 if backup is in use, wait and retry. Returns 500 on server error, retryable after 30s.'