A long session keeps running out of room. You have several MCP servers connected, and a command-line tool exists that covers what one of those servers does. A colleague proposes raising the tool-output cap instead, arguing that large results are what fills the window. What is the better move, and why?

The principle — Context spend has two shapes: a standing cost you pay every turn for what is connected, and a variable cost you pay when a call returns something large. They have different remedies, and reaching for the wrong one makes things worse.

Why the key is correct — The documentation is direct about this trade: tools like the common vendor command-line clients are still more context-efficient than MCP servers because they do not add any per-tool listing. Claude can run them as ordinary commands. Meanwhile each connected server takes some space in Claude's context window because its tool names and server instructions load into every session, so removing one server removes a cost that recurs on every single request.

Why the others are wrong — An MCP server is not automatically the better option; it is better when structured tools are worth their standing cost, which is exactly the judgement under review here. A command-line tool is not comparably expensive, because nothing has to be listed per tool. And raising the output cap admits more text into the window rather than less, which addresses neither the standing cost nor the pressure the session is under.

Remember this — Under context pressure, count what is connected before you adjust what comes back. The standing cost is paid on every request and the output cap is paid only when a call returns something large, so the standing cost is almost always the one worth attacking first.

Sources — Anthropic's Claude Code cost guidance and MCP quickstart.