The 2026-08-22 MCP roadmap explicitly prioritizes progressive tool discovery, urging servers to offer a small entry point rather than dumping every tool definition on the agent. While the standard is clear, the implementation gap is widening. Developer Mike (webofmike) recently built a side-by-side comparison of a flat 50-tool catalog against a progressive one, revealing that the native solution for this pattern is locked behind Solo Enterprise's agentgateway license, leaving open-source users to build it themselves.

The License Wall

Solo Enterprise's agentgateway documentation lists four toolMode values for MCP backends: Standard, Search, Code, and CodeSearch. The Search mode is the exact mechanism the roadmap describes, using meta-tools to disclose one tool at a time. However, this feature is gated behind the entMcp.toolMode field on an EnterpriseAgentgatewayBackend resource. A check of the open-source agentgateway v1.6.0 documentation confirms no equivalent tool-mode page exists. The OSS binary supports MCP multiplexing and routing, which actually expands catalog visibility rather than constraining it, making it the opposite of what progressive discovery requires.

Hand-Rolling the Search Mode

Since the primitive was unavailable in the OSS tier, the developer implemented the logic directly in the MCP server using approximately 130 lines of Python. The hand-rolled solution exposes three fixed entry points: list_categories, expand_category, and call_tool. This structure ensures the agent only sees the full definitions for a specific category after explicitly requesting it. The demo runs these custom servers behind a standard agentgateway v1.6.0 instance using separate-path routing, proving that the architecture works without Enterprise features, provided you are willing to maintain the server-side logic.

The Measured Savings

Running the measurement script against the gateway yielded concrete results. For a 50-tool catalog, the flat tools/list response was 16,358 bytes, while the progressive response was just 922 bytesβ€”a 94.4% reduction in initial payload size. In a realistic scenario where an agent only needs the 'billing' category, the total data transfer dropped from 16,358 bytes to 5,521 bytes. This represents a 66.2% net saving, accounting for the overhead of listing categories and expanding the specific tool set. These are wire bytes, not model tokens, but the content type ensures the token savings follow the same trajectory.

Key Takeaways

  • Progressive discovery is distinct from Code Mode; it hides catalog size rather than replacing tools with a script executor.
  • Solo Enterprise locks the native Search tool mode behind its license tier, leaving OSS users without a config field for it.
  • A functional progressive catalog can be built with ~130 lines of Python, reducing initial tool visibility by 94.4%.
  • Open-source agentgateway v1.6.0 supports routing and multiplexing but lacks native tool-level discovery controls.

The Bottom Line

This is a classic infrastructure squeeze: the roadmap demands efficiency, but the vendor gates the easiest implementation behind an Enterprise SKU. For teams running open-source gateways, the 130-line Python workaround is a viable, low-friction path to reclaiming 66% of your context window.

Code and Replication

The entire experiment, including the Docker Compose setup and measurement scripts, is available in the themsquared/progressive-tool-discovery repository under the Apache-2.0 license. The demo validates against Docker 29.8.1 and Compose v5.5.1, taking under 15 minutes to run. For developers with catalogs exceeding forty tools, building the entry point pattern now is likely more cost-effective than waiting for the OSS gateway to catch up to the Enterprise feature set.