Three tools with complete input schemas and descriptions. Tool names follow verb_noun pattern (deploy_html, get_feedback, list_deployments). Descriptions are detailed (100-300 chars) and explain WHAT, WHEN, and prerequisites. All parameters have types and descriptions. However, output schemas are not documented in the source, LLMs cannot see what fields to expect from responses. Error handling is present (cliErrorResult, cliExceptionResult) but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is sound: each tool has one responsibility, and deploy_html accepts human-friendly identifiers (path, room slug, display name).

• Document output schemas for all three tools. Example for deploy_html: 'Returns {share_url: string, room_slug: string, expires_at: ISO8601, display_name: string}'. This enables agents to chain calls and extract the right fields.
• Enhance error messages with recovery guidance. In cliErrorResult, detect 'not signed in' and append AUTH_HINT (already present in code). For other errors, categorize as retryable (network, timeout) vs user-fixable (invalid plan, missing parameter) vs fatal (API error).
• Add tool annotations: registerTool('deploy_html', {...}, ..., {destructiveHint: true}); registerTool('get_feedback', {...}, ..., {readOnlyHint: true}); registerTool('list_deployments', {...}, ..., {readOnlyHint: true}).
• Clarify plan-based constraints in deploy_html description: 'expires: Free plan allows 24h and 7d only. Pro+ plans allow 30d, 90d, and never. Private rooms (private: true) are exempt from plan limits.'
• Document list_deployments pagination: 'Returns up to `limit` rooms (default 20, max 100). If more rooms exist, include a next_cursor field in the response to fetch the next batch.' Add a 'cursor' parameter to support iteration.