Cursor Buddy MCP shows mixed quality. All 6 tools have explicit registrations with descriptions and schema definitions visible in cmd/buddy-mcp/main.go. However, there are significant gaps: (1) Parameter descriptions are often generic or missing full context, e.g., 'validate_query' in buddy_get_database_info lacks guidance on what constitutes a valid query or what happens if validation fails. (2) Tool descriptions lack WHEN-to-use guidance and error recovery hints. (3) Output schemas are completely undocumented, no indication of what fields are returned or their types, violating the 'Document the output schema' requirement. (4) No actionable error messages or recovery guidance anywhere. (5) Parameter dependencies and constraints are underspecified (e.g., buddy_history 'add' action requires 'description', 'reasoning', and 'changes' but this is buried in descriptions, not enforced in schema). (6) The 'buddy_manage_todos' tool mixes list/read and update/write in one tool, violating single-responsibility. (7) Input schemas lack minLength, maxLength, pattern, and enum constraints that would prevent invalid LLM input. Overall, the server demonstrates framework competence (proper mark3labs/mcp-go usage) but lacks LLM-optimization and production hardening.

• Document the output schema for every tool. E.g., for buddy_get_rules, specify: 'Returns {rules: [{id, category, priority, text, rationale}], total_count: int}'. This enables LLMs to extract and chain results.
• Split buddy_manage_todos into three tools: buddy_list_todos (query only), buddy_update_todo_status (stateful), buddy_report_todo_progress (stateful). Each is single-responsibility and clearly idempotent or not.
• Enhance parameter descriptions with constraint context. For priority enum, add: 'critical: security, correctness, or data loss; recommended: code quality, readability; optional: style, conventions'. For validate_query, add: 'SQL query is validated against the current schema. Returns validation errors or success.'
• Add error handling guidance to each tool description. E.g., 'Returns 404 if query matches no knowledge. Suggest: Try a broader search term or call buddy_list_knowledge_categories to see available topics.'
• Explicitly document parameter dependencies in tool descriptions. E.g., 'buddy_history: If action=add, required params: feature, description, reasoning, changes. If action=search, required: query. If action=list, optional: feature, limit.' Use a 'Parameter Constraints' subsection.
• Add side-effect declarations. E.g., 'buddy_manage_todos update action: side effect, marks todo complete. This operation is idempotent (retry-safe).' or 'buddy_history add: side effect, appends to implementation history. Non-idempotent; retries create duplicates.'
• Add numeric bounds and constraints to parameters. E.g., limit in buddy_history: min=1, max=100, default=10. max_age_days in buddy_backup: min=1, max=365.