krishnashakula/toollens

Give your agent 2,468 tools. It sees 3. A Rust MCP gateway: dependency-aware tool discovery, policy-checked execution, measured on 110 real vendor MCP servers (26/28 tasks at half the cost of Anthropic's tool search)

Summary

ToolLens is a Rust Model Context Protocol gateway that sits between an AI agent and multiple MCP servers. Instead of sending every server tool definition with every request, it exposes three operations—discover_tools, inspect_tool, and invoke_tool—while keeping discovery separate from execution permission.

What it is useful for

This is useful when a large MCP setup makes context size or request limits the main problem. In the README’s benchmark of 110 vendor-published servers and 2,468 tools, exposing everything produced about 1.43 million tool tokens per request and the requests were rejected. ToolLens completed 26 of 28 tasks, versus 25 for Anthropic’s built-in tool search; the authors also state that this was one model and one run per task.

The three operations have clear roles:

• discover_tools(goal, limit?) returns up to 10 tool IDs for a goal, including direct matches and dependencies, with reasons for inclusion.
• inspect_tool(tool_id) exposes the schema, owning server, and current policy decision.
• invoke_tool(tool_id, arguments) checks policy, validates arguments, and forwards the call.

For example, an “investigate a failed deployment” goal can bring in a deployment lookup, logs, and commit tools because their schemas pass identifiers between one another. This makes ToolLens useful for deployment, observability, version-control, and other multi-server workflows where sending the entire catalog is impractical. Discovery alone never authorizes execution.

How engineers can use it

Build the release binary with Rust 1.89 or newer:

git clone https://github.com/krishnashakula/toollens && cd toollens && cargo build --release

Before changing a client, measure the current tool tax:

./target/release/toollens tax --config .mcp.json

Then create a gateway configuration from an existing Claude Code or Claude Desktop-style config:

./target/release/toollens init --from .mcp.json

init reads the server entries, writes toollens.json, and prints the client change; --write applies it and keeps a backup. Point the client’s mcpServers entry at /path/to/toollens with arguments serve --config /path/to/gateway.json. Before involving an agent, test discovery with ./target/release/toollens discover --config gateway.json --goal "investigate a failed deployment". Set a policy explicitly: with no policy, all execution is denied.

Check the limitations before deployment. denyDestructive only covers tools explicitly annotated destructiveHint: true; use deny globs for other sensitive tools. Lazy mode trusts its cached tool list until --reindex, so pin server versions. maxLive is not a hard limit. Claude Desktop remains untested in the README, and the benchmarks cover one model with one run per task.