MCP or CLI? Yes.

Let’s stop debating it and just lean in: you can have both.

curl https://cli.sentry.dev/install -fsS | bash

sentry auth login

claude mcp add sentry -- sentry mcp

Sentry is now shipping a unified experience that bridges the gap, and we think its the right solution right now for agents with access to sandboxes.

You’re probably immediately asking why? Probably because you think CLI is superior (its not btw).

There’s a few key reasons which I’ll dive into, but in a nutshell:

1. Shared authentication, and controlling the flow is valuable in some scenarios (but it has limitations!)
2. The CLI can do things MCP can’t, and MCP is still the superior agentic tooling.
3. MCP implementations still widely differ, and I dont see its capabilities being able to fully replace CLI.

I’ll try to cover a bit in depth on each, with our thinking behind it, and how the implementation works under the hood.

Shared Authentication

This ones mostly straight forward, and its arguably the main value we’re bringing with this bridge.

sentry mcp

Behind the scenes this is effectively just launching the MCP server in stdio mode. The primary difference is it adds a shim to share the credentials used by CLI. In our case we already did this behind the scenes, but it was implicit, where its not explicit.

This means that you can easily authenticate via the standard CLI methods (generally a device code flow) and itll pass that through.

Behind the scenes the way we do this, because it needs to bypass CIMD/DCR, is we have a different token header. Sentry is setup to where the MCP server is an entirely different service that proxies our OAuth provider (layers on its own functionality, adds CIMD/DCR). That means if you send a bearer token to it its going to assume its following those constraints. Instead, we allow you to specify an alternative token type which completely bypasses the auth (Sentry-Bearer vs Bearer).

Pretty straight forward, but the biggest advantage here is that any of the historical authentication bugs in MCP are no longer present, because we control the authentication flow.

Its not the perfect solution.

One of the great advantages MCP brings is consolidated authentication, which means you can do things like layer in organization-wide authentication. It also generally makes it so usptream clients can implement native handling of tokens (think storage), as well as the authentication flows. In practice a lot of those flows are still pertty sloppy, but without that consolidation you end up with what we’ve done here: one-offs.

For something like Sentry that might be ok - you use it daily, its probably one of the more high-engagement developer tools in that lifecycle - but I dont think this is the long term solution to the problem.

Differening Capabilities

Under the hood our CLI and MCP server share a lot, but they also offer different raw capabilities and one cannot replace the other. I’ll give you two examples.

First, the CLI has a filesystem. That is extremely powerful in some domains like ours. For example, say you want to ask some questions session replays (which are a large number of events that happen in a sequence). We could expose some search endpoints on the server, but you’re not going to be able to inject reasoning into them. What would be better is if you had access to the raw event log, some context so the agent knows how to address them, and then could token-efficiently fetch the data as you need it. Grabbing chunks of events at a time, grepping through it, paginating.

That cannot be done with MCP, unless you (very inefficiently) were to try to implement those same behaviors on the server. Its just not worth it, which is why everyone leans on pre-aggregation, search APIs, etc. The future is more sandboxes, less limited APIs.

On the other hand, the agent does not even know the CLI exists by default. The advantage of the MCP is its native. It has native steering, native tool call capabilities. The agent discovers behavior without you telling it to, without you telling it how. It discovers how to use the behavior natively. To make the CLI work you need to tell it that it exists, it then needs to look up how to use the CLI, what commands are available. Just like our authentication limitations, its the same here. You’re trading off a known quantity behavior for a one-off custom behavior every time.

One of the interesting things I think you can do by combining both capabilities. We know when we launch the MCP server from the CLI, which means the MCP server can change its behavior. It can inject steering to make it known how to use the CLI. For example, maybe there’s a tool call that is get_session_replay. The response of that tool call can now tell you to use the CLI to fetch additional details and how to do it efficiently.

We haven’t implemented this transport-specific steering yet, but its definitely top of mind for us as we work to maximize the effectiveness of the headless tooling.

MCP Inconsistencies

If you’ve implemented any aspect of MCP, you’ve likely experienced both the sheer complexity and breadth of the spec, as well as the fact that even the major harnesses implement things quite differently. One of the most important and still common differences is tool search. A lot of major harnesses now do deferred tool calling - that is they dont load all of the tools up front. Thats important to know because that means you can optimize differently - you can load a lot more tools, you might change steering patterns. But wait, what about search? How does each harness implement search? What about the clients who dont implement deferred tool calling and search?

Thats the most in-your-face consistency, and its slowly improving, but a large majority of the MCP spec is effectively unadopted. Some of its now deprecated, some of it certainly will be deprecated in the future, but it leaves you in a pickle if you want to consider any bheavior beyond tool calling itself.

One extremely relevant example is the instructions metadata. This is a newer addition (afaik) which allows you to give some baseline steering to the model for your MCP server. This is unbelievably important, but its not uniformly supported across even frontier harnesses.

Another recent example is MCP Events. These seem like a great idea, but they’re largely not usable today. Either they’re not implemented or they’re implemented in such a domain specific way that its hard for you - the author of an MCP server - to rely on them for any customer facing behavior.

MCP ultimately has this complex identity crisis which I believe triggers a lot of this: the frontier harnesses expect you to use MCP to integrate into their ecosystem (to build on top of their harness) in a very specific way, and that specific way might not be how users want it to behave (organically) or how vendors want it to integrate. A great piece of research here if you’re not familiar: look into how Claude Desktop works, or how T3 Code works. They’re effectively, largely, just MCP servers and they’re building on top of a frontier harness.

Time Will Tell

This is a new experiment for us, but like all past experiments its built to work around the limitations of today. Those limitations often disappear or change within months, which means you’re going to always be adapting. That’s the requirement of doing business in the agentic era.

If you do end up trying out the new flow, we’d love to hear your feedback. We’re working on shifting onboarding to suggest a CLI-based approach (vs a plugin-based approach) right now, as we think this is the least compromise and most user-friendly experience we can deliver.