Two tools with minimal input schemas (both empty objects) and descriptions that are honest but lack LLM-optimized structure. connect_telescope has a detailed, security-conscious description (195 chars) explaining the semantic difference between 'ok' and 'connected', which is excellent for preventing misuse. get_status is similarly thorough (156 chars). However, neither tool has parameters to describe, and the descriptions, while accurate, do not follow the 50-200 char LLM-optimized baseline. No output schemas are documented. No error handling guidance is provided. The codebase shows strong engineering (separation of concerns, error catching, provenance logging) but the MCP tool definitions themselves are sparse.

• Document output schemas for both tools. For connect_telescope, specify: {ok: boolean, connected: boolean, error?: string, error_number?: number}. For get_status, list all fields returned (e.g., connection_state, pointing_ra, pointing_dec, tracking_state, etc.) with types.
• Expand tool descriptions to 100-150 chars and include WHEN to call each. Example: 'connect_telescope: Establish connection to the Seestar S50 telescope via Alpaca. Call this before any observation. Returns ok=true only if connection succeeded; connected field indicates current state.'
• Add error handling guidance to descriptions. Example: 'If ok=false, check network connectivity to seestar_alp (:5555) and retry. If error_number is present, consult Alpaca error codes.'
• Implement a confirmation pattern for connect_telescope. Add a dry_run parameter (boolean, default false) so agents can preview the action before committing, or require explicit user approval via Multi Round-Trip Requests (result 'input_required').
• Document dependencies between tools. Clarify whether get_status requires a prior connect_telescope call or if it works independently. Add this to both descriptions.