Agentic Data Plane

Sentry Managed MCP Server

The Sentry managed MCP server gives agents read-only access to a Sentry instance. With it, an agent can discover organizations and projects, list and read issues, read the events (with stack traces) behind them, scope an error’s impact across releases and tags, and surface the commits most likely responsible. The intended use is an agent that reads a Sentry issue and its stack trace to diagnose a bug, then fixes it in the codebase.

After reading this page, you will be able to:

  • Configure the Sentry managed MCP server with per-user OAuth

  • Confine the server to a single Sentry organization (optional)

  • Diagnose an issue from the Inspector or an agent, from discovery through to the suspect commit

What this MCP server does

Wraps the Sentry REST API and exposes read-only tools grouped by the diagnose-and-fix flow. The tools discover organizations and projects, read the error and its stack trace, scope the impact across tags and releases, and localize the fix to a suspect commit.

Authentication is per-user OAuth only. Every tool call runs as the authenticated user against a Sentry OAuth token resolved from the gateway’s token vault, so there is no shared service account and each action is attributed to the calling end user. The server requests only read scopes (org:read, project:read, and event:read).

The server is read-only by design. Resolving or ignoring issues, commenting, and any other write operation is deliberately absent. Use the Sentry UI or its API directly for those.

Tool output is developer-facing observability data and is not guaranteed to be free of personally identifiable information (PII). The curated event shape omits Sentry’s user and request context, but event tags are forwarded verbatim and can carry user-supplied values (for example user, url, server_name, or custom tags), and suspect-commit and release-commit output includes commit author names and email addresses.

This MCP server connects to sentry.io only. Self-hosted Sentry is not supported.

Prerequisites

Before you create the server, make sure you have:

  • A Sentry account on sentry.io with access to the organizations and projects you want the agent to read.

  • A Sentry OAuth application and a matching OAuth provider configured in Redpanda Agentic Data Plane. See Configure an OAuth Provider.

Get Sentry credentials

Sentry MCP uses per-user OAuth, so you register an OAuth application on Sentry and a matching OAuth provider in Agentic Data Plane:

  1. In Sentry, create an OAuth application. See Sentry’s authentication documentation. Set the authorized redirect URI to your Agentic Data Plane gateway’s OAuth callback.

  2. Copy the Client ID and Client Secret, and store the client secret in the Agentic Data Plane secret store.

  3. Register a matching OAuth provider in Agentic Data Plane. See Configure an OAuth Provider. Click Add provider. To narrow the catalog, click the Observability category filter. Then click the Sentry preset card. The preset fills in Sentry’s authorization and token endpoints, PKCE, and the org:read, project:read, and event:read scopes, so you supply only the Client ID and Client Secret reference.

    To enter the endpoints by hand instead, use Sentry’s authorize endpoint (https://sentry.io/oauth/authorize/) and token endpoint (https://sentry.io/oauth/token/).

  4. Each end user authenticates once through the OAuth flow, and tokens are stored in the gateway’s token vault.

Required scopes: org:read, project:read, and event:read. Together they cover every tool on this page, they are all read-only, and the preset seeds exactly these three. If you need to know which scope a particular tool depends on, Sentry’s API reference lists the accepted scopes per endpoint. Most endpoints accept more than one.

Do not add scopes beyond these three. A server that requires a scope the Sentry application isn’t allowed to grant fails every tool call, even after the user reconnects. See Scope upgrades.

Configure

Create a new Sentry MCP server in Agentic Data Plane:

  1. Open MCP servers in the sidebar.

  2. Click Add MCP server.

  3. Click the Sentry card in the marketplace picker.

  4. Replace the suggested Name, and optionally add a Description.

  5. In the Sentry configuration form:

    Field Notes

    organization_slug

    Optional. Confines the server to a single Sentry organization. When set, every tool that takes an organization_slug is forced to this value and a request targeting a different organization is rejected. The list_organizations tool stays unrestricted so it can still be used for discovery. Leave empty for unrestricted access, bounded only by the OAuth token. The slug is the URL segment at sentry.io/organizations/<slug>, not the display name.

    user_oauth

    provider_name (the Sentry OAuth provider you configured) and the required scopes (org:read, project:read, and event:read, which cover all tools). Do not list a scope the OAuth provider does not grant.

  6. If the form shows Queryable, Enabled is on. Turn it off unless your agents need the two SQL tools. See Expose Sentry data as SQL tables.

  7. Click Create server.

To add code mode, create a Code MCP server that includes this server. Click the Code MCP card in the marketplace, or click Add to Code MCP on this server’s Overview tab and choose an existing Code MCP or New Code MCP. From the CLI, run rpk ai mcp-server create <code-mcp-name> --enabled --code.mcp-servers <server-name>.

Configure from the CLI

Use rpk ai to create the server with a managed config. Set the OAuth provider and scopes inside the --managed.config JSON. Per-user OAuth is the only supported authentication method.

  • Unrestricted

  • Confined to one organization

The caller supplies the organization on each call, bounded only by the OAuth token’s access.

rpk ai mcp-server create acme-sentry --enabled --managed.config '{
  "@type": "type.googleapis.com/redpanda.mcps.sentry.v1.SentryMCPConfig",
  "user_oauth": {
    "provider_name": "sentry-prod",
    "required_scopes": ["org:read", "project:read", "event:read"]
  }
}'

