> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmcpulse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Heavy payload

> This tool returns a lot of context. What it costs per call and across the range, and how to cut it.

> `list_orders` returns \~3.1k tokens per call, roughly $0.0094 of context each time — $8.39 across 892 calls.

## When it fires

|           |                                          |
| --------- | ---------------------------------------- |
| Condition | Average response over **10,000 bytes**   |
| Severity  | **medium** over 10kB, **high** over 30kB |
| Minimum   | 20 calls                                 |
| Lag       | None — live                              |

## What it means

Ten thousand bytes is roughly 2,500 tokens. Every call is putting that into the model's context window, and it is paid for on **every subsequent turn** of the conversation, not once.

The insight prices it two ways because both matter: per call, which is what you are deciding about, and across the range, which is what it has already cost.

## The fixes, in the order they usually work

<Steps>
  <Step title="Return fields, not records">
    A row with 40 columns costs 40 columns of context. Return the three or four fields the model actually needs to answer the next question, and offer a `get_x` tool for the full record when it is genuinely wanted.
  </Step>

  <Step title="Add a limit, and default it low">
    A search with no limit returns everything matching. A default of 10 with an explicit `limit` argument is almost always better than 100 — the model can ask for more, and usually does not need to.
  </Step>

  <Step title="Stop pretty-printing">
    `JSON.stringify(x, null, 2)` is measurably more bytes than `JSON.stringify(x)`, and no model reads the indentation.
  </Step>

  <Step title="Stop echoing the request">
    Returning the filters that were applied, alongside the results, doubles small responses. The model already has the arguments it sent.
  </Step>

  <Step title="Summarise where you can">
    A count and five examples often answers the question better than four hundred rows — and if it does not, the model can narrow and ask again for far less than the four hundred rows would have cost.
  </Step>
</Steps>

## Worth checking before you optimise

Sometimes a heavy response is correct. A tool whose whole job is fetching a document returns a document.

The test is whether the model **uses** what it is given. A heavy tool with high [first-call success](/metrics/first-call-success) is expensive and working; a heavy tool that also gets retried is expensive and not working, and it is the second one worth fixing first.

## Related

* [Response size](/metrics/response-size)
* [Cost per session](/metrics/cost)
* [Cut context cost](/guides/cut-context-cost)