Critical gaps across all dimensions. Tool definitions are inferred from factory functions and test assertions rather than directly visible in source. No input schemas found in provided code. Descriptions are minimal (10-40 chars, well below 50-200 char baseline for A+ tools). No parameter descriptions visible. No output schemas documented. No error handling guidance. Tool names follow verb_noun pattern (positive), but lack the supporting schema and description infrastructure required for LLM-safe operation.

• Create explicit tool registration with full JSON Schema input definitions. Each tool must declare parameter types (string, number, boolean, array, object), required fields, and constraints (enum, minLength, pattern, minimum, maximum).
• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. Example: 'Search Jira issues using JQL syntax. Use this to find issues by status, assignee, or custom criteria. Requires valid JQL query string.'
• Document output schemas for all tools. Specify returned fields, types, and pagination info. For list tools, include limit, offset/cursor, and total_count. Example: 'Returns array of issues with fields: key, summary, status, assignee, created, updated.'
• Add parameter descriptions to all inputs. Disambiguate generic names like 'type', 'status', 'value'. Example: 'issue_key (string, required): Jira issue identifier (e.g., PROJ-123). Must be uppercase alphanumeric with hyphen.'
• Implement confirmation/dry-run for destructive operations (delete_attachment, delete_issue_link). Return 'input_required' with confirmation prompt before executing irreversible changes.