If you are exposing an MCP server in front of a REST API, two things from our own experience that are worth passing on:
Code change and tool-description change have to land together. Reshape a list response without updating the description, and you trade a loud overflow failure for a silent one — the agent stops at the thin record, never realises get_bug exists, answers from incomplete data.
Log result_size_bytes per tool call, and smoke-test against production-shaped data, not synthetic fixtures. A response can be type-correct and still wrong about its size, and dev fixtures hide the 99th-percentile costs that broke us in production.
Both are aspects of the now-familiar idea that an MCP server is a context translator, not a protocol translator — the BFF / overfetching pattern with the consumer swapped from a UI client to an LLM. The principle itself is not new; what may be new is the specific pairing of the code change with the tool-description change, and the habit of logging output byte size on every call.
The story below — list_bugs(limit=3) returning 61,621 bytes for three records, the agent harness saving the overflow to disk and then grepping field values from the file, one question producing four tool calls — is one incident on our own backend. Illustrative, not a benchmark.