Pin the server to a single organization with organization_slug.

rpk ai mcp-server create acme-sentry --enabled --managed.config '{
  "@type": "type.googleapis.com/redpanda.mcps.sentry.v1.SentryMCPConfig",
  "organization_slug": "my-org",
  "user_oauth": {
    "provider_name": "sentry-prod",
    "required_scopes": ["org:read", "project:read", "event:read"]
  }
}'

Tools

The Sentry MCP exposes read-only tools, grouped by the diagnose-and-fix flow:

Tool Description

list_organizations

List the Sentry organizations the token can access. Used for discovery. Never restricted by organization_slug.

list_projects

List the projects within an organization.

list_issues

List a project’s issues, filtered by a Sentry search query (for example, is:unresolved).

get_issue

Fetch issue detail by numeric ID or short ID (for example, WEB-1).

get_issue_latest_event

Return the most recent event for an issue, including its exception stack trace.

list_issue_events

List the individual occurrences of an issue (compare a failing against a passing event).

get_issue_event

Return one event of an issue with a full stack trace, by ID or the alias latest, oldest, or recommended (oldest is the regression boundary).

get_event

Fetch an event by ID within a project, plus the issue ID it belongs to.

resolve_event_id

Resolve a bare event ID to its issue and project at organization scope.

get_issue_tag

Return the distribution of one tag (for example, release, environment, browser, or OS) for an issue.

list_issue_tag_values

List the full set of values behind a tag’s capped top values.

list_issue_hashes

List the issue’s grouping hashes. More than one hash means several crash signatures.

get_event_committers

Return the commits and authors Sentry deems most likely responsible (suspect commits). Requires a source-code integration. Returns empty when none is configured.

list_releases

List an organization’s releases. Line an issue’s first-seen date up against a deploy.

get_release

Return a single release’s detail by version.

list_release_commits

List the commits that shipped in a release (the candidate changes behind a regression).

Tool examples

List the organizations you can read:

curl -s https://aigw.<cluster-id>.clusters.rdpa.co/mcp/v1/acme-sentry \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": { "name": "list_organizations", "arguments": {} }
  }'

Replace <cluster-id> with your cluster ID and $TOKEN with a gateway access token.

Find unresolved issues in a project:

curl -s https://aigw.<cluster-id>.clusters.rdpa.co/mcp/v1/acme-sentry \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "list_issues",
      "arguments": {
        "organization_slug": "my-org",
        "project_slug": "web",
        "query": "is:unresolved",
        "stats_period": "24h"
      }
    }
  }'

Read an issue’s latest event and stack trace. This is the diagnostic step. The latest event carries the exception stack trace the agent reasons over.

