The server exposes 52 tools with inconsistent quality. Many tools have descriptions, but a significant portion have severely incomplete input schemas with empty properties objects (tools 2, 4, 9, 10, 12, 17, 18, 19, 20, 28, 41, 42, 43, 46, 50). This pattern indicates missing parameter definitions. Tool naming is generally verb-first and clear (getAlertConfig, createLocalBroker, etc.), which is positive. However, descriptions vary widely in quality, many are generic one-liners under 30 characters (e.g., 'Get alert configuration', 'Create a new local broker'). No output schemas are documented in any tool definition. Parameter descriptions are sparse; most parameters lack any guidance on expected format, range, or constraints. Error handling and recovery guidance are entirely absent from tool definitions. The server follows a consistent naming convention (verb_noun via camelCase), which helps LLM parsing, but the shallow definitions and missing schemas create high risk of misuse.

• Fill in all empty input schemas with actual parameter definitions. For each tool, enumerate the parameters it accepts, add 'type' (string, number, boolean, array, object), add 'description' (50-200 chars explaining purpose, constraints, and examples), and add 'enum' for parameters with known allowed values.
• Expand tool descriptions from generic one-liners to 50-200 character narratives. Include: what the tool does, when to call it (vs. similar tools), what it returns, and any side effects. Example: 'Get alert configuration for the NPA tenant. Returns alert thresholds, channels, and delivery settings. Use before updateAlertConfig to see current state.'
• Document output schemas for every tool. Specify the response structure as a JSON object with field names, types, and brief descriptions. Example for listPrivateApps: returns {total: number, apps: [{id: string, name: string, host: string, protocol: string}]}.
• Add parameter descriptions for all parameters lacking them. For enum-like parameters (e.g., resourceType, sortorder), list valid values and explain when each is appropriate.
• Implement error handling guidance in tool descriptions and error responses. For each tool, document expected error scenarios and what the agent should do (retry, ask user, call alternative tool). Example: 'If ID not found, return 'Resource not found. Try listLocalBrokers() to find the correct ID.'
• Add a confirmation or dry-run parameter to all destructive tools (delete*, replace*). Example: deleteLocalBroker should accept a 'confirm: boolean' parameter and return 'Dry-run: would delete broker ID 123 with 5 associated apps' if confirm is false.