I’ve been running a few experiments to streamline our development workflow, and I keep talking with folks on teams who haven’t been granted the budget or access to this kind of tooling yet. So I’m writing some of these up to help demystify what the experience is actually like.
For this one.. I wanted to see if I could take an AppSignal error and go from alert → fix → deploy without leaving the terminal.
Using Claude Code and AppSignal’s MCP integration, the whole process took under five minutes.
For context, our Rails app is already configured with AppSignal and has been running in production for a while. Like many teams, there are a few low-priority errors that pop up from time to time, but aren’t mission-critical enough to demand immediate attention. The kind of thing where you’d normally open AppSignal in a browser, copy the stack trace, switch to your editor, dig around, and by the time you’ve context-switched three times you’ve lost 30 minutes and your train of thought.
Here’s how I was able to handle one of those lingering errors without leaving the terminal.
Step 1: Install AppSignal’s MCP
I popped over to AppSignal’s MCP docs. Okay, I used a browser for this part.
I’m familiar enough with installing MCPs, but noticed that AppSignal’s MCP requires Docker to run it. I don’t know if this will be the case long-term, but I already had Docker running on my laptop so it wasn’t an issue.
I jumped down to their “Claude Code” instructions… which proposed:
% claude mcp add appsignal -e APPSIGNAL_API_KEY=your_api_key_here -- docker run -i --rm -e APPSIGNAL_API_KEY appsignal/mcp
I didn’t like the idea of adding the API key into my zsh command history, so I opted to add the API key to my project’s .env file, which is already being used by the Rails app, and then referenced it like so:
% claude mcp add appsignal -e APPSIGNAL_API_KEY=$APPSIGNAL_API_KEY -- docker run -i --rm -e APPSIGNAL_API_KEY appsignal/mcp
Added stdio MCP server appsignal with command: docker run -i --rm -e APPSIGNAL_API_KEY appsignal/mcp to local config
File modified: /Users/robbyrussell/.claude.json [project: /Users/robbyrussell/projects/project-name]
Step 2: Test the MCP connection
Next, I opened up Claude Code and ran /mcp to see if the connection was working. I was able to see the AppSignal MCP listed and was connected.
❯ appsignal · ✔ connected
Instead of digging through the docs, I tried the obvious command:
Fetch details on AppSignal error 342
(Note: my first attempt was “Error #3342” — a typo that returned no results. Being precise with incident numbers saves a roundtrip.)
To my delight, the MCP integration retrieved the full error details from AppSignal, including the stack trace, exception type, and timeline of when it first and most recently occurred. A positive starting point.
For some context, this looked related to some bot-crawler behavior. Something related to authenticity tokens. Again, it didn’t feel like a critical error, hence why it had been lingering for a while. But I was curious to understand the root cause and potential fixes.
Step 3: Collaborate on a solution
Next, I was eager to task Claude with helping me understand the severity and potential fixes for this error. I prompted Claude with the following:
How can we handle this gracefully in Rails?
Claude provided four potential solutions. Some were minor code tweaks, one was to just set it to ignored in AppSignal, another was to modify our middleware or explore something on the Web Application Firewall (WAF) side of things.
Once we narrowed down a solution, I asked Claude to write the code change, run our test suite, commit with a descriptive message (including a link to the AppSignal incident for context), and submit a pull request to our GitHub repository.
My prompt for the first few steps was something like:
please go ahead and implement Option 1 for now and then mark the issue as closed for now in AppSignal.
Step 4: Deploy the fix
Given the non-critical nature of this particular error, I opted to use one of my /review-pr skills to run a fresh PR review on the change that Claude had made. I asked for a summary of the change, then approved the PR and let our pipelines run as normal.
While that was deploying, I logged into the AppSignal dashboard to confirm that particular error was now marked as closed. That way, if it popped up again, it would reopen and alert us again.
No Performance Help… yet
Once this was sorted out, I wanted to see if it could look into performance issues captured by AppSignal, too. Sadly, that doesn’t exist in the MCP as of March 2026.
❯ https://appsignal.com/planet-argon/sites/655d333b83eb671c877e2948/performance/incidents/2
⏺ appsignal - Check for additional tools (MCP)(context: "User wants to view a performance incident from AppSignal. The existing
get_incident tool doesn't seem to support performance incidents (only
exceptions/anomalies). Need to find a tool that can fetch performance incident
details.", description: "I need to fetch performance incident details from AppSignal.
The URL is for a performance incident (not an exception). I need a tool that can
retrieve performance/slow request incident information by incident number.")
⎿ # Tool Request Logged
We've recorded your request for additional tooling capabilities. Your feedback helps us prioritize new tool development.
I’ll be sure to keep an eye on that feature request and update this post if/when it becomes available.
Final thoughts
The interesting part here isn’t this particular error.
It’s the workflow.
By exposing monitoring tools like AppSignal through MCP, tools like Claude Code can retrieve incidents, analyze stack traces, propose fixes, and help ship patches without ever leaving the terminal.
In this case the flow looked like this:
AppSignal alert → investigate → implement fix → open PR → deploy.
Five minutes. No browser tabs. No losing my train of thought.
This is still early territory, but the building blocks are starting to line up. If you’re already using tools like AppSignal, it’s worth experimenting with MCP integrations and seeing what workflows you can streamline.
