Single tool with clear naming (get_sentry_issue) and good description (194 chars, well-structured with use cases). Input schema present with type and description. However, output schema is not documented, LLMs cannot predict response structure. No error handling guidance (what happens on invalid issue ID, auth failure, API timeout?). No parameter constraints (issue_id_or_url accepts any string; should validate format). Prompt feature registered but duplicates tool logic without clear distinction. Missing pagination, rate-limit guidance, and recovery instructions.

• Document the output schema explicitly. Specify that the tool returns a text field containing formatted issue details, and list key fields the LLM can expect (title, status, error count, stacktrace, first/last seen).
• Add error handling with recovery hints. Catch auth failures ('Invalid Sentry token. Verify SENTRY_TOKEN env var.'), invalid IDs ('Issue not found. Try searching by error message.'), and timeouts ('Sentry API timeout. Retry in 30s.').
• Constrain the issue_id_or_url parameter. Add description: 'Sentry issue ID (numeric) or full URL (https://sentry.io/organizations/*/issues/*)'. Validate format in the handler and return clear errors.
• Clarify the sentry-issue prompt's purpose. Either remove it (tool alone is sufficient) or redesign it to guide multi-step workflows (e.g., 'Retrieve issue, then suggest fixes based on stacktrace').
• Add pagination and limits to tool description. State: 'Returns up to 100 most recent events. For full event history, use Sentry web UI or paginate via API.' Offer optional parameters like event_limit or time_range.