Cap the size of each individual tool response in MCP server

[jmikitova]

Several MCP tools return unbounded output, so a single call can blow the context budget. get-dataset-items with limit:125 can land ~150k+ tokens in one response (max observed 236,424). search-actors is the most-called tool (2,518 calls) and largest aggregate consumer (~5.8M tokens), with a long per-call tail driven by un-clipped descriptions and full pay-per-event pricing lists.

Measured output sizes (~4 chars/token heuristic):

Tool	Calls	Avg	Median	p95	Max	Aggregate
search-actors	2,518	2,298	1,682	4,583	11,536	~5.79M
get-dataset-items	264	10,522	2,608	47,924	236,424	~2.78M
call-actor	1,053	1,483	329	8,021	48,475	~1.56M
fetch-actor-details	682	1,980	1,124	5,854	58,342	~1.35M
search-apify-docs	42	10,854	2,201	69,478	86,478	~0.46M
get-key-value-store-record	19	1,444	363	9,713	9,713	~0.03M

Specific unbounded sources: get-dataset-items (whole items array, no byte cap), fetch-actor-details (full README + full input schema), search-apify-docs (uncapped per-snippet content), get-key-value-store-record (text/JSON value inlined uncapped), search-actors (un-clipped descriptions + full PPE pricing).

Source: Notion — Cap the size of each individual tool response

[vojtechj-apify]

From my investigation of tool calling, get-dataset-items ignores the configured limit. We should hardcode it and verify it's respected. There's a tension here: we want to capture as much dataset data as possible, but we also need to cap it.

After discussing with @jirispilka , we landed on the following approach: shorten the dataset output after one message after the message is processed, and if more data is requested, call get-dataset-items again.

[MQ37]

I think this should be handled in the MCP client - someone might want to ingest the whole 150k response and process that in the LLM directly.

[jmikitova]

@MQ37 but they can ingest it, the LLM will just iterate with pagination

[jmikitova]

closing this issue as we've handled it on AI chat side