There's a recurring problem when working with an AI assistant on debugging: the AI doesn't know what's happening in production. It can read the code, analyze a stack trace you paste into the chat, suggest directions — but it's working blind. Without access to actual errors, logs, and events from the runtime environment, it's guessing.
That's not a limitation of the model. It's a limitation of tool access.
This is exactly the problem MCP addresses. And it's what led me to integrate Sentry and GlitchTip directly into my AI workflow.
Why AI agents need access to observability tools
When a bug surfaces in production, the useful context goes beyond the source code. It includes the exact stack trace, event data at the moment of failure, occurrence count, affected environments, and sometimes breadcrumbs showing the path taken before the crash.
Today, that context stays siloed in separate tools — Sentry, GlitchTip, Datadog, whatever you use. Getting to it means opening a tab, finding the error, copying the stack trace, switching back to the editor, pasting it into the chat. That's a manual round-trip that breaks the workflow and reduces the AI agent to a text suggestion tool rather than a real debugging collaborator.
MCP — Model Context Protocol — changes this equation. It lets the AI agent connect directly to these tools and fetch the information it needs on its own. Instead of handing it a stack trace, it can read one. Instead of describing unusual behavior, it can pull the recent events and see for itself.
The benefit isn't just saved time. It's a qualitative improvement in reasoning: the AI works from real data, not an approximation I've constructed.
Why I chose GlitchTip
Sentry is the reference tool for error monitoring. I use it on client projects that already benefit from SaaS infrastructure and have no hosting constraints. But on my own projects — including this site and several internal tools — I needed a self-hosted alternative.
GlitchTip fit for several reasons. It's compatible with the Sentry API, which means existing Sentry SDKs work without modification. That compatibility matters: it avoids having to choose between two ecosystems and allows migration without rewriting the application side. GlitchTip deploys with Docker in minutes, the interface is clean and functional, and the project is open source with an active community.
It's not a perfect Sentry replacement — some of Sentry's advanced features don't exist in GlitchTip. But for capturing errors, organizing them by project, and exposing them via MCP to an AI agent, it's more than enough. And controlling your own hosting changes the equation on projects where data privacy is a concern.
Why MCP over manual integration?
Before MCP, I'd tried different approaches to give AI context: copy-pasting stack traces, scripts to export errors as Markdown, sometimes even system prompts describing the application state. All of that worked, but with friction. Response quality depended directly on the quality and completeness of the context I provided — and I was the one who had to build that context.
MCP shifts that responsibility. The agent can now query Sentry or GlitchTip when it needs to, with whatever parameters it finds relevant. That's a difference in kind, not degree.
Configuration in Codex
Codex from OpenAI supports MCP via a JSON configuration file. Here's the configuration I use for Sentry:
{
"mcpServers": {
"sentry": {
"command": "npx",
"args": ["-y", "@sentry/mcp-server@latest"],
"env": {
"SENTRY_AUTH_TOKEN": "your-token"
}
}
}
}
The Sentry token needs read access to the relevant projects. I avoid creating a token with write permissions — the agent doesn't need to create or modify issues, only read them.
Configuration in Claude Code
Claude Code manages MCP via .claude/settings.json. This is the configuration I use day-to-day, both for Sentry on client projects and GlitchTip on personal ones:
{
"mcpServers": {
"glitchtip": {
"command": "npx",
"args": ["-y", "glitchtip-mcp-server"],
"env": {
"GLITCHTIP_TOKEN": "your-token",
"GLITCHTIP_URL": "https://your-instance.glitchtip.com"
}
}
}
}
The URL points to your self-hosted instance. If you're using GlitchTip Cloud, use the URL provided when you created the account.
Configuration in VS Code
VS Code uses a .vscode/mcp.json file at the project root. The structure is identical, only the root key changes:
{
"servers": {
"sentry": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@sentry/mcp-server@latest"],
"env": {
"SENTRY_AUTH_TOKEN": "your-token"
}
}
}
}
One practical note: I prefer using Sentry's project auto-discover rather than hardcoding an organization in the config. It avoids maintaining project-specific values and keeps the configuration more portable across repos.
Limits and things to watch out for
A few things worth considering before adopting this setup in production.
Token security. API tokens should never appear in a Git repository. For Claude Code, .claude/settings.json must be in .gitignore whenever it contains sensitive values. Prefer environment variables or a secrets manager over plaintext values in config files.
Scope of access. An AI agent that can read your production errors has access to potentially sensitive data: error messages, request parameters, user information captured in breadcrumbs. Before opening that access to an agent, verify that what you're sending to Sentry or GlitchTip doesn't include unnecessary personal data.
Shared access management. On team projects, the question of who can use which MCP token comes up quickly. It's better to define a clear policy upfront rather than letting everyone create their own tokens with inconsistent permissions.
Overconfidence in AI. This is probably the most important point. Giving the agent direct access to production errors improves its diagnostic capability — but it doesn't make it infallible. It can misread an event, overlook context that isn't visible in the Sentry data, or suggest a fix that resolves the symptom without addressing the cause. Tool access improves AI reasoning; it doesn't replace human judgment.
What I take away from this
What struck me most about this integration isn't the configuration itself — it's fairly straightforward. It's the change in working posture it produces.
When the agent can access errors directly, the debugging conversation changes in nature. You don't start by describing the problem — you start by asking the agent to look at what happened. It pulls the recent events, identifies patterns, asks questions about the relevant code. The flow feels more natural and the exchanges are denser with useful information.
Does it replace debugging work? No. Does it change it? Yes, meaningfully.
Observability hasn't always been seen as a development tool — more as an operations or SRE concern. MCP integration blurs that boundary. A production error becomes accessible in the same context as the source code, without switching tools and without losing the thread of the conversation with the agent. It's a modest shift in the toolchain, but it changes how you think about the develop-deploy-fix cycle.
As AI agents become more embedded in development workflows, their ability to reach the right tools at the right moment will matter as much as their ability to reason about code. MCP is a serious first answer to that need. It probably won't be the last.