Two tools with basic naming and minimal descriptions. Both tools have input schemas with type definitions, but descriptions are generic and lack actionable context. No output schemas documented. No error handling guidance. Parameter descriptions are present but sparse. Missing parameter constraints (enums, ranges). No indication of idempotency, destructiveness, or recovery paths. Naming follows verb_noun pattern (get_, search_) but descriptions do not explain WHEN to use each tool or what distinguishes them.

• Add output schema documentation for both tools. Example: get_jira_issue returns {issue_key: string, summary: string, description: string, status: string, assignee: string, created: ISO8601, updated: ISO8601}. This enables LLMs to chain calls and extract fields.
• Expand tool descriptions to 80-150 chars. Example: 'Fetch a single JIRA issue by key (e.g. PROJECT-123). Returns summary, description, status, assignee, and timestamps. Use this when you have the exact issue key; use search_jira_issue to find issues by criteria.'
• Add parameter constraints. For issue_key, add pattern: '^[A-Z]+-\d+$' and description: 'JIRA issue key in format PROJECT-123 (uppercase letters, hyphen, digits). Comma-separated keys accepted (e.g. PROJECT-123,PROJECT-456).'
• Document pagination for search_jira_issue. Add limit (default 20, max 100) and offset parameters. Return total_count and next_offset in response. Cap results at 50 items per call.
• Add error handling guidance. Example: 'If issue not found, return error: "Issue PROJECT-999 not found. Try search_jira_issue with project=PROJECT to find similar issues."'

Inferred effective spec: 2026-07-28+.

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