Bodhi MCP demonstrates solid definition quality with complete input schemas, output schemas, and tool annotations across all 6 tools. All tools have descriptions (avg 65 chars) and properly typed parameters. However, parameter descriptions are sparse or missing in several tools (bodhi_list, bodhi_diagnose, bodhi_get_knowledge_base_summary lack parameter docs), and descriptions could be more LLM-optimized per pattern:tool-description. Error handling guidance is absent, tools do not explain recovery paths when failures occur. Tool naming follows verb_noun convention (route, search, list, read, diagnose) which is strong. Output schemas are well-structured with required fields and proper typing. No security issues detected (read-only operations, no secrets in params).

• Add parameter descriptions to bodhi_list (domain: 'Filter by knowledge domain (e.g., engineering, product, operations)', complexity: 'Filter by playbook complexity level', limit: 'Max results to return (default: 50, max: 500)'). Apply to bodhi_diagnose and bodhi_get_knowledge_base_summary.
• Expand tool descriptions to 100-200 chars following pattern:tool-description. Example: bodhi_route → 'Find the best playbook for a given task by matching against routing rules. Use this when you need to recommend a specific playbook to the user. Returns confidence score and alternatives.'
• Add recovery guidance to descriptions. E.g., bodhi_read: 'If playbook not found, try bodhi_search() to locate it by keyword or domain.'
• Rename bodhi_get_knowledge_base_summary to bodhi_summarize_knowledge_base for consistency with verb_noun naming and clarity.
• Document pagination defaults and limits in bodhi_search and bodhi_list descriptions. E.g., 'Returns up to 50 results by default; use limit parameter to adjust (max 500). Use offset for pagination.'

Inferred effective spec: 2025-06-18+.

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