Repository navigation
search_events always fails on self-hosted Sentry 25.7.0: /events/validate/ returns 404 #1355
Description
Summary
Since 0.37.0, search_events calls GET /api/0/organizations/{org}/events/validate/ before every events query (#1105, #1113). Our self-hosted Sentry 25.7.0 answers 404 on that endpoint. The tool treats the 404 as a fatal error, so search_events fails on every call, even though the events query itself would succeed.
Environment
@sentry/mcp-server0.42.0, stdio- Self-hosted Sentry 25.7.0 (build
0ce69559) - Flags:
--host=<self-hosted host> --organization-slug=<org> --project-slug=<project> --skills=inspect,triage - User auth token with
event:read,project:read,org:read,alerts:read
Steps to reproduce
- Start the server with the flags above against a self-hosted Sentry 25.7.0.
- Call
search_eventswithdataset: "errors",query: "level:error",statsPeriod: "24h".
Expected
The tool returns the matching error events.
Actual
API error (404): API request failed: Not Found
What we checked
With the same token, directly against the API:
| Request | Status |
|---|---|
GET /organizations/{org}/events/validate/?project=<id>&dataset=errors&field=title |
404 |
GET /organizations/{org}/events/?project=<id>&dataset=errors&field=title&field=count() |
200 |
GET /organizations/{org}/events/?...&dataset=discover |
200 |
GET /organizations/{org}/events/?...&dataset=spans |
200 |
GET /organizations/{org}/events/?...&dataset=ourlogs |
200 |
search_issues and get_sentry_resource work on 0.42.0. On 0.36.0, the last version without the validate call, search_events returns results against the same instance with the same flags. We pinned 0.36.0 as a workaround.
Suggestion
When /events/validate/ answers 404, skip validation and run the events query, maybe with a warning in the tool output. A 404 there most likely means that the server does not have the endpoint, and not that the query is invalid.
If the maintainers prefer not to fall back: which Sentry version is the minimum for search_events? A version check or a note in the self-hosted docs would help.
Related
- fix(api-client): Handle generic 400 responses in validateEvents #1253 handles a generic 400 from
validateEvents. This report is about a 404. - search_events returns HTTP 404 while search_issues + search_issue_events succeed (mcp.sentry.dev hosted) #937 reports a 404 from
search_eventson the hosted server. That may be a different cause.
Activity
linear-code commentedon Oct 1, 2026
MCP-1039
ruvarthesio commentedon Oct 1, 2026
Follow-up: the endpoint is not in Sentry itself before 26.6.0. src/sentry/api/urls.py has no events/validate/ route in 25.7.0 through 26.5.1, and has it from 26.6.0. So this affects every self-hosted instance older than 26.6.0. Skipping validation on a 404 would still help them. A documented minimum Sentry version for search_events, or an error message that names it, would also do.
chykB commentedon Oct 5, 2026
Hi Ruvar, I’d like to work on this issue.
Based on the follow-up confirming that /events/validate/ is unavailable before Sentry 26.6.0, my proposed approach is to:
Could you confirm whether backward-compatible fallback is preferred over enforcing a minimum Sentry version of 26.6.0, and whether the fallback should produce a warning? If this approach is appropriate, I’d be happy to take the issue.
fix(upgrade): delta apply progress bar shows percentage only (no GB s…
fix(upgrade): delta apply progress bar shows percentage only (no GB s…
ruvarthesio commentedon Oct 6, 2026
@chykB Thnx! I'm just the reporter, so not really up to me, but from the user side: a fallback works better than a minimum version, since self-hosted upgrades are often out of the user's hands (ours runs 25.7.0). A warning on stderr is fine; I'd keep it out of the tool result.
chykB commentedon Oct 6, 2026
Thanks, that’s helpful. I’ll account for a 404-only fallback, with any warning sent to stderr rather than included in the tool result, while preserving the existing handling for other errors.
If this direction is good, could you confirm that I can proceed and assign the issue to me?