Server has 10 tools with basic schemas and descriptions, but significant quality gaps. All tools have descriptions (10-100 chars, mostly 80-120 chars) and input schemas with type definitions. However, descriptions lack actionable context (WHEN to use, prerequisites, state-change implications). Parameter descriptions are minimal. No output schemas documented. Error handling is absent from definitions. Naming is verb-first but some tools are redundant (execute_jql vs get_only_ticket_name_and_description). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Schemas are present but sparse, many parameters lack constraints, ranges, or enums. This is typical C-grade community server work.

• Add output schemas to every tool. Document the response structure, field types, and which fields are needed for downstream tool chaining (e.g., create_ticket returns ticket_id, which assign_ticket needs).
• Expand descriptions to 100-200 chars. Include WHEN to use (e.g., 'Use this to find tickets matching a condition before updating them'), prerequisites (e.g., 'Requires a valid JQL query'), and state-change implications (e.g., 'Creates a new ticket; cannot be undone without delete_ticket').
• Add tool annotations to schema. Mark delete_ticket and edit_ticket with destructiveHint: true; mark read-only tools with readOnlyHint: true. This enables agents to reason about safety.
• Consolidate execute_jql and get_only_ticket_name_and_description into a single search_tickets tool with an optional 'fields' parameter (default: ['key', 'summary', 'description']) to control verbosity.
• Add enums and constraints to parameters. E.g., issuetype.name should be an enum of valid issue types; number_of_results should have minimum: 1, maximum: 100; labels should validate against Jira's label format.