curl -s https://aigw.<cluster-id>.clusters.rdpa.co/mcp/v1/acme-sentry \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "get_issue_latest_event",
      "arguments": {
        "organization_slug": "my-org",
        "issue_id": "WEB-1"
      }
    }
  }'

Expose Sentry data as SQL tables

The Sentry server can also present its read operations as read-only SQL tables, so an agent can filter records the way it would query a database. SQL exposure is the Enabled toggle under Queryable in the server’s configuration. If SQL tools are available in your organization, the create form shows Queryable with Enabled on, so a server you create there is queryable unless you turn it off. Otherwise the form doesn’t show Queryable, and the server starts with SQL exposure off. Creating a server with rpk ai leaves SQL exposure off unless the managed configuration sets it. An existing server keeps the setting it was saved with. To change it, open the server’s edit form, which shows Queryable if SQL tools are available in your organization or if the server was saved with SQL exposure on. SQL exposure adds two tools:

  • list_tables: Return the table catalog. For each table, the catalog lists its columns and their types, which columns can be filtered and with which operators, whether each filter is exact, the page-size limit, and a schema fingerprint that every query response repeats so a caller can tell when the catalog changed.

  • execute_query: Run one query against a table and return a page of rows plus a cursor for the next page.

The tables are:

Table Contents

organizations

The Sentry organizations the connected user belongs to. The table offers no filters, and the server’s organization_slug restriction doesn’t narrow it, matching list_organizations.

projects

The projects of one organization.

issues

The issues of one project. Every query has to filter on project_slug. The table holds unresolved issues only, because Sentry applies is:unresolved when no search query is sent, so a filter on a resolved status matches no row. Use list_issues with a search query to read other issues.

issue_events

The events of one issue, without stack traces. Every query has to filter on issue_id.

issue_tag_values

The values of one tag key on one issue. Every query has to filter on both issue_id and key.

issue_hashes

The grouping hashes of one issue, each with the ID of its latest event. Every query has to filter on issue_id.

releases

The releases of one organization. You can filter on version, but not exactly, because Sentry matches it as a case-insensitive substring. Re-apply that filter to the rows you read back.

release_commits

The commits associated with one release. Every query has to filter on version.

Every table except organizations is scoped to one organization. On a server without an organization_slug restriction, a query also has to filter on organization_slug. On a restricted server, the server fills it in. The required filters and the organization_slug filter are exact. A page holds at most 100 rows on every table.

The tools that read a single issue, event, or release stay plain tools, along with get_issue_tag and get_event_committers.

With SQL exposure on, the two tools are available to every caller of the server, including agents. Turn off Enabled on a server whose agents should only reach the curated Sentry tools.

To trim the catalog table by table, hide columns, require filters, retype a column, or serve a table under another name, use the SQL exposure tab on the server’s page. That tab works the same way for every managed type that offers SQL tables. See Narrow what the SQL tools expose. If the server’s page has no SQL exposure tab, narrowing isn’t enabled for your organization. The Enabled setting on the server’s configuration still turns the two SQL tools on and off.

Troubleshooting

Common symptoms and fixes:

Symptom What to check

connection_required

First call from a user with no stored token. The user completes Sentry’s OAuth consent flow, the token lands in the vault, and subsequent calls reuse it. See User-delegated OAuth.

scope_upgrade_required

The server’s required_scopes was extended after users had already consented. Users re-consent to grant the missing scope. If the error persists after re-consenting, the server requires a scope the Sentry application can’t grant. Compare the server’s required_scopes against the provider’s scopes and remove any that the provider does not list.

A request is rejected naming two organization slugs

The server is confined with organization_slug and the call targeted a different organization. Target the pinned organization, or use an unrestricted server.

get_event_committers returns empty

Sentry has no source-code integration configured for the project, so it cannot attribute suspect commits. Configure a source-code integration in Sentry.

Limitations

This page does not cover:

  • Write operations: Resolving or ignoring issues, commenting, and managing alerts are deliberately absent. The server is read-only.

  • Self-hosted Sentry: The server connects to sentry.io only.

Next steps