Server has 6 well-defined tools with explicit schemas and descriptions. All tools are registered via mcp-go with proper parameter types and descriptions. Naming follows verb_noun convention (start, stop, list, output, send, status). Descriptions are present and actionable (avg ~80 chars). However, output schemas are not documented, callers cannot see what fields to expect from responses. Error handling returns error strings but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameter descriptions are good but some lack format/constraint details (e.g., 'tail' and 'maxBytes' in output tool lack min/max bounds).

• Document output schemas for all tools. For start(): return {id, name, pid}. For list(): return [{id, name, pid, state, uptime}]. For output(): return {stdout, stderr, uptime, truncated}. For status(): return {id, name, pid, state, uptime, exitCode}. For stop(): return {id, exitCode, uptime}.
• Add tool annotations via mcp.WithReadOnlyHint() for list, output, status; mcp.WithDestructiveHint() for stop; mcp.WithIdempotentHint() for start (if idempotent by design). This signals to clients which tools are safe to retry.
• Add min/max bounds to numeric parameters. For output(): tail should be 0 - 10000 (lines), maxBytes should be 0 - 10485760 (10 MB). Document in parameter descriptions: 'tail: number of lines to return (0 = all, max 10000).'
• Enhance error messages with recovery guidance. Instead of 'Process not found', return 'Process not found. Call list() to see available processes.' For invalid IDs, suggest alternatives if available.
• Improve list() description to explain use case and output structure: 'List all managed processes with their current state. Returns id, name, pid, state, and uptime. Call this first to discover available processes before calling status() or output().' (currently 34 chars, should be 150 - 200).