Backlog MCP server has well-structured tool definitions with complete JSON schemas and consistent naming patterns. All 12 tools follow verb_noun convention (get_, add_, update_, delete_). Schemas are properly typed with descriptions for most parameters. However, descriptions are minimal (10-30 chars), lacking context about WHEN to use tools, dependencies, and recovery guidance. Output schemas are not documented. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Parameter descriptions lack format constraints (e.g., date format YYYY-MM-DD is mentioned but not enforced). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels.

• Expand tool descriptions to 50-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. E.g., 'Get all issues matching filters (keyword, status, assignee, date range). Use for bulk operations; for a single issue, call backlog_get_issue() instead. Returns paginated results (default 20 per page).'
• Document output schemas for all tools. Specify which fields are returned, their types, and which IDs/references can be chained to other tools. E.g., backlog_get_issues should document that it returns issue IDs usable in backlog_update_issue.
• Add tool annotations: mark all get_* tools with readOnlyHint=true; mark add_*, update_* with destructiveHint=false; mark delete_* with destructiveHint=true. This enables LLMs to reason about safety.
• Implement error handling with recovery guidance. For delete operations, return 'Issue deleted successfully' or 'Issue not found (ID: X). Available issues: [list]. Did you mean one of these?' For validation errors, return 'Invalid status ID: 5. Valid IDs: 1 (Open), 2 (In Progress), 3 (Closed).'
• Add parameter constraints: use enums for statusId, priorityId, issueTypeId (if known); add minLength/maxLength for string params; document date format as ISO 8601 (YYYY-MM-DD) with regex pattern validation.