ToolLens: An MCP Gateway Built in Rust That Condenses Thousands of Tools into Three

Why Do We Need an MCP Gateway?

When AI agents need to connect to external tools, the MCP (Model Context Protocol) makes this standardized. But problems arise along with it: once the number of tools grows, agents get stuck in "choice paralysis." Every tool occupies context window space, and thousands of tool descriptions can inflate the prompt to an unmanageable degree. ToolLens is an open-source project designed to address exactly this pain point—an MCP gateway written in Rust that exposes only three tools to the agent instead of thousands.

According to discussions in the Reddit community, the core idea of this project is "a tool of tools": rather than dumping the entire toolbox onto the agent, give it a key that can open the toolbox.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, aimed at establishing a unified connection standard between AI applications and external data sources and tools. Before MCP emerged, every AI application that wanted to connect to external tools (such as databases, search engines, and file systems) needed customized adapter code, resulting in severe ecosystem fragmentation. Drawing on the design approach of the Language Server Protocol (LSP), MCP defines a standardized communication method between clients (AI applications) and servers (tool providers), typically based on JSON-RPC transport. A tool provider only needs to implement an MCP server once to be callable by all AI clients that support MCP. This protocol was quickly adopted by mainstream AI development tools and directly gave rise to the management challenge that followed the "explosion in the number of tools"—which is precisely the backdrop for the emergence of gateway projects like ToolLens.

How Do Three Tools Replace Thousands?

The design philosophy of ToolLens is not simply to hide tools, but to reorganize the way tools are exposed. The agent interacts with the entire tool ecosystem through three entry points. The specific mechanism was not fully elaborated in the original discussion, but it can be inferred that the pattern is roughly: one for discovering tools, one for invoking tools, and one for managing or querying state. In this way, the agent's context always contains only three tool descriptions, while any number of actual tools can be mounted behind them.

This "gateway pattern" is a direction worth watching in the MCP ecosystem. It shifts the complexity of tool selection from the agent to the gateway layer, allowing the model to focus on the task itself rather than doing multiple-choice questions in a list of tools.

Context Window refers to the maximum number of tokens a large language model can process in a single inference, simultaneously holding the system prompt, conversation history, tool descriptions, and information about the task to be handled. Tool descriptions are usually embedded in the prompt in the form of JSON Schema, and a moderately complex tool description may consume hundreds of tokens. When the number of tools reaches hundreds or even thousands, tool definitions alone may fill the entire context window, preventing the model from effectively handling the actual task. This phenomenon is often called "context pollution" or "tool overload." The core value of the gateway pattern lies in compressing this overhead to a constant level—no matter how many tools are mounted on the backend, the agent always sees only the descriptions of a fixed few entry-point tools, thereby reserving the precious context budget for the task itself.

The Choice of the Rust Tech Stack

ToolLens is implemented in Rust, which is itself an interesting signal. An MCP gateway needs to handle concurrent connections, protocol parsing, and low-latency forwarding, and Rust's memory safety and high-performance characteristics match these infrastructure requirements well. Compared with Python or Node.js implementations, Rust versions typically perform better in resource usage and throughput, which is crucial for a gateway service that needs to run for a long time.

The open-source community is showing growing interest in AI infrastructure projects written in Rust, and the emergence of ToolLens shows that the MCP toolchain is moving from the prototyping stage toward engineering maturity.

JSON-RPC is the remote invocation format used at the底层 of the MCP protocol. It is a lightweight request-response protocol that transmits method calls and results between client and server through JSON messages. An MCP gateway needs to parse, route, and forward JSON-RPC messages between the agent and multiple backend MCP services, which involves high-frequency serialization/deserialization operations. Libraries such as serde in the Rust ecosystem provide zero-copy and high-performance JSON processing capabilities, and combined with asynchronous runtimes (such as Tokio), they can support a large number of concurrent connections. This is also why gateway-type infrastructure tends to choose Rust rather than scripting languages—on an I/O-intensive and latency-sensitive path such as message forwarding, runtime overhead and garbage collection pauses directly affect the agent's response experience.

The Impact on the Agent Tool Ecosystem

The problem ToolLens raises is very practical: the more MCP tools there are, the more efficient the agent is not necessarily. The context window is a scarce resource, and the unrestrained expansion of tool descriptions will crowd out the task information that really matters. The gateway pattern provides a layered approach—letting the agent face a stable, minimal interface, while the expansion of the tool ecosystem is completed behind the gateway.

If this pattern is widely adopted, it may change the way MCP tools are published: tool providers no longer need to worry about the "exposure" of their tools in the agent's context, but instead register and discover through the gateway. Of course, this also brings new problems, such as how the gateway decides which tools are visible to the current task and how to avoid single-point bottlenecks. The original material does not cover these details, but they are worth continued observation in this direction.

Open Source and Community Feedback

ToolLens is released as open source, with both code and discussion public in the community. Discussions on Reddit show that developers resonate with the "less is more" tool exposure strategy, especially those who have encountered tool count inflation in real agent applications. The "Lens" in the project name suggests a focused perspective—viewing the entire tool world through a lens, rather than cramming the world into the lens.

For developers who are building MCP applications, ToolLens provides a reference implementation paradigm: use the infrastructure layer to solve complexity, rather than forcing the model to bear it.

One-line Summary

ToolLens is an open-source MCP gateway written in Rust that condenses thousands of tools into three exposed to the agent.

Paragraph Summary

ToolLens is an open-source MCP gateway written in Rust, designed to solve the "choice paralysis" and context inflation that occur when AI agents connect to a large number of external tools. Although the MCP protocol standardizes the way tools are connected, an increase in the number of tools causes each tool description to occupy valuable context window space, making the prompt unmanageable. The core idea of ToolLens is "a tool of tools": exposing only three entry-point tools to the agent (presumably for discovery, invocation, and state management), with any number of actual tools mounted behind them, shifting the complexity of tool selection from the model to the gateway layer. The Rust tech stack fits the gateway's needs for high concurrency, low latency, and long-term stable operation, and also reflects that the MCP toolchain is moving from prototyping toward engineering maturity. The open-source community has responded positively to the "less is more" strategy, but questions such as how the gateway determines tool visibility and how to avoid single-point bottlenecks remain to be seen.