Loading ToolBench
Model Context Protocol server for Sentry error tracking and issue management. Provides tools to search issues, events, and organizations; execute Sentry operations; and integrate Sentry functionality into AI agents.
The Sentry MCP Server exposes only 2 tools with reasonable descriptions and acceptable parameter schemas. Both tools are discovery/execution wrappers rather than domain-specific operations. Tool naming follows verb_noun convention (search_, execute_), and descriptions are present and moderately detailed (160 - 190 chars). However, the design represents a significant architectural departure from Arcade patterns, rather than exposing granular, single-responsibility tools (get_project, list_issues, create_alert), it delegates tool catalog and execution to runtime discovery via search_sentry_tools and execute_sentry_tool. This indirection trades immediate discoverability for flexibility, but creates friction: LLMs must first search for the right tool name, then invoke it by name with unvalidated schemas. Output schemas for both tools are undocumented, callers cannot know the structure of search results or execution responses. Parameter descriptions are adequate but lack detail on result limits, filtering, and error cases. Error handling guidance is minimal. The tool annotations (toolAnnotations=true) suggest readOnlyHint/destructiveHint presence, but these are not visible in the provided source. Overall, the server is competent but not production-grade for agentic use without additional discovery documentation.
Execute an available Sentry MCP tool discovered through search_sentry_tools. Use this tool when you need to: - Call a Sentry operation returned by search_sentry_tools - Execute a tool by name using arguments that match its returned schema <examples> execute_sentry_tool(name='find_projects', arguments={ organizationSlug: 'my-org' }) execute_sentry_tool(name='whoami', arguments={}) </examples> <hints> - Use search_sentry_tools first if you are not sure which name or arguments to pass. - Arguments are validated against the target tool's schema before execution. - Active organization, project, and region constraints are injected automatically. </hints>
Search the available Sentry MCP tool catalog by name and description. Many Sentry operations are intentionally not exposed as top-level tools. Use this for any Sentry-related task when you do not see an obvious direct tool, including long-tail inspection, project management, documentation lookup, preprod snapshots, attachments, DSNs, releases, teams, and issue-specific pivots. Use this tool when you need to: - Find the right Sentry operation for a task - Discover catalog tools and their schemas for a task - Inspect the executable JSON input schema for an available tool <examples> search_sentry_tools(query='list projects') search_sentry_tools(query='issue details') search_sentry_tools(query='find dsn', limit=5) search_sentry_tools(query='snapshot image') </examples> <hints> - Results only include tools available in the current session. - If a Sentry operation is not listed as a direct tool, search here before deciding it is unavailable. - Returned schemas already account for active organization, project, and region constraints. - Use the returned name and schema when executing a catalog result. - This tool returns structured JSON. Do not parse markdown from its text content. </hints>
Output schemas are not documented. Callers cannot know the structure of search_sentry_tools results (does it return tool objects with name, description, schema fields? Is it paginated?) or execute_sentry_tool responses (error format, result shape, content type). LLMs cannot reliably parse responses without schema guidance.
execute_sentry_tool accepts 'arguments' as a generic object with no schema constraints. The tool description states 'Arguments are validated against the target tool's schema before execution' but the input schema for the 'arguments' parameter provides no structure, type hints, or validation rules. LLMs cannot predict valid inputs without runtime discovery.
The 'limit' parameter in search_sentry_tools lacks a minimum/maximum range. Description states 'up to 20' but this is not enforced in the schema. Unbounded integer parameters allow LLMs to pass absurd values (limit=10000) that could cause performance issues or API errors.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No error handling guidance. Neither tool description explains what happens on failure, when to retry, or what the LLM should do if a tool is not found or an execution fails. Pattern guidance is missing ('User not found. Try search_users() with a partial name.').
Tool composition via indirection. Instead of exposing granular tools (list_projects, get_issue_details, create_alert), the server delegates all operations to execute_sentry_tool, requiring two-step discovery + execution. This violates the pattern that common user intents should resolve in one call, and increases latency and token waste.