Server has 11 tools with explicit schemas and descriptions visible in source. However, critical gaps limit production readiness: (1) Most descriptions are generic and under 100 chars, lacking WHEN/WHY context for LLM selection. (2) Parameter descriptions are minimal or absent, e.g., 'device_udid' has no format guidance. (3) No output schemas documented, LLMs cannot predict response structure for chaining. (4) No error handling guidance, tools return raw failures without recovery hints. (5) Several tools conflate concerns (watch_builds, get_live_build_errors) and lack clear differentiation. (6) No pagination support despite tools returning lists. Naming is generally good (verb_noun pattern), but descriptions and schemas fall short of production baseline (94% of A+ tools have full param descriptions; this server ~30%).

• Document output schemas for all tools. Example: get_build_errors should return {errors: [{file, line, message, severity}], total_count: int}. This enables LLMs to chain tools and extract the right fields.
• Expand parameter descriptions to 50-100 chars with format/constraint hints. E.g., 'device_udid: UUID of the connected device (e.g., 00008020-001234567890ABCD). Call get_connected_devices to list available UDIDs.'
• Clarify tool selection by adding WHEN/WHY to descriptions. E.g., 'get_build_errors: Fetch errors from the last completed build. Use this for post-build analysis. For real-time monitoring, call watch_builds instead.'
• Add error recovery guidance. E.g., 'If device not found, call get_connected_devices to verify the device is connected and get its UDID.'
• Implement pagination: add limit (default 50, max 200) and offset/cursor to list_recent_projects, get_console_logs, get_device_logs. Return total_count so agents know if more results exist.

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

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