Ghostly MCP server has 7 tools with mixed quality. Tool naming follows verb_noun convention (ghostly_run_flow, ghostly_get_project_map), which is good. However, descriptions vary significantly in quality and completeness. ghostly_run_flow has a detailed description (180+ chars) with comprehensive parameter documentation, but other tools like ghostly_list_ghostly_projects and ghostly_get_run have minimal descriptions. Parameter schemas are present for ghostly_run_flow but visibility into other tools' schemas is limited from the provided source. No output schemas are documented. Error handling guidance is absent across all tools. The server lacks tool annotations (readOnlyHint/destructiveHint) despite having clear READ_ONLY vs WRITE risk classifications.

• Expand descriptions for ghostly_get_project_map, ghostly_analyze_component, ghostly_read_flow_docs, ghostly_list_ghostly_projects, and ghostly_get_run to 50-200 characters. Example: 'ghostly_get_project_map: Retrieves the project structure including components, flows, and dependencies. Call this first to understand available test scenarios.'
• Document input schemas for all 6 tools lacking them. Include parameter types (string, number, boolean, array), descriptions, and constraints (enums, min/max, patterns).
• Add output schemas to all tools. Example for ghostly_get_project_map: 'Returns {components: [{name, path, type}], flows: [{name, steps}], total: number}'.
• Add error handling guidance. Example: 'If component not found, call ghostly_get_project_map to list available components. If API timeout, retry with exponential backoff.'
• Implement tool annotations in MCP registration: mark ghostly_get_project_map, ghostly_analyze_component, ghostly_read_flow_docs, ghostly_list_ghostly_projects, ghostly_get_run with readOnlyHint=true; mark ghostly_run_flow and ghostly_submit_plan with destructiveHint=true.