---
title: 2,190 tools, zero standing cost
url: https://revworx.ai/insights/2190-tools-zero-standing-cost/
date: 2026-10-27T23:45:30+00:00
modified: 2026-10-29T06:35:16+00:00
lang: en_US
---

# 2,190 tools, zero standing cost

The strongest objection to building a GTM stack on the Model Context Protocol is cost. Done the default way, every capability you connect becomes a permanent tax on every request. The objection is fair, and it deserves a direct answer. The answer is the load-bearing element of the whole architecture.

## The objection, stated fairly

The default pattern is load everything, always. Each connected server publishes the definitions of its tools, and the agent carries every one of those definitions on every turn, whether the turn needs them or not. Two problems follow.

- **Tool bloat.** Context spent on definitions is context unavailable for the work. Model usage is metered by the token, so it is paid for on every call.
- **Selection inconsistency.** An agent choosing from hundreds of similar tools in one flat list picks the wrong one more often, and not in a predictable way.

Together they mean cost rises and reliability falls with every server you add. An architecture built on that pattern cannot grow without degrading itself.

The scale is easy to underestimate. On one of our production agent instances, the connected servers exposed 2,190 tools. Their definitions alone came to 778,900 tokens, more than a 475,000-token context window can hold. The agent could not carry its own toolbox, let alone do any work with it.

## Load nothing until it is needed

The architecture replaces load-everything with progressive disclosure. The agent carries no tool definitions by default. When a task needs a capability, it works in three steps:

1. **Discover.** Search the catalog of connected servers for candidate tools, returned in compact form.
2. **Inspect.** Load the full definition of the one tool about to be used, and no other.
3. **Execute.** Call it, and filter the result before it enters context.

The agent learns this loop once, at a small fixed cost. From then on, adding a server is a configuration entry, not a prompt change, and the standing cost of tool definitions does not move.

## The measured result

On the same instance with progressive disclosure turned on, standing tool-definition cost fell from 778,900 tokens to zero. Context in use fell from 168.6 percent of the window to 4.3 percent. Nothing was disconnected. All 2,190 tools stayed reachable.

![Figure 2. Context window on one production agent instance, progressive disclosure off and on](https://revworx.ai/wp-content/uploads/cra-figure-2-context-window.png)

State the claim precisely. Standing tool-definition cost is flat in server count. Total token spend still scales with the work performed. What changes is that capability no longer costs you anything until you use it.

## When MCP composes, and when it does not

Progressive disclosure is one of five conditions the architecture needs before MCP makes a stack composable:

- One protocol for every capability, infrastructure included.
- Discovery on demand rather than loading by default.
- A curated, versioned catalog whose tool descriptions are good enough for search to select consistently.
- A single gateway that holds every login credential and routes every call.
- Master records owned outside every tool.

Remove any one of them and composability degrades.

Progressive disclosure also has limits worth saying out loud. It removes the context-cost and selection problems, the scaling limits that bite first. It does not fix MCP’s trust model. A malicious server is malicious however it is called, and tool descriptions and outputs remain routes for prompt injection. The architecture handles those risks elsewhere, through the curated catalog, the credential gateway and containment controls.

Design principle

Load nothing until the moment it is needed.

Applied to tools, the MCP portfolio grows with your ambition while the standing context cost stays flat.

Key takeaway

MCP’s cost and reliability problems come from how tools are loaded, not from the protocol itself. Load nothing until it is needed, and the MCP portfolio scales with your ambition while the standing context cost stays flat.

Read the full section: [The load-bearing element](/architecture/4/)

Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §4. revworx.ai.