Skip to main content
AppSignal MCP is currently in preview. Join our Discord community to help test and shape this implementation.
Model Context Protocol (MCP) enables AI agents and AI code editors like Claude, Cursor, Windsurf, Zed, VS Code, and GitHub Copilot to interact with external tools and data sources. AppSignal MCP gives those agents direct access to your monitoring data: errors, traces, logs, metrics, and more. AppSignal MCP is a public HTTP endpoint at https://appsignal.com/api/mcp. Most agents connect to it directly. If you’d rather run a local proxy — for example, in an environment that restricts outbound traffic — an optional Docker image is available.

What you can access

AppSignal MCP exposes read and write access to your monitoring data across seven areas. Each area maps to a permission you can configure when authenticating: with an MCP token, set each area to read, write, or disabled; with OAuth, all read and write tools are exposed at once. What you get back depends on what your apps send to AppSignal. If your app is not sending logs, get_log_lines will not return anything. AppSignal MCP is a gateway to data AppSignal already has. It does not collect new data on its own.

Available now

  • Error incidents (read + write): list and search exceptions, inspect stack traces, update state and severity, assign handlers, and add notes
  • Performance (read): rank slowest actions, pull traces, walk span trees, and inspect span attributes. Sample-based for standard Ruby and Elixir apps; OpenTelemetry traces for apps sending OTel data
  • Anomaly detection (read + write): browse alerts, list existing triggers, and create, update, or archive triggers
  • Logging (read + write): query log lines with AppSignal’s expression syntax, and set up log ingestion rules: filter, trigger, and metrics actions. Particularly powerful for stitching together a customer journey across log sources, errors, and traces in one prompt — see reconstructing a customer journey
  • Metrics (read): discover metric categories (including host_metrics), list metric names and tags, and pull timeseries or aggregated values
  • Dashboards (read + write): create dashboards, and add or update chart visuals
  • App discovery (read): list your applications, environments, namespaces, users, notifiers, log sources, log line actions, deploy markers, and uptime monitors
For the full list of tools, parameters, and example prompts, see the MCP Tool Reference.

Outside the toolset’s scope

A few AppSignal features are intentionally not exposed through dedicated MCP tools. In most cases there’s already a better way to access the data, or a natural-language interface isn’t the right fit for the job. Every tool exposed also takes up space in your agent’s context, so we’d rather keep the toolset focused than mirror every part of the app.
  • Uptime monitor management: creating or changing uptime monitors is not exposed. You can still list your monitors and their settings through get_app_resources. Uptime results are stored as metrics (uptime_monitor_error_count and uptime_monitor_duration), so you can compute uptime yourself through the metrics tools (get_metric_names, get_metric_tags, get_metrics_timeseries, and get_metrics_list).
  • Notifier, user, and deploy marker management: creating or modifying these requires owner-level permissions and has real consequences: a misinterpreted prompt could grant the wrong person access or misroute alerts. Admin operations like these are better handled in the AppSignal UI, where they’re explicit and easy to audit. You can still read notifiers, users, and deploy markers through get_app_resources.
  • Custom metric and signal ingestion: AppSignal’s ingest path runs on dedicated endpoints optimized for high-throughput delivery, and AppSignal MCP is not designed for pushing data. To send custom metrics, use the AppSignal integration in your application.

On the roadmap if there’s demand

  • Process monitor querying: read access to cron and heartbeat process monitor data. We’d like to gauge interest before adding this.
These are current stances and can change as the way agents work evolves. If you hit a wall with the current toolset, let us know in the Discord community so we can weigh it against the list.

Authentication

You need an AppSignal account to get started. AppSignal MCP supports two authentication methods — pick whichever fits the AI agent you’re configuring:
  • OAuth — sign in with your AppSignal account once. Access is granted at the application level and exposes all read and write tools at once. The recommended path for GitHub Copilot CLI, and the simplest setup for editors that natively support remote MCP servers (Claude Code, VS Code) or that can run mcp-remote as a bridge (Cursor, Windsurf, Zed).
  • Bearer token — generate a long-lived MCP token with fine-grained permissions per toolset. Each token can be set to read, write, or disabled per area, scoped to specific applications, and configured to automatically expose new tools as they ship. Best when you want to limit what an agent can do.
If you’re getting started and your agent supports OAuth, that’s the quicker path. If you need per-tool permissions or per-app scoping, generate an MCP token instead. To generate a Bearer token:
  1. Select your profile icon.
  2. Go to Account Settings.
  3. Select MCP Tokens to create a new token.
The token form has two long checklists: the applications to scope the token to, and the permissions to expose. Each list has a Select all toggle in its header that checks or clears every box at once.

Configuration

Configure AppSignal MCP in your AI agent’s settings using the HTTP endpoint https://appsignal.com/api/mcp. Each section below has tabs for OAuth and Bearer token — pick whichever you set up above.
OAuth support is new across our supported editors. If the OAuth tab errors out for your editor, fall back to the Bearer token tab and let us know in our Discord community so we can tighten these instructions.

Claude Code

With OAuth, Claude Code starts the browser-based sign-in flow the first time AppSignal tools are invoked. See the Claude Code MCP docs for transport flags and CLI reference.

