MCP Gateway exposes 17 tools across server management and aggregation. Most tools lack proper input schemas, only 3 of 17 have visible schema definitions in the source. Descriptions are present but generic (10-50 chars typical). Critical gaps: no parameter type definitions for most tools, no output schema documentation, no error handling guidance, and missing descriptions for aggregation tools (handle_* functions). The server acts as a gateway/orchestrator rather than a domain-specific tool provider, which limits applicability of standard tool patterns. Tools like 'handle_list_tools' and 'handle_call_tool' are internal MCP handlers, not user-facing tools, and should not be scored as primary tools.

• Add explicit JSON Schema definitions for all 17 tools. At minimum: type, description, and enum constraints for status/branch/command parameters. Example: status parameter should be enum: ['running', 'stopped', 'error'].
• Expand tool descriptions to 100-200 characters. Include WHEN to use (e.g., 'Call list_servers first to discover available servers before calling create_server'), WHAT it does, and WHAT it returns. Current descriptions are too terse for LLM selection.
• Document output schemas for all tools. Specify which fields are returned (e.g., list_servers returns [{id, name, status, tools_count, ...}]) so LLMs know what data is available for downstream calls.
• Separate internal MCP protocol handlers from user-facing tools. Move handle_list_tools, handle_call_tool, handle_list_resources, handle_read_resource, handle_list_prompts, handle_get_prompt into a separate internal handler registry. Expose only the 11 server management and aggregation tools.
• Add error handling guidance to destructive/state-changing tools. E.g., delete_server: 'Returns 404 if server not found. Returns 409 if server is running, call stop_server first. Deletion is irreversible.' This guides LLM recovery.