octoperf-bench-reports

OctoPerf — Reading bench reports

A BenchReport is a polymorphic document. Its items array carries 20+ report item types (charts, tables, top-N, insights, …), each backed by its own get_report_*_values tool. This skill maps every report item you can encounter to the right tool, calls out the semantic gotchas that have repeatedly tripped LLMs, and explains the trend-report architecture.

Editing a report item's metrics/filters (not just reading them)? See octoperf://skills/report-item-editing — it covers the allow-select workflow (get_report_item_allow_select → get_report_tag_keys / get_report_tag_values → validate_report_item → patch_bench_report).

The BenchReport shape — one quick anchor

BenchReport {
  id, projectId, name, benchResultIds,         // — the runs the report aggregates
  configs:  [ApdexReportConfig | TrendReportConfig | ...],  // global settings
  items:    [polymorphic BenchReportItem...]   // — what's visible on the page
}

• A regular report has 1 entry in benchResultIds (the run it was generated for) and items that pull values from that run.
• A trend report has 1 entry too (the reference anchor) and a TrendReportConfig in configs whose selectors are re-evaluated dynamically at read time to pull in other matching runs. See Trend reports below.

To read any report item, always start with:

mcp__octoperf__get_bench_report(reportId)

then dispatch on each items[i]["@type"] per the table below.

Before reading: the run's data must be up to date

A bench result holds its samples in the shape the current analysis queries expect only once its data has been updated. A run recorded before the last data model change still holds the previous shape, and the metric queries never look there: every report item answers empty — not "old numbers", not an error. Zeros read as a finding, which is how an outdated run becomes a fabricated diagnosis.

So the report tools refuse rather than answer empty: