toolsieveGitHub
v0.3.1 · MIT

Three tools instead of a hundred.

toolsieve sits in front of your MCP servers and routes by meaning instead of keywords. Your agent sees three tools. It still reaches all 181, for about 4% of the tokens.

View on GitHub
toolsievefind_toolscall_toolget_savings_report
The problem

Every server you add taxes every request you make.

Aggregate a handful of MCP servers and the whole tool catalog ships with each request: names, descriptions, and complete input schemas, whether the agent needs one tool or none. Across 25 real servers that is 181 definitions and 14,418 tokens, spent before the model has read your question.

Routed by meaning

Queries are matched with cosine similarity over embedded tool names and descriptions, so a request can find the right tool even when it shares no keywords with it.

Weak matches flagged, not hidden

Low-confidence results come back with their score and full schema attached. You decide, instead of silently getting the wrong tool.

One failing server stays one failing server

A downstream server going down does not disable the others, empty catalogs start safely, and remote connection failures get one retry in each direction.

How it works

One entry in your config. Three tools on the wire.

toolsieve registers as a single MCP server and aggregates every server listed in ~/.toolsieve/config.json. Edit that file while it runs and it re-aggregates without a restart.

  1. 01

    find_tools

    find_tools(query, k=3)

    Returns the best semantic match with its full input schema, the runners-up as name plus description, an also_available roster grouped by server, and a token-savings receipt for the lookup.

  2. 02

    call_tool

    call_tool(server, tool_name, args)

    Proxies the call to the MCP server that owns the tool and returns its real result. No shim, no re-implementation.

  3. 03

    get_savings_report

    get_savings_report()

    Running token totals for the current session, so you can check the savings rather than take them on trust.

Connectivity

Every transport MCP defines.

Downstream servers connect however they already run. toolsieve dials each one over whichever transport its config entry names, and follows OAuth discovery automatically for the ones that gate access behind it.

stdio

A local command toolsieve spawns and talks to over stdin and stdout. What most self-hosted and CLI-installed servers use.

Streamable HTTP

The current MCP remote transport. Give it a url and nothing else is required for a server that does not gate access.

SSE

The legacy remote transport, still what plenty of servers ship. toolsieve keeps speaking it for servers that have not moved to Streamable HTTP.

OAuth

For servers that authenticate through a browser instead of a static token. An unauthenticated request comes back 401 with a WWW-Authenticate header, the discovery mechanism MCP itself defines. Sign in once with toolsieve-auth and the session refreshes on its own after that.

Benchmarks

181 tools. 25 servers. 159 queries.

Measured against the full-catalog baseline on the same corpus, counted with a real tokenizer rather than the runtime chars-per-token estimate. Each card names the catalog it was measured on, because the numbers move with catalog size.

Tokens per resolved lookup, 181-tool catalog

Full catalog, every request0 tokens
toolsieve0 tokens

Tokens saved per find_tools call

At 50 tools0.0%
At 181 tools0.0%

Correct tool in the response, 181-tool catalog

First match0%
Named anywhere in the response0%

Right tool found vs. BM25, 50-tool catalog: all queries

toolsieve0%
BM250%

Right tool found vs. BM25, 50-tool catalog: paraphrased queries sharing no vocabulary

toolsieve0%
BM250%

Below roughly 10 aggregated tools, exposing the full catalog is cheaper, so do not use this. Loading a catalog is a one-off while routing is charged per lookup, so at 181 tools toolsieve is ahead for about the first 26 lookups of a session. Working the other way: this catalog averages 80 tokens per tool, where live public MCP servers measure about 154 and a GitHub-heavy set about 269, and the saving grows with schema size. These figures are the conservative end.

Install

Python 3.11+, uv, one command.

Run it with uvx and point it at the servers you already have. toolsieve-setup can rewrite an existing client config in place, so read the diff before you apply it.

  1. 01

    Run it

    No install step. uvx fetches and runs it.

    uvx toolsieve
  2. 02

    List your servers

    Standard mcpServers entries in ~/.toolsieve/config.json. Local commands and remote URLs both work, ${ENV_VAR} is interpolated in headers, and OAuth servers need only a url.

    {
  "mcpServers": {
    "docs":     { "command": "node", "args": ["/path/to/docs-mcp/dist/index.js"] },
    "mintlify": { "url": "https://mcp.mintlify.com" },
    "linear":   {
      "url": "https://mcp.linear.app/mcp",
      "headers": { "Authorization": "Bearer ${LINEAR_TOKEN}" }
    }
  }
}
  3. 03

    Point your client at toolsieve

    Replace the individual server entries in your MCP client with this one.

    {
  "mcpServers": {
    "toolsieve": { "command": "uvx", "args": ["toolsieve"] }
  }
}
  4. 04

    Or migrate automatically

    toolsieve-setup finds existing client configs, shows you the change, then applies it. Clients with a project-scoped config get one.

    uvx toolsieve-setup --list
uvx toolsieve-setup --client claude-code --dry-run
uvx toolsieve-setup --client claude-code --apply
uvx toolsieve-setup --verify
Compatibility

Migrate the config you already have.

toolsieve-setup finds each client's config file and rewrites it in place: Claude Code, Claude Desktop, Cursor, Devin Desktop, VS Code, Codex CLI, and Devin CLI.

  • Claude logoClaude
  • Cursor logoCursor
  • VS Code logoVS Code
  • Codex CLI logoCodex CLI
  • Devin logoDevin
Roadmap

Where this goes next.

Two features being scoped out past what ships today, not a wish list.

Tracing and observability

Next: an open-source dashboard, built on ClickHouse, that traces token burn and tool reliability across the whole organization instead of one session.

  • Token burn per server and per tool
  • Per-user attribution
  • Trend over time, with budget alerts
  • Latency and error rates per tool

Faster to run, cheaper to run

Next: less friction getting toolsieve configured, and a lower token cost once it is.

  • Sharper CLI feedback and clearer config diffs
  • Fewer tokens per resolved lookup, without losing the accuracy margin over BM25