Five read-only tools with clear, concise descriptions (50-150 chars each). All tools have proper input schemas with typed parameters and descriptions. Naming follows verb_noun convention (overview, server_health, usage_summary, unused_tools, recent_audit). However, descriptions lack actionable context for LLM selection, they state WHAT but not WHEN or WHY to call each tool. No error handling guidance, no output schema documentation, and no indication of response structure. Parameters are minimal but well-typed. Tools are single-responsibility and composable. Missing: recovery guidance, output field documentation, and LLM-optimized descriptions that explain tool relationships and selection criteria.

• Document output schemas for all tools. For 'overview', specify: {servers_total: int, servers_enabled: int, tools_total: int, tools_enabled: int, clients_total: int, tool_groups_total: int}. For 'server_health', specify: [{server_name: string, status: 'up'|'down'|'unknown', latency_ms: int}]. This enables LLMs to extract and chain data.
• Enhance descriptions with WHEN/WHY context. E.g., 'overview' → 'Call this first to get a snapshot of the gateway's capacity and health. Use before server_health to understand scale, or before usage_summary to contextualize metrics.' This guides tool selection.
• Add error handling guidance to each tool. E.g., 'If the gateway is unreachable, server_health returns status=unknown for all servers. Retry after 30s or check gateway logs.' This tells LLMs what to do on failure.
• Constrain 'limit' parameters. Change description to: 'Maximum number of results to return (1 - 1000, default 20 for usage_summary, 50 for recent_audit). Larger limits may increase latency.' This prevents runaway queries.
• Document tool composition. Add a note to 'unused_tools': 'Combines data from overview (tool list) and usage_summary (call counts). Call overview first to see all tools, then unused_tools to identify candidates for disabling.' This clarifies dependencies.