This Kotlin MCP Jira server has 8 tools with complete input schemas and descriptions, but quality is inconsistent. All tools have basic parameter documentation, yet descriptions are generic and lack depth about when/why to use each tool. Parameter schemas are well-formed with proper types, but no enums constrain Jira-specific values (e.g., transition IDs, status names). Error handling and output schemas are not visible in the provided code. Tools follow a clear verb_noun naming pattern (get*, add*, update*, move*), but lack discovery guidance and chaining context. The server shows competent SDK usage but falls short of production-grade agent tool quality, descriptions are utilitarian rather than LLM-optimized, and critical context about dependencies and side effects is missing.

• Add detailed output schemas for every tool, documenting field names, types, and sample values. This unblocks agent reasoning and eliminates guesswork.
• Expand parameter descriptions to 60-120 characters, including format constraints, valid value ranges, and examples. Example: 'The Jira board ID (numeric, e.g., 123). Use getCurrentSprint or list_boards to discover available boards.'
• Add enum constraints to Jira-specific fields. For transitionId, return available transitions as an enum from getIssueTransitions so moveIssueWithTransition can validate input.
• Explicitly document tool dependencies in descriptions. Example: 'Before calling moveIssueWithTransition, call getIssueTransitions to retrieve valid transitionId values for this issue.'
• Add error recovery guidance to each tool description. Example: 'If issue is not found, call search_issues() with keywords. If transition is invalid, call getIssueTransitions() to see allowed transitions.'
• Implement dry-run or confirmation patterns for write operations. Example: moveIssueWithTransition could accept a 'dryRun: bool' parameter or require confirmation via a separate confirm_transition tool.
• Add pagination/batching constraints to list and batch tools. Example: 'Accepts up to 100 issue IDs per call. For larger batches, paginate with multiple calls.'
• Include tool-selection hints in descriptions. Example for getIssueDetails vs getIssuesFromCurrentSprint: 'Use this to fetch a single issue by ID. For all issues in a sprint, use getIssuesFromCurrentSprint.'

Inferred effective spec: <=2025-11-25.

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