Loading ToolBench
The server provides 2 tools with clear, actionable descriptions (194 chars baseline exceeded). Tool names follow verb_noun pattern (get_, list_). However, critical issues emerge: (1) input parameters lack descriptions in schema, the JSON Schema shows property definitions but no 'description' field for parameters themselves; (2) output schema is not documented, SentryIssueData.to_tool_result() returns TextContent, but LLMs cannot see the structured fields they'll receive; (3) error handling exists (McpError, SentryError) but lacks recovery guidance, errors like 'Missing issue_id_or_url argument' don't suggest next steps; (4) the extract_issue_id() function validates well but no 'format' or 'pattern' constraint is declared in the schema itself. Tool composition is sound (get vs list distinction clear). Naming is appropriate (get_sentry_issue, list_sentry_issues match action verbs).
Retrieve and analyze a Sentry issue by ID or URL. Use this tool when you need to: - Investigate production errors and crashes - Access detailed stacktraces from Sentry - Analyze error patterns and frequencies - Get information about when issues first/last occurred - Review error counts and status
List all issues in a Sentry project. Use this tool to: - Get an overview of all issues in a project - Identify high-priority errors - Track issue status and frequency - Monitor error trends across the project
Input parameters lack descriptions in JSON Schema. The 'issue_id_or_url' parameter in get_sentry_issue has a type and is required, but the schema contains no 'description' field for it. The tool description mentions 'Sentry issue ID or URL' but this is tool-level, not parameter-level, LLMs need explicit per-parameter guidance to avoid misuse.
Output schema is not documented. The tools return SentryIssueData (structured via to_tool_result()), but no schema is provided to the MCP server registration. LLMs cannot plan downstream operations or extract specific fields without explicit output documentation.
Error messages lack recovery guidance. extract_issue_id() raises SentryError with messages like 'Invalid Sentry URL. Must be a URL ending with .sentry.io', but does not suggest what the LLM should do next (retry with different format, call a discovery tool, etc.). Pattern: recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No pagination support on list_sentry_issues. The tool lists 'all issues in a project' but does not accept limit or page parameters, and does not document result caps. If a project has 500+ issues, the full list could blow the context window. Pattern: paginated-result.
Parameter format constraints not in schema. extract_issue_id() validates that issue_id must be numeric and optionally a Sentry URL, but the JSON Schema does not declare a pattern (e.g., '^\d+$') or format. LLMs cannot validate locally and may pass invalid values.