Sentry.io에서 문제를 검색하고 분석하기 위한 모델 컨텍스트 프로토콜 서버입니다. 이 서버는 Sentry 계정에서 오류 보고서, 스택 추적 및 기타 디버깅 정보를 검사할 수 있는 도구를 제공합니다.
get_sentry_issue
ID 또는 URL로 Sentry 문제 검색 및 분석
입력:
issue_id_or_url (문자열): 분석할 Sentry 문제 ID 또는 URL
반품: 문제 세부 정보 포함:
제목
문제 ID
상태
수준
처음 본 타임스탬프
마지막으로 본 타임스탬프
이벤트 수
전체 스택 추적
get_list_issues
프로젝트 슬러그별로 Sentry 문제를 검색하고 분석합니다.
입력:
project_slug (문자열): 분석할 Sentry 프로젝트 슬러그
organization_slug (문자열): 분석할 Sentry 조직 슬러그
반환: 다음을 포함한 세부 정보가 포함된 문제 목록:
제목
문제 ID
상태
수준
처음 본 타임스탬프
마지막으로 본 타임스탬프
이벤트 수
기본 문제 정보
sentry-issue
Sentry에서 문제 세부 정보 검색
입력:
issue_id_or_url (문자열): Sentry 문제 ID 또는 URL
반환: 대화 맥락으로 포맷된 문제 세부 정보
Related MCP server: MCP Server Sentry
Smithery를 통해 Claude Desktop에 mcp-sentry를 자동으로 설치하려면:
지엑스피1
uv 사용하면 별도의 설치가 필요하지 않습니다. uvx 사용하여 mcp-sentry를 직접 실행합니다.
또는 pip를 통해 mcp-sentry 설치할 수 있습니다.
pip install mcp-sentry또는 uv를 사용하세요
uv pip install -e .설치 후 다음을 사용하여 스크립트로 실행할 수 있습니다.
python -m mcp_sentryclaude_desktop_config.json 에 다음을 추가하세요:
"mcpServers": {
"sentry": {
"command": "uvx",
"args": ["mcp-sentry", "--auth-token", "YOUR_SENTRY_TOKEN","--project-slug" ,"YOUR_PROJECT_SLUG", "--organization-slug","YOUR_ORGANIZATION_SLUG"]
}
}"mcpServers": {
"sentry": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/sentry", "--auth-token", "YOUR_SENTRY_TOKEN","--project-slug" ,"YOUR_PROJECT_SLUG", "--organization-slug","YOUR_ORGANIZATION_SLUG"]
}
}"mcpServers": {
"sentry": {
"command": "python",
"args": ["-m", "mcp_sentry", "--auth-token", "YOUR_SENTRY_TOKEN","--project-slug" ,"YOUR_PROJECT_SLUG", "--organization-slug","YOUR_ORGANIZATION_SLUG"]
}
}Zed settings.json에 다음을 추가합니다.
예를 들어 Curson
"context_servers": [
"mcp-sentry": {
"command": {
"path": "uvx",
"args": ["mcp-sentry", "--auth-token", "YOUR_SENTRY_TOKEN","--project-slug" ,"YOUR_PROJECT_SLUG", "--organization-slug","YOUR_ORGANIZATION_SLUG"]
}
}
],"context_servers": {
"mcp-sentry": {
"command": "python",
"args": ["-m", "mcp_sentry", "--auth-token", "YOUR_SENTRY_TOKEN","--project-slug" ,"YOUR_PROJECT_SLUG", "--organization-slug","YOUR_ORGANIZATION_SLUG"]
}
},"context_servers": {
"sentry": {
"command": "python",
"args": [
"-m",
"mcp_sentry",
"--auth-token",
"YOUR_SENTRY_TOKEN",
"--project-slug",
"YOUR_PROJECT_SLUG",
"--organization-slug",
"YOUR_ORGANIZATION_SLUG"
],
"env": {
"PYTHONPATH": "path/to/mcp-sentry/src"
}
}
},MCP 검사기를 사용하여 서버를 디버깅할 수 있습니다. UVX 설치의 경우:
npx @modelcontextprotocol/inspector uvx mcp-sentry --auth-token YOUR_SENTRY_TOKEN --project-slug YOUR_PROJECT_SLUG --organization-slug YOUR_ORGANIZATION_SLUG또는 특정 디렉토리에 패키지를 설치했거나 해당 디렉토리에서 개발 중인 경우:
cd path/to/servers/src/sentry
npx @modelcontextprotocol/inspector uv run mcp-sentry --auth-token YOUR_SENTRY_TOKEN --project-slug YOUR_PROJECT_SLUG --organization-slug YOUR_ORGANIZATION_SLUG 또는 용어로
npx @modelcontextprotocol/inspector uv --directory /Volumes/ExtremeSSD/MCP/mcp-sentry/src run mcp_sentry --auth-token YOUR_SENTRY_TOKEN
--project-slug YOUR_PROJECT_SLUG --organization-slug YOUR_ORGANIZATION_SLUG
이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 조건에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
Retrieve and analyze Sentry issues by project slug. 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
| Name | Required | Description | Default |
|---|---|---|---|
| project_slug | No | Sentry project slug to analyze | |
| organization_slug | No | Sentry organization slug to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully describes the data accessed (stacktraces, counts, first/last occurrence dates) but omits safety classification (read-only vs. destructive), authentication requirements, or rate limiting constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with the core purpose front-loaded in the first sentence, followed by actionable bullet points. Each of the five use-case bullets earns its place by clarifying distinct capabilities. Slightly verbose but efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema and lack of output schema, the description adequately compensates by detailing the returned information (stacktraces, status, counts) within the text. Missing only safety/permission context which would normally appear in annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both 'project_slug' and 'organization_slug', establishing a baseline of 3. The description references 'by project slug' confirming the primary filter, but does not add format constraints, examples, or explain the optional nature of parameters (required: [] in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination ('Retrieve and analyze Sentry issues') and scopes it to 'by project slug'. It distinguishes from sibling 'get_sentry_issue' by emphasizing aggregate capabilities like 'patterns and frequencies' and 'error counts' vs. single-issue retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool when you need to:' preamble followed by five specific scenarios (investigate crashes, access stacktraces, analyze patterns, etc.) provides excellent contextual guidance. Lacks an explicit pointer to sibling 'get_sentry_issue' for single-issue lookups, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id_or_url | Yes | Sentry issue ID or URL to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses what data is returned (stacktraces, frequencies, first/last occurrence, status) but omits operational concerns: authentication requirements, rate limits, error handling for invalid IDs, or privacy implications of accessing production errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose front-loaded in the first sentence, followed by explicit usage guidelines. Bullet points are specific and non-redundant. Slightly verbose compared to minimalist ideal, but every sentence serves distinct selection or invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool without output schema, description adequately hints at return value structure by listing accessible data types (stacktraces, error patterns, temporal metadata). Missing only operational edge cases; sufficient for agent to understand tool capabilities and expected output richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single parameter 'issue_id_or_url' fully documented). Description mentions 'by ID or URL' which aligns with schema but adds no additional semantic value such as format examples, validation rules, or distinction between ID vs URL input behavior. Baseline 3 appropriate for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+noun combination ('Retrieve and analyze a Sentry issue') and clearly identifies the lookup method ('by ID or URL'). Effectively distinguishes from sibling 'get_list_issues' by emphasizing singular issue retrieval versus listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prefixes usage scenarios with 'Use this tool when you need to:' followed by five specific bulleted contexts (production errors, stacktraces, error patterns, temporal data, counts/status). Lacks explicit 'when not to use' or named alternative, but sibling tool name provides clear contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.6.2get_list_issuesget_sentry_issueThe two tools are essentially indistinguishable in purpose. Both descriptions are identical, listing the exact same use cases (investigate errors, access stacktraces, analyze patterns, get timing info, review counts). An agent would have no way to determine when to use get_list_issues versus get_sentry_issue since they appear to serve the same function.
Both tools follow a similar get_ prefix pattern, which provides some consistency. However, the naming is confusingly similar (get_list_issues vs get_sentry_issue) rather than clearly differentiated, and the verb-noun structure is mixed (list_issues vs sentry_issue).
With only 2 tools, this feels severely under-scoped for a Sentry integration. A production error monitoring system would typically need tools for creating issues, updating statuses, searching/filtering, accessing events, or managing projects. Two tools is too few to cover meaningful workflows.
The tool surface is severely incomplete for Sentry's domain. There are no tools for creating issues, updating issue status (resolve/ignore), searching across projects, accessing event details, managing alerts, or any administrative functions. The two existing tools appear redundant rather than complementary.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for Studex tools, notifications, and profile integrations
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MCP-100/mcp-sentry'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
