Five tools with basic descriptions and minimal input schemas. All tools are READ_ONLY and well-intentioned, but descriptions are generic (avg 80 chars, well below 194-char baseline), parameters lack type constraints (no enums, ranges, or validation hints), and output schemas are completely undocumented. No error handling guidance, no parameter relationships documented, and no composition hints for chaining tools. Tool names follow verb_noun pattern (logs-tail, status-get, etc.) but descriptions do not explain WHEN to use each tool or what distinguishes them from each other.

• Document output schemas for all tools. Example for logs-tail: {"lines": [{"timestamp": "2024-01-15T10:30:00Z", "level": "INFO|WARN|ERROR", "message": "..."}], "total_available": 1000}. This enables LLMs to extract and chain data.
• Add enum constraints to free-form parameters. For status-get, define section as enum: ["process", "memory", "network", "disk"]. For metrics-legacy-get, define metric as enum: ["flowcount", "conncount", "packetcount"]. This prevents hallucinated values.
• Expand descriptions to 150 - 250 chars and include WHEN to use each tool. Example: 'Retrieve the last N lines from loxilb logs. Use this to diagnose recent errors or trace request flow. Returns structured log entries with timestamp, level, and message. For aggregated metrics, use metrics-legacy-get instead.'
• Add min/max bounds to numeric parameters. For logs-tail, specify: 'lines: integer, 1 - 1000 (default 10). Limits memory usage and prevents runaway queries.'
• Document parameter relationships and error cases. Example for status-get: 'section: string, one of [process, memory, network, disk]. If invalid, returns 400 with available sections. Call this first to discover valid sections before filtering metrics.'