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.
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.
- 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
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.
One command plus a key — npx @scout_apm/wizard, then supply credentials