When we launched AppSignal MCP in beta, OAuth was on the roadmap but not yet shipped. We were issuing static bearer tokens — enough to connect Claude Desktop, Cursor, and Windsurf, but not the one-click install path in the MCP Registry, and not GitHub Copilot's recommended setup.

That's fixed.

What Changed

The original beta required Docker. You'd pull appsignal/mcp, add a config block to your editor, paste in a manually generated token, and the container would run locally and proxy requests to AppSignal on your behalf. That path still works for existing Claude Desktop, Cursor, and Windsurf setups, but it's no longer the one we'd recommend. Running a container, managing static tokens, and keeping the image up to date is extra work you don't need to do.

The remote HTTP connection with OAuth is simpler on every dimension. There's no container to pull or keep updated, no token to generate and paste into a config file, and nothing to revoke when someone leaves the team. Your editor talks to mcp.appsignal.com directly, OAuth handles authentication, and access is scoped to the organizations and apps you choose at login time.

OAuth was the model we wanted from the start: scoped access, no static tokens to rotate, no container to keep updated. Now that it's shipped, the MCP Registry's one-click install works, GitHub Copilot's recommended setup is a few lines of config, and every other editor gets a cleaner default.

Connecting Copilot is straightforward: add the server URL to your .vscode/mcp.json, and when you first invoke it, Copilot initiates an OAuth login. You authenticate with your AppSignal account, choose which organization and apps to grant access to, and you're connected.

The same OAuth path is available to Cursor, Windsurf, JetBrains IDEs, and Zed. If you're setting up AppSignal MCP for the first time, or revisiting an existing Docker-based setup, this is the path we'd point you at.

What You Can Do with It

Regardless of which editor you use, the toolset is the same. Since the beta launched, we've expanded the toolset significantly. AppSignal MCP now exposes 24 tools across seven areas.

Performance Traces

Two new tools cover performance investigation end to end.

get_performance gives you a ranked overview of slow actions. For OpenTelemetry apps it shows mean duration, throughput, and error rate across actions; for Ruby and Elixir apps it returns sample-based performance incidents. Either way, you see what's hurting before you dig in.

get_traces takes you deeper. Give it a namespace and action name, and it returns matching traces from a time range. Pass a trace ID to see the full span tree: every database call, external request, and background job, nested by duration. Drill into any span for full attributes and timing.

This now works for errors too. Previously, the MCP server could hand you an exception incident and its metadata, and that was it. With get_traces, you can pass a digest instead of an action name and jump straight into the actual samples: pull multiple traces tied to the same error, walk the span tree for each, and figure out where in the request the failure is really coming from. The incident tells you what broke; the traces let you dig through the tree to find why.

Log Querying and Processing

get_log_lines queries your logs using AppSignal's expression syntax. Filter by severity, hostname, message content, custom attributes, or combinations: severity=error AND hostname=web-1, message:timeout, duration>500. Up to 100 lines per call.

You can also configure how AppSignal processes logs during ingestion. Log line actions run in order and come in three types: filter (discard matching lines), trigger (fire an alert when matched), and metrics (extract a counter, gauge, or distribution from matching lines). reorder_log_line_actions sets the execution order. A useful pattern: put metrics and trigger actions before filter actions. AppSignal captures the signal before discarding the noise.

Anomaly Trigger Management

Previously the MCP server could read triggers but not create them. manage_trigger closes that gap. Specify the metric, field, threshold, comparison operator, warmup and cooldown durations, and the notifier IDs to send alerts to.

Updating a trigger archives the existing one (closing its open alerts) and creates a new one with a version reference back to the old. archive_trigger handles cleanup when a trigger is no longer needed.

Full Coverage

The 24 tools now cover:

• Error incidents - list, search, update state and severity, assign, add notes
• Performance - slow action overview, trace lists, span trees, span detail
• Anomaly detection - browse alerts, list triggers, create and archive triggers
• Logging - query log lines, manage log line actions, set execution order
• Metrics - discover categories, query timeseries, get aggregated values
• Dashboards - create dashboards, add and update chart visuals
• App discovery - list apps, environments, namespaces, users, notifiers, log sources

Setup instructions for GitHub Copilot, Claude, Cursor, Windsurf, Zed, and VS Code are in the AppSignal MCP documentation.

If there's something the MCP server can't do that you'd expect it to, describe the goal to your editor. The server logs those requests and they feed directly into what we build next. Or post in the AppSignal Discord community.