Single tool with critical definition gaps. Tool name 'Get_Sentry_Event' uses underscore convention (non-standard verb_noun) and lacks clarity on what 'event' means in Sentry context. Description is 287 chars but reads as API documentation (URL examples, parameter mapping) rather than LLM-optimized guidance on WHEN/WHY to call it. Input schema present but parameters lack descriptions entirely, 'issueId' and 'eventId' are unexplained, forcing LLMs to guess. No output schema documented. No error handling guidance. Tool does not follow pattern:tool-description or pattern:response-shaper standards.

• Add descriptions to both parameters: 'issueId (number): The Sentry issue ID, obtain from search_sentry_issues or the Sentry UI.' and 'eventId (string): The event ID within the issue, visible in Sentry event timeline.'
• Document output schema: 'Returns {type: "text", text: string} containing JSON with fields: title (string), location (string), contexts (object). Use title for summaries, contexts for debugging details.'
• Rewrite description to 100-150 chars: 'Retrieves detailed event information from Sentry by issue and event ID. Use this after identifying an issue to inspect error context, stack traces, and breadcrumbs. Returns structured event data.'
• Add error handling: wrap fetch in try-catch, return actionable errors like 'Issue {issueId} not found. Verify the ID or call search_sentry_issues() first.' for 404s.
• Rename tool to lowercase 'get_sentry_event' to match verb_noun convention and improve LLM parsing.