Trend tools return every raw point: get_file_io_trend sends 12,451 points / 1.4 MB for one server at defaults, more than an LLM client's context #3897

Summary

The trend tools return every raw point in the window. At default arguments, get_file_io_trend sends 12,451 points and 1.4 MB of JSON for one server. That is roughly 350k tokens at ~4 characters per token: more than a 200k-context model can take in, for a single tool call.

The store answers in about 100 ms. The slowness users feel is the client: transferring, parsing and feeding that payload to the model, or truncating it and reasoning over a fragment.

The size grows with objects per server (database files, databases, counters), so it is invisible on our servers and severe on large ones. Measured at d21bbc9a against nightly 458 on DARLING01.

Measured (tool text payload at default arguments)

get_file_io_trend is files × one point per 1-minute collection. SQL2022 has 27 files. A 300-database server (about 600 files) would return about 22× this, roughly 30 MB for one call.

My own client spilled a single 87 KB get_collection_log result to disk rather than put it in context. Clients with smaller budgets fare worse.

Existing mitigations, and why they do not reach this

• MCP tool results are pretty-printed, and every consumer of them is a model #2350 made results compact rather than pretty-printed.
• The opt-in GCF encoding (DARLING_OUTPUT_FORMAT=gcf, Mcp/GcfOutput.cs) cuts record-heavy results by roughly a quarter to a half.

Neither changes the number of points, and the point count is what scales.

Fix shape

• Downsample on the server to a bounded number of points per series by default: a time_bucket sized from the window so each series lands at or under about 200–300 points. Carry min/avg/max per bucket (or an LTTB-style selection) so a spike survives.
  • The trend family already discloses its grain (bucket: per-collection / 1 hour, source, effective_start), so a computed bucket width fits the existing envelope.
  • Per payload-contract rule "refuse what you cannot honor" (MCP payload-contract campaign: the agent-facing API tells the truth (~30 defects + an 11-rule contract) #3541 lineage), the cap is disclosed, never silent. Callers who need raw resolution can narrow the window or pass an explicit bucket.
• Bound the series count for per-object trends. For example, get_file_io_trend defaults to the top N files by the trended measure, with a remaining_series count and totals for the rest, so a 600-file server does not return 600 series.
• get_store_metrics: 1.2 MB is mostly per-object history. Default to a summary plus the top movers, with the full series behind a parameter.
• A census pin: every trend tool's default call stays under a byte budget on a fixture sized like a large server (hundreds of files and databases), so this cannot regrow.

Where the web viewer charts these readers through its /api/read/* mirror, server-side bucketing also cuts browser payload and render time on large servers.