feat(plugins): add Sentry plugin backed by a sentry_mcp connector

Merged
HA
1mo ago
+472-2

What

Adds the plugins-flow half of the Sentry story. The sentry connector (org-scoped app_install) already powers the automations flow — webhook triggers, one installation per Sentry org. This PR adds:

  • sentry_mcp connector in connectors.json: a dynamic public OAuth client against https://mcp.sentry.dev/mcp (discovery + dynamic client registration + PKCE, same as notion_mcp). No client id, no secret, nothing to provision.
  • An mcp identity-probe variant in the connector framework: after the token exchange, probeIdentity opens a short streamable-HTTP MCP session (initialize → notifications/initialized → tools/call) and reads the identity JSONPaths from the tool's structured content. This is what makes a dynamic client viable for MCP servers that put no identity in their token response.
  • plugins/sentry/ first-party plugin (published as sentry@1.0.0): proxies agents to Sentry's hosted MCP server, plus two skills (debug-with-sentry, find-in-sentry).
  • auth: [{ type: "oauth2" }] on the existing PLUGIN_CATALOG sentry entry, matching linear/github.

Why the framework change

mcp.sentry.dev runs Cloudflare's workers-oauth-provider. Verified against the live server: its token response is exactly {access_token, token_type, expires_in, scope, refresh_token} — no identity fields — and it has no userinfo endpoint. The url-less identity probe (notion_mcp's pattern) would therefore fail every connect on account.id.

The identity does exist over MCP: execute_sentry_tool(name: "whoami") returns {user: {id, name, email}} as structured content. The new probe variant reads it:

"identity": {
  "mcp": "https://mcp.sentry.dev/mcp",
  "tool": "execute_sentry_tool",
  "arguments": { "name": "whoami", "arguments": {} },
  "account": { "id": "$.user.id", "label": "$.user.email" },
  "user":    { "id": "$.user.id", "label": "$.user.name" }
}

An earlier revision of this PR worked around the gap with a static sentry.io OAuth client (Sentry-Bearer binding, SENTRY_MCP_CLIENT_ID/SECRET env vars); the MCP probe removes all of that operational surface.

Validation

  • Live end-to-end: ran the full dynamic flow against mcp.sentry.dev — registration issued a public client (token_endpoint_auth_method: "none"), PKCE code exchange succeeded, and the shipped probeIdentity code returned {account: {id: "5009252", label: "harshith@superset.sh"}, user: {id: "5009252", label: "Harshith"}} for a real token. find_organizations and other tools work with the same token. One live-flow caveat baked into the config: the authorize request must send no scope parameter (an explicit scope string makes Sentry's consent flow error out), hence "scopes": [].
  • bun run check:plugins — all plugins valid and published
  • packages/trpc connectors tests: 45 pass (new test asserts the MCP probe sequence and identity mapping); plugins router tests: 39 pass
  • packages/shared: 1143 tests pass
  • turbo typecheck for @superset/shared, @superset/trpc, @superset/api

Before this ships

  • Tag sentry@1.0.0 on the merge commit (the tag is the release the hosts download).

No secrets or Sentry-side app registration needed.

Summary by CodeRabbit

  • New Features
    • Added Sentry as a developer tools integration with OAuth sign-in and access to Sentry data.
    • Added guidance for investigating Sentry issues, tracing errors to code, checking production releases, and assessing potential causes and impact.
    • Added guidance for searching Sentry issues and events, evaluating error trends, and reporting findings with links and time ranges.
  • Bug Fixes
    • Uses the metadata-document sign-in flow only when the URL is secure and the server supports it.
  • Improvements
    • The plugin catalog refreshes when you return to the app window.