Server has 6 tools with basic schemas and descriptions, but significant gaps prevent production use. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization), and input schemas are present but lack parameter descriptions entirely. No tool has documented output schemas. Parameter naming is inconsistent (org_slug vs project_slug; some optional params lack defaults). Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Descriptions are too terse to guide LLM selection (e.g., 'Inspect server configuration and capabilities' is 50 chars; baseline is 50-200). Parameter descriptions are completely absent from schemas.

• Add parameter descriptions to all tool schemas. For each parameter (org_slug, project_slug, release_version, count, issue_id), add a 'description' field explaining what it is, valid format, and constraints. E.g., 'org_slug: Organization slug from Sentry (alphanumeric, 2-50 chars)'.
• Document output schemas for all tools. Add a 'returns' or 'outputSchema' section to each tool definition. E.g., get_issue returns {id: string, title: string, permalink: string, status?: string}.
• Expand tool descriptions to 80-150 characters. Include WHAT the tool does, WHEN to use it, and any prerequisites. E.g., 'Get a Sentry issue by ID. Use this after searching for issues or when you have an issue ID. Returns title, status, and permalink.'
• Add readOnlyHint: true to all tool definitions since all tools are read-only queries. This signals to agents that calls are safe to retry and do not modify state.
• Implement error handling with recovery guidance. Catch axios errors and return structured responses like {error: 'Issue not found', suggestion: 'Try list_recent_releases() to find valid issue IDs', retryable: false}.

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

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