Ghost MCP has 22 tools with clear naming (verb_noun pattern) and risk classifications. However, critical gaps undermine quality: input schemas are visible but many lack parameter descriptions; tool descriptions exist but are often terse (10-50 chars, below the 50-200 char baseline for LLM optimization); no documented output schemas; no error handling guidance; no parameter constraints (enums, ranges, formats). The server conflates two distinct domains (Cloud workflows + Tauri desktop automation) without clear separation. STDIO transport caps protocol readiness at 50, further limiting production viability.

• Add input schemas (JSON Schema with type, description, required, enum/pattern constraints) to all 17 ghost.* tools. Currently inferred from Rust code, not visible in MCP registration.
• Expand tool descriptions to 80-150 chars with explicit WHAT/WHEN/WHY. E.g. 'ghost.status' → 'Check Ghost desktop app status, trust pipeline state, and availability of macOS semantic/vision operations. Call this first to verify the agent can access Zones and execute plans.'
• Document output schemas for all tools. Include field names, types, and which fields are safe to chain to downstream tools (e.g. does get_workflow return step_ids that execute_plan accepts?).
• Add error handling guidance to irreversible tools (start_run, execute_approved_plan, execute_approved_routine). E.g. 'If execution fails, call get_run to check halt_reason. If halt_reason is "policy_violation", the plan cannot be retried, ask the user to modify the plan and request approval again.'
• Add parameter constraints: enums for zone_id/workflow_id (list available options in error messages), ranges for limit (1-100), patterns for IDs. This prevents LLM hallucination and enables self-correction.