How to connect a Sentry MCP to Cursor (4 steps)

Developers building tools that integrate with Sentry, such as an alert routing system that pages the right team based on error context, need to understand Sentry's data model while writing the code.

What are the valid project slugs for API endpoint paths? What does a Sentry event payload actually contain, and how are exception frames structured? What condition types does Sentry accept when creating alert rules programmatically?

Without the MCP connection, answering those questions means leaving Cursor, authenticating against Sentry's API separately, running test calls, and copying responses back into the session where the integration code is being written.

To help your developers inspect Sentry's data model and query real project data without leaving Cursor, we'll show you how to connect Sentry with Merge Agent Handler's Sentry MCP server.

How it works

Merge Agent Handler connects Cursor to the Sentry API through the Merge CLI.

Install the CLI, authenticate once, and run a single setup command from your project root.

That command writes a ## Merge CLI section to the project's .cursorrules file, which tells Cursor's agent when to call merge search-tools and merge execute-tool to reach Sentry.

Once connected, Merge handles Sentry's authentication token lifecycle so you never store API credentials locally or rewire auth when tokens change.

Here's the registration command:

merge setup cursor

Prerequisites

Before getting started, you'll need the following:

• A Merge Agent Handler account
• Cursor installed
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A Sentry account with access to the organization and projects you want to query

If you want to connect Merge Agent Handler's Sentry MCP with internal or customer-facing agentic products, you can follow the steps in our docs.

1. Install the Merge CLI

Run the following to install the Merge CLI: pipx install merge-api

Verify your installation: merge --version

Related: How to use the Sentry MCP in Claude Code

2. Log in to Merge

Authenticate the CLI with your Merge Agent Handler account: merge login

This links the CLI to your account so it can make authorized requests to Sentry on your behalf.

3. Connect the CLI to Cursor

Run the following from the root of the project where you want to use Merge tools:

merge setup cursor

This writes a ## Merge CLI section to .cursorrules so Cursor knows to use the CLI for third-party services. The command is idempotent, safe to re-run if you need to reset.

4. Authenticate Sentry

Open a Cursor chat in your project and start with a query that reflects real integration work. For example: "Fetch the list of projects in my Sentry organization, including their slugs, platform types, and team assignments, so I can write correct API endpoint paths in my integration."

The first time you invoke a Sentry tool, a Magic Link will appear to complete connector authentication.

{{this-blog-only-cta}}

Sentry MCP FAQ

In case you have more questions on setting up and using the Sentry MCP in Cursor, we've addressed several more commonly-asked questions below.

What can you do once the Sentry MCP is connected to Cursor?

With Sentry connected, Cursor can:

• Fetch project slugs before writing API call code: retrieve the exact slug identifiers for each project in your Sentry organization before writing endpoint paths or query parameters that target specific projects, so API calls are correctly formed from the first request

• Inspect event payload structure before writing parsers: pull a sample event from a recent issue to see the actual JSON shape, including exception frames, breadcrumbs, and context fields, before writing code that parses or transforms Sentry event data

• Check alert rule condition formats before writing alert automation: retrieve the condition types and threshold configurations of existing alert rules before writing code that creates or modifies alert rules programmatically, so condition payloads match what Sentry's API accepts

• Validate tag keys and value formats before writing filter logic: fetch the tag schema and sample tag values for a project before writing code that filters issues by tag, so filter expressions match the actual key names and value formats in the workspace

• Look up team identifiers before writing issue assignment code: query the list of teams and their slugs before writing code that routes alerts or assigns issues to specific teams, so team references in API payloads are correct

• Retrieve release object structure before writing release-tracking integrations: inspect the fields and format of recent release objects before writing code that creates releases or associates commits with them, so payload structure matches what the API expects

Why use Merge Agent Handler vs. a self-hosted Sentry MCP server?

You can connect directly to Sentry's API using an auth token. Sentry's REST API is well-documented, token generation is straightforward, and for a single developer building against their own organization the setup is fast.

The access control problem appears when you scale beyond one developer or one agent.

A Sentry auth token carries the permissions of the account that generated it. Sharing it across agents or team members means every agent operates with the same level of access, with no way to restrict which projects or operations a given agent can reach. Rotating the token requires updating every system that holds it at once.

Merge Agent Handler handles Sentry authentication centrally.

You define exactly which Sentry operations each agent is allowed to call. Every call is also logged with the timestamp, tool, and inputs, so you have a full audit trail of what each agent read or modified.

For teams running multiple agents against a shared Sentry organization, that combination of scoped access and central logging is the difference between a controlled deployment and a shared credential problem.

Why connect Sentry to Cursor?

Sentry's API data isn't something you can accurately reconstruct from documentation alone.

These values are organization-specific: slug identifiers differ across environments, tag schemas reflect what your instrumentation actually emits, and alert rule conditions reflect the exact threshold types your organization has configured.

Connecting Sentry to Cursor puts that discovery step inside the editor.