Add Sentry adapter with four read-only tools

[Nagharjun17]

Summary

Add a Sentry adapter so agents can discover projects, investigate issues,
and inspect individual error events with stack traces.

Changes

• Add four read-only tools: list projects, list issues, retrieve an issue,
  and list issue events.
• Register the adapter in the generated catalog.
• Document Bearer-token setup, required scopes, and pagination limitations.
• Add opt-in live tests using an existing Sentry test project.

Type

• New feature

Testing

• Adapter validator: 189 adapters passed.
• Catalog tests: 2,388 tests passed.
• Backend suite: 241 suites and 4,111 tests passed; 55 tests skipped.
• All four Sentry live tests passed against a test project with a sample error.
• Confirmed all four live tests skip when RUN_SENTRY_LIVE is disabled.

The root npm test command finishes the backend tests but exits with an
error because the frontend workspace has no test script. The backend run
also reported a worker-shutdown warning.

Limitations

List tools return one page. Sentry supplies pagination cursors in Link
headers, but the REST engine returns only the response body. The adapter
accepts externally supplied cursors and documents this limitation.

Related Issues

Relates to #150.

[github-actions]

👋 Welcome, @Nagharjun17, and thanks for opening your first PR on AnythingMCP!

A few quick pointers:

• Make sure CI is green before requesting review (Backend, Frontend, Playwright, CodeQL, Trivy).
• If this is a new adapter, the parametrised catalog.spec.ts test will validate it automatically.
• Sign off your commits if you can — it's not blocking, just nice to have.

Someone from the core team will look at this within ~48h. If you don't hear back, please ping us in Discussions / Q&A.

⭐ While you wait — if you find AnythingMCP useful, a star helps others discover it.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Nagharjun17]

I have read the CLA Document and I hereby sign the CLA

[keysersoft]

Hi Nagharjun, thanks for this. I went through the JSON and the live spec and it's a solid first adapter: the descriptions actually tell the model when to use which tool, the params are explicit with examples, and you were upfront about the pagination limit instead of hiding it. Also nice that you found the regenerate script on your own, the issue text was out of date on that (fixed now).

Two things before I merge, the first one matters, the second is optional.

1. The organization slug. Right now every tool requires organization_id_or_slug, so the model has to know it or ask on every call. We handle this kind of thing with an env var. Add SENTRY_ORG to requiredEnvVars, write the paths as /organizations/{{SENTRY_ORG}}/issues/ and so on, and drop the parameter from the tools. The double braces are resolved from the connector's env vars at call time, the WhatsApp and Amazon Seller adapters do exactly this if you want a reference (intl/whatsapp-business.json). The user sets it once when installing and never thinks about it again.

2. Self hosted Sentry. If you make the base URL {{SENTRY_BASE_URL}} with https://sentry.io/api/0 as the default in the env var description, the same adapter works for people running their own Sentry. Those are honestly the users most likely to pick AnythingMCP over the official Sentry connector, so it's worth the one line. Totally fine to leave it for a follow up if you prefer.

On pagination: that's a limitation of our REST engine (it only hands the body back to the tool, never the response headers), not something you should work around here. I opened #557 for it. Leave the cursor param as you have it.

Guide page, logo and the marketplace listing are on our side after the merge, you don't need to do anything for those.

[keysersoft]

Quick update on the pagination point. The engine limitation is gone: #557 landed today and is live in 0.7.0. A REST tool can now ask for response headers, so your two list tools can work through all pages instead of one.

The change on your side is small. On sentry_list_issues and sentry_list_issue_events add

"exposeHeaders": ["link", "x-sentry-rate-limit-remaining"]

to the endpointMapping, keep the cursor query param you already have, and adjust the description to say something like "pass cursor = _pagination.nextCursor from the previous call; when _pagination is missing you are on the last page". The engine reads Sentry's Link header, finds rel="next", and puts the cursor value under _pagination.nextCursor (it looks at the query params your tool actually maps, so it picks cursor and not something else). Details in docs/tool-definition.md, section "Response headers and pagination".

Together with the SENTRY_ORG env var from my earlier comment, that's everything. Happy to merge as soon as those are in.