lazy-tool

The more MCP servers you connect, the more tool schemas get dumped into every prompt. The model reads all of them, picks the wrong one more often, and you pay for every token. This is a known problem — the pattern that solves it (search before invoke) is well-established.

Most implementations of that pattern require a Python stack, a vector database, Docker, or a cloud service. lazy-tool does it as a single Go binary with a local SQLite catalog. No containers, no API keys for the tool layer, no infrastructure.

make build → import --write → reindex → serve

That's it. One binary, reads your existing IDE config, indexes everything locally, serves as an MCP endpoint.

| | Direct MCP | Through lazy-tool | |---|---:|---:| | Input tokens per turn | 1,701 | 915 (−46%) | | Latency per turn | 0.232s | 0.158s (−32%) | | Tools in agent context | 47 | 5 |

^{llama-3.1-8b-instant, 20 repeats per task. <a href="benchmark/README.md">Methodology</a>}

[](https://github.com/rpgeeganage/lazy-tool/actions/workflows/ci.yml) [](LICENSE) [](https://go.dev)

---

Several projects address MCP tool sprawl in different ways: RAG-MCP (Python + vector DB), MetaMCP (Docker), AWS AgentCore Gateway (managed cloud), and Claude Code's built-in tool search (client-side, Claude-only).

lazy-tool occupies a specific niche: local-first, zero-dependency, single binary.

• No infrastructure. One Go binary, local SQLite. No Docke