Section 4 · Part one
The load-bearing element
If MCP is the integration paradigm, the next question is what it costs to run at scale. Done the default way, it costs a great deal. The standard way agents connect to MCP servers makes every added capability a permanent tax on every request. This is the strongest objection to an MCP-centric architecture, and it deserves a direct answer. The answer is the core innovation of this architecture, and the reason MCP can carry the weight we place on it.
Connecting agents to MCP servers the default way makes every tool a standing cost on every request. On one of our production agent instances, nine servers exposed 2,190 tools whose definitions came to 778,900 tokens. With progressive disclosure, that standing cost fell to zero and all 2,190 tools stayed reachable.
4.1The objection, stated fairly
The default integration pattern is load everything, always. Each connected server publishes the definitions of its tools, and the agent carries every one of those definitions in its context on every turn, whether or not the turn needs them. Two problems follow.
The first is tool bloat. Context spent on definitions is context unavailable for the work, and because model usage is metered by the token, it is paid for on every call. The second is 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 that cost rises and reliability falls with every server you add. An architecture built on that pattern cannot grow its capability without degrading itself, which is a fair reason to be skeptical of MCP.
The scale of the problem is easy to underestimate. On one of our production agent instances, nine connected servers exposed 2,190 tools. Their definitions alone came to 778,900 tokens, or 164 percent of a 475,000-token context window, the model’s working memory for a single request. The agent could not hold its own toolbox, let alone do any work with it.
4.2Progressive disclosure
The Composable Reference Architecture replaces load-everything with progressive disclosure. The agent carries no tool definitions by default. When a task needs a capability, the agent works in three steps.
Search the catalog of connected servers for candidate tools, returned in compact form.
Load the full definition of the one tool about to be used, and no other.
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 rather than a prompt change, and the standing cost of tool definitions does not move. On the same instance, with progressive disclosure enabled, standing tool-definition cost fell from 778,900 tokens to zero, and context in use fell from 168.6 percent of the window to 4.3 percent. Nothing was disconnected. All 2,190 tools stayed reachable.
Design principle
Load nothing until the moment it is needed.
Applied to tools, this is progressive disclosure: the MCP portfolio grows with your ambition while the standing context cost stays flat. Applied to knowledge, it is just-in-time context, covered in Section 6.
The same principle, applied twice, is what makes this architecture composable rather than merely large. Capability can be added, swapped or retired without the cost of the whole system moving with it.
4.3The conditions under which MCP composes
MCP makes an architecture composable only when five conditions hold. Remove any one of them and composability degrades.
4.4What progressive disclosure does not fix
Progressive disclosure removes the context-cost and selection-reliability problems, which are 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, version-locked catalog, the credential gateway and the containment controls described in Section 10.
For technical evaluators
Mean definition cost on the measured instance is about 356 tokens per tool (778,900 ÷ 2,190). Under load-everything that cost grows linearly with tool count and is paid on every turn; this instance overflowed its window at nine servers. Under progressive disclosure the standing cost is the discovery loop itself, which fits inside the existing system-tool and skill overhead of about 12,000 tokens. That overhead was identical in both runs. The per-task cost is one compact search result plus one inspected definition.
State the claim precisely: standing tool-definition cost is flat in server count, while total token spend still scales with the work performed. Selection becomes a two-stage search-then-inspect pipeline that can be logged and audited, instead of a single-shot choice from a flat list. Results are filtered before they enter context.
Current implementation
Progressive disclosure is implemented as a capability of the agent runtime. It exposes the full MCP portfolio through a compact, searchable catalog and loads individual tool definitions on demand. The implementation is proprietary to revWorx.
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.
Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §4. revworx.ai/architecture/4