The Scout MCP server connects your AI assistant directly to your Scout Monitoring data. Instead of switching between your editor, Scout, and a chat window, your assistant can pull traces, errors, N+1 insights, and endpoint metrics on its own and use that context to suggest or make fixes right in your codebase.
This covers how to connect it, what to ask it, how other teams are using it, and what we shipped recently.
Getting started
If you haven’t set it up yet, these prompts will get you there fast:
- “Help me set up Scout Monitoring for my Rails application.”
- “Create a Scout APM config file for my Django project with key ABC123.”
Full setup instructions are in the Scout MCP server repo on GitHub.
Performance investigation
These are the prompts teams reach for most:
Slowest endpoints:
“Find the slowest endpoints for app [your-app-name] in the last 7 days. Generate a table with average response time, throughput, and P95.”
N+1 queries:
“Get any recent N+1 insights for app [your-app-name]. Pull the specific trace by ID and help me optimize it based on the backtrace data.”
Error investigation:
“Show me the highest-frequency errors for app [your-app-name] in the last 24 hours. Get the latest error detail, examine the backtrace, and suggest a fix.”
Background jobs:
“What are the slowest background jobs for [app] this week?”
Regression detection:
“Which endpoints have degraded the most in the last 30 days?”
Monthly and quarterly reporting
The Scout MCP server is useful for reporting, not just incident response. With 30-day metrics and historical insight queries now available, you can pull a full picture without stitching calls together:
“Pull endpoint performance for [app] over the last 30 days. Identify the top 5 endpoints by time consumed and flag any that have gotten slower since last month.”
“Get performance insights for [app] for May. Summarize any N+1 queries, memory bloat, or anomalies that were active during that period.”
“Compare endpoint performance for [app] this month versus last month. Flag any endpoints where response time has increased more than 20%.”
Connecting Scout data to other tools
The Scout MCP server pairs well with GitHub, JIRA, and other MCP-enabled tools your assistant has access to:
“Find the top error in [app], open a GitHub issue with the backtrace and a suggested fix, and assign it to me.”
“Pull the slowest trace for [endpoint] and open a JIRA ticket with the full context pre-filled.”
“Find any N+1 queries in [app], write the fix, and open a PR.”
How teams are using it
AcuBliss: N+1 fix in under 3 minutes
AcuBliss runs a booking and scheduling platform with a lean engineering team. When a performance problem surfaced, they connected Claude Code to the Scout MCP server and let it work.
Scout handed over the trace: 637ms average response time, 4.28 second worst case, 418 SQL queries on a single endpoint. Claude Code traced the problem to three N+1 patterns in the same serializer and ranked them by impact. The fix was clear before anyone opened a log file. Total time: under three minutes.
BackerKit: Pre-filled issues from Scout traces
BackerKit’s team uses Scout trace links directly in their issue tracker. When Scout surfaces a problem, the relevant trace data travels with the ticket: response times, query counts, backtrace. Engineers open the issue and the context is already there. No re-investigation, no “can you reproduce this?” back-and-forth.
The Scout MCP server takes this further: your assistant can create the issue for you, pulling trace data from Scout and writing the ticket with the details already filled in.
Scout team: day-to-day investigation
We use the Scout MCP server ourselves. A common workflow: something surfaces in a customer account (high endpoint latency, memory spike, error cluster), connect the assistant to Scout, pull the relevant traces, and have it explain what’s happening and where in the code. It cuts the time from “something’s wrong” to “here’s why and here’s the fix” significantly.
“With their CLI and MCP, it’s really easy to pull the data out and analyze it.” - Tyler S., Co-Founder
What’s available
The Scout MCP server exposes these tools to your assistant:
| Tool | What it does |
|---|---|
list_apps |
List your Scout applications |
get_app_metrics |
Response time, throughput, and other metrics |
get_app_endpoints |
All endpoints with aggregated performance data |
get_endpoint_metrics |
Timeseries data for a specific endpoint |
get_app_endpoint_traces |
Recent traces for a specific endpoint |
get_app_trace |
Full trace with all spans and execution detail |
get_app_error_groups |
Recent errors, optionally filtered by endpoint |
get_app_insights |
N+1 queries, memory bloat, slow queries (last ~7 days) |
get_app_insights_history |
Historical insights over any date range |
get_app_anomaly_events |
Detected latency and throughput anomalies |
get_app_anomaly_event |
Detail for a specific anomaly event |
get_usage |
Billing-period usage data (transactions, errors, logs, nodes) |
Your assistant can also read and apply Scout configuration templates for Rails, Django, Flask, and FastAPI via the built-in resources.
All tools are read-only.
What shipped in June 2026
We made a batch of improvements to the hosted MCP server this month, mostly driven by teams doing monthly reporting and running high-traffic apps.
Faster, paginated endpoint listings
get_app_endpoints previously fetched every endpoint and computed stats one-by-one. On high-traffic apps this could time out (25s+) and return very large payloads. It now supports sort_by, limit (default 50, max 200), and offset for pagination. Stats are computed only for the page you request, and responses include total_count and has_more. Existing calls keep working.
Historical insights
The new get_app_insights_history tool lets you pull past N+1 queries, memory bloat, slow queries, and anomalies over any date range, not just a live snapshot. By default it returns insights that were active during your chosen window, so recurring issues that started before the window aren’t missed. Each result includes a compact trace summary; full detail is available via get_app_trace.
30-day metrics in one call
The time-series metrics window has been raised from 2 weeks to 30 days, matching our minute-level metric retention. No more stitching two calls together for a monthly report. This also applies to the public REST API.
Retention windows documented in the tools
Tool descriptions now clearly state what data is available and how far back:
- Minute-level metrics: 30 days
- Traces: 7 days
get_app_insightssnapshot: roughly the last 7 days of traces
Metrics tools now return a clear “range predates retention” message instead of a silently empty result.
Anomaly events
get_app_anomaly_events and get_app_anomaly_event expose detected latency and throughput anomalies through MCP and the REST API.
Usage tool on the hosted server
get_usage is now available on the hosted MCP server, matching what was already in the local MCP server. Returns billing-period usage: transactions, errors, logs, and node counts.
Questions or want help getting set up? Reach out at support@scoutapm.com.