The first is the aggregate view and the second the individual-request view, which is the split that decides whether you are looking at a trend or at one slow request. The useful filtering lives in get_traces: min_response_time_ms and max_response_time_ms bound the sample to the requests worth reading, and has_callgraph narrows to the traces carrying enough detail to act on. The 15-minute buckets in get_performance_summary are what make a spike visible at all — a daily aggregate would flatten it out of existence.
A Tideways client with 5 tools covering aggregate performance metrics, a 15-minute-interval summary, errors and issues, historical data at a chosen granularity, and individual trace samples.
- get_performance_metrics returns aggregate performance and system-wide statistics as JSON, for overall health and trends.
- get_performance_summary returns a time series in 15-minute buckets showing requests, errors and 95th-percentile response times.
- get_issues returns recent errors, exceptions and performance issues, filterable by issue type and status with paging.
- get_historical_data returns historical performance for a specific date at daily, weekly or monthly granularity.
- get_traces returns individual trace samples, filtered by transaction name, environment, a minimum and maximum response time, a date range, whether a call graph is present, and a sort order.
Tideways access for the project you want to read: a token in TIDEWAYS_TOKEN, with the organisation and project named by TIDEWAYS_ORG and TIDEWAYS_PROJECT.
One command plus a key — npx tideways-mcp, then supply credentials