Cursor

Edit ~/.cursor/mcp.json:
The OAuth setup uses mcp-remote as a local bridge to the HTTP endpoint. The browser-based sign-in flow opens the first time Cursor connects. See the Cursor MCP docs for the full schema.

Windsurf

Edit ~/.codeium/windsurf/mcp_config.json:
See the Windsurf MCP docs for the full schema and OAuth notes.

Zed

Open your Zed settings file and add the context_servers section:
When the Authorization header is omitted, Zed initiates the standard MCP OAuth flow against AppSignal. See the Zed MCP docs for the full context_servers schema.

VS Code

If you are running GitHub Copilot and are signed in under a company account, make sure to set “MCP servers in Copilot” to “Enabled” under your organization settings > Copilot > Policies. GitHub Copilot settings Add this to your .vscode/mcp.json:
With OAuth, VS Code initiates the sign-in flow the first time AppSignal tools are used. See the VS Code MCP docs for input variables and headers.

GitHub Copilot CLI

The GitHub Copilot CLI uses OAuth for MCP authentication. Run the following to add AppSignal:
Bash
Follow the OAuth prompt to authorize AppSignal. Once connected, AppSignal tools will be available in Copilot CLI sessions. See the GitHub Copilot CLI MCP docs for the interactive /mcp add flow and config file location.

Gemini CLI

Gemini CLI reads MCP servers from ~/.gemini/settings.json (user-level) or .gemini/settings.json in a project. Add AppSignal under mcpServers:
Leave headers out to use OAuth: when the endpoint returns 401, Gemini CLI discovers the flow and opens the browser sign-in. You can also add the server from the command line with gemini mcp add appsignal https://appsignal.com/api/mcp. See the Gemini CLI MCP docs for the full mcpServers schema and gemini mcp commands.

Verify the connection

After adding the server, confirm your agent can reach it before you rely on it.
  • Claude Code: run claude mcp list — AppSignal should show as ✔ Connected — or run /mcp inside a session to inspect the server and its tools.
  • Other editors: open the MCP or context-server panel in the editor’s settings, where AppSignal should appear as connected.
Then try a prompt that calls a read tool, such as “List my AppSignal applications”. A list of your app_name/app_environment pairs confirms the tools are working. If the agent reports no applications, check that you authorized the right organization during OAuth, or that your MCP token is scoped to the applications you expect.

Usage, logging, and data handling

Rate limits and account access

AppSignal applies no rate limit specific to MCP. Tool calls run through the same infrastructure as the rest of appsignal.com and share its general protections. What gates access is your account’s plan. A locked account, or a free account past its trial and usage limit, gets an error instead of data — the same restriction the rest of the AppSignal API uses.

What AppSignal MCP logs

AppSignal logs each tool call for reliability and abuse prevention: the tool name, the arguments you pass, and your account and user IDs. get_more_tools also logs the capability you asked for. Your email and organization name can appear in a tool’s reply, but the log stores IDs, not those. Because arguments are logged, don’t pass secrets in free-text parameters such as log queries. MCP logs follow AppSignal’s general log retention; there is no separate retention window for MCP.

Data handling and compliance

MCP reads and writes the same data as the rest of AppSignal, so it inherits AppSignal’s data handling. AppSignal is GDPR compliant, ISO/IEC 27001 certified, and hosts data in the EU. HIPAA coverage is available through a Business Associate Agreement add-on. For the details, see GDPR, Security, and Business add-ons.

Troubleshooting

The server won’t connect, or OAuth fails

Fall back to a Bearer token. Generate an MCP token and use the Bearer token tab for your editor. In Claude Code:
Bash
Then run claude mcp list to confirm AppSignal shows as connected.

No applications show up

Your OAuth sign-in authorized a different organization, or your MCP token isn’t scoped to the apps you expect. Ask the agent to “list my AppSignal applications”. If the list is empty or missing apps, sign in again and pick the right organization, or regenerate the token with those applications selected.

”Application not found”

app_name and app_environment are matched case-insensitively, but they must otherwise match an app you can access. The error lists those applications — retry with an exact name and environment from the list.

A tool call reports that access is restricted

Your account is locked, or a free account has passed its trial and usage limit. MCP uses the same access rules as the rest of the AppSignal API. Resolve the plan or billing state, then retry.

A tool you expect is missing

An MCP token exposes only the toolsets you selected when you created it. A token created before a tool shipped won’t include it unless you set the token to expose new tools automatically. Regenerate the token, or create one with the toolset enabled. OAuth exposes all read and write tools, so switch to OAuth if you want everything.

GitHub Copilot in VS Code shows no MCP servers

On Copilot Business or Enterprise, MCP servers are disabled by default and gated by an organization policy. An org owner sets Settings → Copilot → Policies → Features → MCP servers in Copilot to Enabled, then reconnect.

Getting Help

We encourage you to join our Discord community where you can:
  • Get help with AppSignal MCP setup
  • Share feedback and suggestions
  • Connect with other developers using AppSignal MCP
  • Stay updated on new features and improvements
Look for the dedicated #mcp channel where our team actively monitors and responds to questions.