getsentry / getsentry/sentry-mcp
Distribute a skill for issue and event search
- Dominant language
- TypeScript
- Stars
- 853
- Forks
- 144
- Avg merge
- 19h 25m
- Merged PRs (30d)
- 32
Description
## Summary
The MCP server currently relies on embedded agent logic for Sentry issue and event search. Distributing this as a standalone, versioned skill would let dependent integrations (e.g., Slack bots, chat agents) rely on a consistent, testable interface rather than ad-hoc embedded implementations.
## Current behavior
Issue and event search logic is implemented inline inside the MCP server's tool handlers. Any consumer that wants similar behavior must either depend on the MCP server directly or re-implement the search logic themselves.
## Gap
- No stable contract for issue/event search that external agents can depend on
- Changes to search behavior require updates in every embedded consumer
- Difficult to test search logic in isolation from transport concerns
- Skill-based distribution would enable versioning, independent iteration, and reuse across agents without tight coupling to the MCP server internals
## Options
**Option A — Extract as a distributed skill package**
Publish a `@sentry/skill-issue-search` (or equivalent) package that exposes a stable programmatic API for issue and event search. Agents import the skill directly; the MCP server becomes one consumer of it.
- ✅ Clean separation, independently versioned and testable
- ⚠️ Requires defining and maintaining a public skill API contract
**Option B — Expose search as a dedicated MCP resource/tool with documented schema**
Keep logic in sentry-mcp but harden the tool schema and document it as the canonical search interface. Agents call the MCP tool rather than embedding their own logic.
- ✅ Minimal structural change
- ⚠️ Agents still depend on the MCP server being available; no offline/embedded use case
**Option C — Skill file distribution (prompt/config-level)**
Define search behavior as a versioned skill file (prompt template + tool spec) that can be loaded by any compatible agent runtime. Already consistent with the skills pattern used in chat-based agents.
- ✅ Lightweight, aligns with existing skill infrastructure
- ⚠️ Limited to agents that support the skill loading protocol
## Recommendation
Option A or C depending on the target consumers. If the primary need is chat agents (Slack bots, etc.), Option C (skill file distribution) is the lowest-friction path and is already proven infrastructure. If the need extends to programmatic consumers or SDK-level reuse, Option A is the right long-term move.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.