Skip to main content
Glama
HieuAnh87

selfhosted-sentry-mcp

by HieuAnh87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_sentry_issue

Read-onlyIdempotent

Retrieve a Sentry issue by numeric ID, short ID, or URL to review core fields. Include the latest event for exception stack frames, message, and breadcrumbs.

Instructions

Retrieve a Sentry issue by numeric ID, short ID (e.g. PROJ-1A2) or issue URL. Returns essential issue fields only; the stacktrace is NOT included unless include_latest_event is true, which adds the latest event's exception (innermost max_stack_frames frames per exception), message and recent breadcrumbs. Supports field filtering, grep and automatic truncation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
grep_patternNoOptional: Regex pattern to filter response content.
exclude_fieldsNoOptional: List of fields to exclude (blacklist). Use dot notation for nested fields.
include_fieldsNoOptional: List of fields to include (whitelist). Use dot notation for nested fields (e.g., "latest_event.entries").
issue_id_or_urlYesNumeric issue ID or short ID (e.g. PROJ-1A2), or a full Sentry issue URL.
max_stack_framesNoOptional: Innermost stack frames kept per exception in latest_event (default: 5). Only applies with include_latest_event.
include_latest_eventNoAlso fetch the latest event (exception with stack frames, message, recent breadcrumbs). Default: false, so no stacktrace is returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / include_latest_event / description
      Previous value: -"Include latest event details (default: false to reduce response size)"New value: +"Also fetch the latest event (exception with stack frames, message, recent breadcrumbs). Default: false, so no stacktrace is returned."
    • changedInput schema / properties / issue_id_or_url / description
      Previous value: -"Sentry issue ID or full issue URL. Issue ID is a number e.g: 123456"New value: +"Numeric issue ID or short ID (e.g. PROJ-1A2), or a full Sentry issue URL."
    • changedInput schema / properties / max_stack_frames / description
      Previous value: -"Optional: Maximum number of stack trace frames to return (default: all)."New value: +"Optional: Innermost stack frames kept per exception in latest_event (default: 5). Only applies with include_latest_event."
  2. First observedv1.2.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this a safe, idempotent read; beyond that the description discloses what is and isn't returned (essential fields only, no stacktrace by default), what enabling include_latest_event adds (innermost frames per exception, message, recent breadcrumbs), and that responses are truncated. These are exactly the behavioral traits annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the identifier forms, then the return-value caveat and the flag that changes it. Dense but every clause carries information an agent needs before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing returns, and it does: essential fields only, conditional exception/message/breadcrumbs payload, and truncation behavior. Nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including max_stack_frames, grep_pattern and include/exclude_fields is already documented. The description reinforces the include_latest_event coupling and truncation but adds no syntax or format details beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (retrieve a Sentry issue) and enumerates the accepted identifier forms (numeric ID, short ID, URL). This clearly separates it from list-oriented siblings like list_sentry_issues and from get_sentry_event_details, which fetches events rather than the issue record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the key choice explicit: the stacktrace is NOT returned unless include_latest_event is true, so an agent knows when to flip that flag. It does not, however, name an alternative tool (e.g. get_sentry_event_details or list_issue_events) for deeper event inspection, so routing guidance is implicit rather than complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools