You open a monitoring tool, and the data is all there: errors, traces, anomalies, incidents, and countless intricacies. If you want to get the right slice of that data, you need to know exactly which dashboard to open and what filters to apply. But when the poor UI gets in the way, this can take longer than it should.

Luckily, this is not the case with AppSignal.

MCP (Model Context Protocol) changes the interface entirely. Instead of clicking through dashboards, you can ask questions in plain language inside your editor. AppSignal's MCP server exposes your monitoring data (errors, incidents, anomaly alerts, metrics, dashboards) as tools that any MCP-compatible agent can access directly.

TL;DR Getting the right data from a monitoring tool isn’t always easy. When a pipeline is broken and bleeding money, understanding specific patterns, terms, and navigation needs to happen fast. AppSignal has built an MCP that lets you use plain English. Ask for what you need, in your own words, and the agent will figure out which call to make.

What You Can Do With MCP

AppSignal’ MCP exposes multiple tools across five areas. Each of them is mapped to a permission scope that you configure prior to auth.

Full parameter docs for every tool can be found in the MCP Tool Reference.

How to Connect

The AppSignal MCP server is available at a public endpoint: https://appsignal.com/api/mcp

You can connect to the MCP server via two authentication methods:

• OAuth: Sign in with your AppSignal account via browser. This work great for Claude Code, VS Code, and GitHub Copilot CLI and is also the fastest way. For Cursor, Windsurf, and Zed, OAuth works as a local bridge via mcp-remote.
• Bearer token: Generate a long-lived MCP token with granular, per-toolset permissions (read, write, or disabled). The Bearer token can be scoped to specific apps, too. You can generate it in Account Settings > MCP Tokens.

Quick-Start Snippets for Each Editor

Save yourself some time by simply copying and pasting these. 😉

• Claude Code

Tabbed code from https://docs.appsignal.com/mcp.html

• Cursor: Edit ~/.cursor/mcp.json (Cursor MCP docs)

Tabbed code from https://docs.appsignal.com/mcp.html

• Zed: Add to your settings file (Zed MCP docs)

Tabbed code from https://docs.appsignal.com/mcp.html

• VS Code: Add to .vscode/mcp.json (VS Code MCP docs)

Tabbed code from https://docs.appsignal.com/mcp.html

• GitHub Copilot CLI

Tabbed code from https://docs.appsignal.com/mcp.html

Full setup instructions for all editors can be found in the AppSignal MCP docs. A Docker image is also available for environments that restrict outbound traffic (GitHub repo).

Awesome Prompts

Use our own awesome prompts to get started with AppSignal via MCP. Feel free to adjust them depending on your use case.

1. "What applications do I have access to in AppSignal?"

• Calls get_applications.

This is the correct first prompt whenever you're in an unfamiliar codebase. It returns all apps connected to your account in the app_name/app_environment format and helps you get your bearings before you start asking questions about the specific ones.

2. "Give me an overview of what's currently monitored in [app name] production."

• Combines get_app_resources, get_exception_incidents, and get_anomaly_incidents.

This prompt surfaces active incidents, recent anomalies, namespaces, and any open alerts in one go.

3. "Show me all open incidents in [app name] production from the last 24 hours."

• Calls get_exception_incidents with states: "open" and a 24-hour time range.

This serves as a solid starting point for unplanned investigations. It’s scoped to a specific app and environment, with no noise from staging or other namespaces. Yay!

4. "Get the full details and stack trace for incident #[number]."

• Calls get_incident.

This prompt returns everything in one shot: exception type, message, stack trace, sample count, first/last seen timestamps, and any captured parameters or context. It’s a much faster solution than loading the incident page. Plus, the agent can immediately suggest fixes based on the trace.

5. "Find all open incidents from the last week and group them by severity."

• Calls get_exception_incidents with a 7-day range and states: "open".

With this prompt, you get a structured view of what's accumulated. It’s particularly useful before a planning session or a sprint review, when you want to understand the backlog shape before you start assigning work.

6. "Mark incidents #120, #121, and #122 as work in progress and assign them to [name]."

• Calls update_incidents with the incident numbers, state: "wip", and the user ID from get_app_resources.

Here, you’ve got bulk incident management in a single prompt. Thanks to it, there’s no need to click through each incident in order to change status and assign. The agent resolves the user ID automatically if you provide a name.

7. "Show me all open anomaly alerts right now."

• Calls get_anomaly_incidents with state: "open".

You get a snapshot of everything currently firing across all metrics. It’s a good first prompt when you sit down after a few hours away and want to know if anything has gone sideways since you last checked.

8. "Create a dashboard called 'API Health' and add a p95 response time chart broken down by action."

• Calls manage_dashboard to create the dashboard, then get_metric_tags to verify available tags, then create_dashboard_visual with display: "line" and fields: ["p95"] broken down by action tag.

Two API calls are handled in one prompt, and the agent chains them automatically.

9. "What's still open and unassigned going into the weekend?"

• Calls get_exception_incidents with states: "open", then filters for incidents with no assigned handlers.

Run this before closing your laptop on Friday so the on-call rotation knows exactly what they're inheriting.

10. "Add a note to incident #[number] summarizing what we found and what the fix was."

• Calls create_incident_note.

This prompt closes the documentation loop on a specific incident. Notes stay attached in AppSignal so that anyone reviewing it later on has the full context. Markdown is supported, so you can include code snippets or links to the relevant PR.

Next Steps and Resources

These ten awesome prompts cover the core: aviate, navigate, communicate. Or, in the world of monitoring: orient, investigate, triage. However, once you connect to the MCP server, you are not limited to these prompts. Ask whatever makes the most sense for your situation, and the agent will figure out which tools to call.

To get started, chec out AppSignal MCP docs for setup and MCP Tool Reference for the full tool and parameter list. The blog post announcing the MCP server covers the design philosophy in more depth.

No AppSignal account yet? Start a free 30-day trial, no credit card required.

Frequently Asked Questions (FAQ)

1. Which editors and agents does AppSignal MCP work with?

AppSignal MCP is compatible with Claude Desktop, Claude Code, Cursor, Windsurf, Zed, VS Code with GitHub Copilot, and GitHub Copilot CLI. The server uses standard MCP over HTTP, so it works with any MCP-compatible client. Explicit setup instructions for each are found in the MCP docs.

2. Do I need OAuth or a Bearer token? What is the difference?

OAuth is the simpler path (one browser sign-in, all tools available immediately) and works natively in Claude Code, VS Code, and GitHub Copilot CLI. Bearer tokens give you per-toolset permissions and per-app scoping.

3. Can the MCP server write to AppSignal, or is it read-only?

It can do both. Read covers incidents, anomalies, metrics, and app discovery, whereas write includes updating incident state, assigning handlers, adding notes, managing anomaly triggers, and creating dashboards.

4. Is my monitoring data sent to an AI model?

Yes. The agent fetches data from AppSignal and includes it in its context window. This is subject to your AI provider’s data handling policies.

5. What if I ask for something the MCP server does not support yet?

The server will let you know and try to route you to the best solution.