Four tools with complete input schemas and descriptions, but significant gaps in output documentation, error handling, and parameter clarity. All tools follow verb_noun naming (caprover_*). Descriptions are present (avg ~80 chars) but lack actionable context for LLM selection. No output schemas documented. Parameters lack constraints (enums, ranges, format specs). Error responses are generic success/failure dicts with no recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being WRITE operations.

• Document output schemas for all tools. Example: caprover_create_app should return {success: bool, app_name: string, app_id: string, created_at: ISO8601, message: string}. Include app_id so downstream tools can reference the created app.
• Add tool annotations: mark all four tools with destructiveHint=true (they modify state). Mark caprover_create_app and deploy_* with idempotentHint=false (retrying creates duplicates). This signals to LLMs which tools are safe to retry.
• Enhance error responses with recovery guidance. Instead of {success: false, error: 'Connection refused'}, return {success: false, error_code: 'connection_failed', error_message: 'Failed to connect to CapRover dashboard', recovery_hint: 'Verify CAPROVER_URL is correct and the dashboard is reachable', retryable: true}.
• Add parameter constraints: app_name (pattern: ^[a-z0-9-]{1,50}$), image_name (pattern: ^[a-z0-9-./:]+(:[a-z0-9-./]+)?$), instance_count (minimum: 1, maximum: 100), port_mapping (pattern: ^\d+:\d+$).
• Expand tool descriptions with WHEN-to-use guidance. Example: 'Create a new CapRover app without deploying. Use this to set up the app structure first, then call caprover_deploy_app_from_image to deploy a container. If you want to deploy in one step, use caprover_deploy_app_from_image or caprover_deploy_oneclick_app instead.'

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

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