13 tools with complete input schemas and descriptions, but quality is inconsistent. Naming follows verb_noun pattern (plan, analyze-structure, publish-direct) which is good. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameters are typed but lack constraints (enums, ranges, patterns). No output schemas documented. Error handling is absent, tools provide no recovery guidance. Many tools accept file paths and config parameters but lack validation rules or format specifications. The server is STDIO-only, which is a hard transport limitation.

• Add output schemas to every tool. Document the JSON structure returned, including field names, types, and whether results are paginated. Example: 'Returns {status: string, plan: {sources: [{id, name, status}], total_count: number}}'.
• Expand descriptions to 100-200 chars. Include WHEN to call the tool, what it requires, and what it enables. Example: 'Analyze BMAD markdown structure to detect board mapping models. Call this first to understand document organization before planning sync. Returns estimated models and structure analysis.'
• Convert string parameters to enums where values are known. 'host' should be enum: ['codex', 'claude-code', 'gemini-cli', 'generic']. 'stage' in run-workflow should list valid stages. Enums are self-documenting and prevent hallucination.
• Add validation rules to descriptions. For 'config': 'Path to YAML config file (must exist, valid YAML syntax)'. For 'project_root': 'Absolute or relative path to project directory (must contain .bmad/ or similar marker)'. For numeric params: specify min/max.
• Implement error handling with recovery guidance. When config is missing, return 'Config file not found at <path>. Run install first to initialize project.' When API fails, return 'Miro API error: <reason>. Check token_env and api_base_url. Retry with publish-direct --changed_only to skip already-published sources.'