The server presents 15 tools with mixed quality. All tools start with appropriate action verbs (get_*, greet_*), and all have descriptions of reasonable length (average ~180 chars). However, the schemas are severely underdeveloped: most tools accept zero or one parameter with minimal constraints. Input schemas lack enums, ranges, and validation rules. Output schemas are not documented at all, the server provides no guidance on what fields the LLM should expect. Tool descriptions are functional but generic, lacking guidance on when to use each tool vs. similar ones (e.g., get_channel_info vs get_channel_status) or how results chain to downstream tools. Parameters like 'last_n_lines' (tool 11) and 'channel_id' (tools 9-10) lack min/max constraints. No error handling patterns visible. Tool composition is reasonable (single responsibility per tool), but many read-only tools return domain-specific data without documented output structure, forcing LLMs to infer field names.

• Document the output schema for every tool. For each, specify the JSON structure, field names, types, and an example. E.g., 'get_storm_channels returns {channels: [{id: number, name: string, logo: string, status: -1|0|1|2|3}, ...], total: number}'.
• Add min/max constraints to numeric parameters. E.g., 'last_n_lines: integer, minimum 1, maximum 1000' and 'channel_id: integer, minimum 0, maximum <max_channels>'. State these in both JSON Schema and parameter descriptions.
• Clarify overlapping tools with explicit usage guidance. E.g., 'Use get_channel_status to check if a channel is Ready (2) or Storming (3); use get_channel_info for full metadata (name, logo, etc.).'
• Add error handling context to parameter descriptions: 'If channel_id is out of range, returns error 404 with available channel indices. Call get_active_channels to discover valid indices.'
• Remove or properly redact API keys from get_ai_provider_keys output. If the tool must expose keys, gate it behind a permission check and log all accesses. Better: create a separate tool for checking key status (without exposing the key itself) and store actual keys server-side only.
• Add pagination support to tools that return lists (get_available_profiles, get_assigned_profiles). Include limit, offset/cursor, and total_count in the response schema.
• For tools that accept no parameters (e.g., get_storm_status), make it explicit in the schema: 'input: {}' with a note like 'This tool requires no parameters. Call it to check whether a storm is currently running.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry