list_appsLABSCO SUMMARY
Traces with backtraces, in the editor where the fix goes.
What comes back from get_app_trace and get_app_error_groups carries line-of-code information, so the assistant can move from "this endpoint is slow" to an edit in your repository without you copying stack traces across. get_app_insights skips the hunting entirely by handing over the repeated-query and slow-query findings Scout has already identified.
What it is
A local server over the Scout Monitoring API. It brings an application's performance and error data — traces, spans, error groups, insights — into the assistant, with line-of-code detail attached.
What you get
- Every application reporting to your account, optionally filtered by when it was last active (list_apps)
- A single metric over time for one application — response time, throughput and the rest (get_app_metrics)
- Every endpoint with its aggregated performance, and a time series for any one of them (get_app_endpoints, get_endpoint_metrics)
- Recent traces filtered to an endpoint, and one trace opened in full with all its spans (get_app_endpoint_traces, get_app_trace)
- Recent error groups, optionally narrowed to an endpoint (get_app_error_groups)
- Scout's own findings — N-plus-one queries, memory bloat, slow queries — as a list you can act on (get_app_insights)
- Setup templates published as resources for Rails, Django, Flask and FastAPI, plus the list of available metrics
Requirements
A Scout Monitoring account with the agent already reporting, and an API key created on the settings page — the read-only one, not the agent key. The server will not start without it. It runs from the published container image, and an interactive wizard writes the client configuration for Cursor, Claude Code and Claude Desktop.
Setup effort
One command plus a key — npx @scout_apm/wizard, then supply credentials
USE CASES
01
Finding where the time goes
List the endpoints with their aggregate performance, then pull recent traces for the worst one.
02
Fixing a repeated-query problem without hunting for it
Read the insights, then open the specific trace by ID and work from the spans.
03
Turning an error into a patch
Get the highest-frequency error groups for the window, open the latest one, and read the backtrace where the code lives.
04
Checking whether last week's change helped
Pull the response-time series for that endpoint and compare it against before.
05
Setting Scout up in the first place
Ask for the configuration template for your framework and have it written into the project.
8 tools
Listed in project docs. Your client may show a different list.
get_app_metricsget_app_endpointsget_endpoint_metricsget_app_endpoint_tracesget_app_traceget_app_error_groupsget_app_insightsBEFORE YOU INSTALL
What to know first
Tools you get
8 tools named in the project's documentation.
Requires
- docker on PATH
- SCOUT_API_KEY in your environment
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
npx @scout_apm/wizardMCP Clients
Claude Code
CLAUDE CODE · TERMINAL
claude mcp add scoutmcp -e SCOUT_API_KEY=<YOUR_SCOUT_API_KEY> -- docker run --rm -i -e SCOUT_API_KEY scoutapp/scout-mcp-localClaude Desktop
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"scout-apm": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"--env",
"SCOUT_API_KEY",
"scoutapp/scout-mcp-local"
],
"env": {
"SCOUT_API_KEY": "<YOUR_SCOUT_API_KEY>"
}
}
}
}
