AppSignal MCP went generally available last month. Until now, adding it to the Claude app meant pasting our endpoint URL into a custom connector form.
Now you search for it like any other connector. Open Settings, go to Connectors, select the Discover tab, and search for AppSignal.
- Open the AppSignal connector from the results and selectConnect .
- Sign in to AppSignal to authorize the connector.
- Choose the organization Claude can access and, optionally, limit it to specific applications.
That's the whole setup. For more detail on each step, follow the Claude app section of the setup guide. The connector points at our hosted endpoint, https://appsignal.com/api/mcp, so there's nothing to install and nothing to keep updated. It works the same way in Claude on the web and in the desktop app.
If you'd rather start from the directory page, open the AppSignal listing and select Connect to Claude. That takes you to the same sign-in. Read the listing before you connect. It spells out what the connector reads, what it can write, and every tool it exposes.
One more thing: AppSignal MCP works with the data AppSignal already has. It doesn't collect anything new. What your agent can see depends on what your apps send and the access you grant at sign-in.
#
Ask Claude for a metric timeseries and you get a chart, not a wall of numbers.
get_metrics_timeseries results now render as an interactive AppSignal chart in hosts that support the MCP Apps extension. Those include Claude and ChatGPT. The chart uses the same components as your dashboards, so it matches what you see in AppSignal. In text-only clients, such as Claude Code, Cursor, and Codex, the tool returns the data as Markdown. Your agent answers from it in text, so nothing breaks either way.
This changes how a conversation feels. Ask for "the allocated objects per host over the last hour", and you don't need to read a table line by line. You see a chart you can interpret immediately.
#
Check-in monitors were the most requested gap. get_check_in_triggers and manage_check_in_trigger now cover them.
That means you can ask whether last night's export actually ran, and which runs were late or missed entirely. You can also create a monitor for a new cron job while you're still writing it. You don't have to remember to add it in the AppSignal app UI later. The tools handle both cron and heartbeat check-ins.
#
manage_uptime_monitor is the newest tool, and it covers uptime monitors end to end: create one, change it, or delete it.
Ask for a monitor on the endpoint you just shipped. Your agent sets the URL, the regions to check from, and the notifiers to alert. It also sets the warmup before an alert opens. For an endpoint behind auth, your agent can attach request headers, such as an Authorization header. Headers often hold credentials, so AppSignal keeps header values out of its tool logs and out of the tool's replies. Your agent can also check that the response body contains a specific string. An update changes only the fields you name, so asking for a region change leaves the notifiers alone.
#
get_exception_incidents takes a query parameter. It matches exception and action names, ignores case, and accepts * wildcards.
Before this, an agent looking for a specific error paged through incidents until it found the right one. Each incident it read along the way used up context. Now you name it: "Find the open Timeout incidents in the background namespace from the last week."*
#
get_exception_incidents also takes new_only. Set it to true to get only the errors first seen in the time window you ask about. Older errors that recur in that window stay out.
Without it, a question about a deploy returns every error reported in that deploy, including old ones. Your agent then has to work out which are new. "Which new errors did the last deploy to MyStore production introduce?" returns only the errors first seen in that deploy. Pair new_only with a revision, or revision: "last", to scope it to a single deploy.
#
Each performance trace action has a logbook now, and MCP writes to it. manage_incident_note is now manage_note. It adds and edits notes on incidents by number, and on performance trace actions by namespace and action name.
Traces expire. Notes on the action don't. Say your agent works out why BlogPostsController#index gets slow every Monday morning. That finding stays on the action for the next person who looks. The old tool name still works.
#
Two limits were cutting answers short. Both are gone.
get_log_lines used to hand your agent a 120-character preview. A stack trace, a JSON payload, or a long error string arrived cut off. Usually, the interesting part was what went missing. The preview is now the heading, with the full message below it, up to 2,000 characters.
In tree mode, get_traces now returns the root span and a breakdown of self time per category. One call shows where a slow request actually spent its time. In span detail mode, database query text used to stop at 500 characters. It now comes through in full, up to 10,000 characters. Your agent reads the whole query. It can spot an N+1 query or missing index without guessing from the first line.
#
We folded three tools into others. archive_trigger moved into manage_trigger. reorder_log_line_actions and delete_log_line_action moved into manage_log_line_action. The merged tools take an action parameter now.
Every tool definition sits in your agent's context window for the whole conversation. A shorter toolset leaves more room for your actual work. The old names still work as aliases, and existing prompts don't need rewriting.
To put the current toolset to work, browse the MCP tool reference for every tool's parameters and example prompts. For prompt sequences that cover a full investigation, follow the MCP workflows.
#
AppSignal MCP covers nine areas: app discovery, check-ins, uptime monitoring, error incidents, performance, anomaly detection, logging, metrics, and dashboards. That's 24 tools. Check-in support exists only because people asked for it.
Missing a tool?
If your agent hits a wall, ask it to call get_more_tools and describe what you are missing. Requests land with us, and we read them. It's the most direct way to share feedback on what we build into MCP next. You can also tell us in the AppSignal Discord community or reach out to our support team.
Published
Wondering what you can do next? #
- [Add the AppSignal connector to Claude.](https://claude.ai/directory/appsignal)
- [Read the MCP setup guide.](https://docs.appsignal.com/mcp/setup)
- [Browse the MCP tool reference.](https://docs.appsignal.com/mcp/reference)
- [Try out AppSignal with a 30-day free trial.](https://appsignal.com/users/sign_up?utm_source=blog&utm_medium=article&utm_campaign=mcp_claude_connector_2026_10_21&utm_content=whats_next_signup)
- Share this article on social media
AppSignal monitors your apps #
AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!