Server has solid naming conventions (verb_noun pattern across all 9 tools) and complete input schemas with type definitions. Descriptions are present but inconsistent in depth, some are terse (e.g., 'Build the web URL for an issue key. No API call.' is 47 chars, below the 50-char baseline for clarity). Parameter descriptions are sparse: 'key' appears in 6 tools with minimal context; 'fields' lacks guidance on valid field names or defaults. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (generic catch-all in server.ts). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write distinction in code. Security is reasonable (no secrets in params, guards for queue access), but no audit logging or rate limiting.

• Add output schema documentation to all tools. Example for get_issue: 'Returns {key: string, summary: string, status: string, assignee: {id, name}, created: ISO8601, updated: ISO8601, ...}'. Use JSDoc or inline comments in tool definitions.
• Expand parameter descriptions with format/constraint guidance. E.g., 'key: Issue key in format QUEUE-NUMBER (e.g., ABC-1). Queue must be allowed by TRACKER_LIMIT_QUEUES if set.' and 'fields: Array of field names to return (e.g., ["summary", "status", "assignee"]). Omit or pass ["*"] for all fields.'
• Add tool annotations to MCP tool definitions. In server.ts ListToolsRequestSchema handler, add readOnlyHint: true for read-only tools and destructiveHint: true for write tools. Example: {name: 'create_issue', description: '...', inputSchema: {...}, readOnlyHint: false, destructiveHint: true}.
• Implement structured error responses with recovery guidance. Replace generic catch-all with specific error types: 'Issue not found. Try search_issues() to find the correct key.' or 'Queue ABC not allowed. Allowed queues: [XYZ, DEF].' Use error classification (retryable, user-fixable, fatal).
• Document pagination and result limits. Add limit/offset parameters to search_issues and list_comments. Cap results at 50 items by default. Return total_count and next_offset in responses. Document in tool descriptions: 'Returns up to 50 results. Use offset parameter to paginate.'