Conduit

The token overhead problem is real - 24k tokens before the agent does anything is a genuine waste. My question is about the 'same task success' benchmark scope. Tasks like 'list the projects in Vercel' are the easy case for lazy discovery because the right tool is obvious from the description. What happens on tasks where the agent needs to plan across tools it doesn't know upfront - say 'debug why my payment flow is broken' across Stripe, your DB, and Vercel logs simultaneously? Does the search-first approach still converge reliably, or does it end up doing multiple search round trips that eat back some of the savings?

This matches the pain from long-running agent work: the tool catalog becomes infrastructure noise. I like that the agent asks for the catalog when it needs it instead of carrying every tool description into every turn. Stale schema handling is the contract I would keep very visible.

~90% token cut on MCP is a big claim and a real pain point. is that from trimming tool schemas/results or actual response compression?

The 90% token reduction claim is the part I want to understand better. Is that coming from stripping context on the client side before it ever hits the model, or are you doing something smarter like caching tool descriptions and only sending diffs when the schema hasn't changed? Those are pretty different architectures with pretty different failure modes. Also curious how Conduit handles situations where the MCP server schema changes mid-session, since a stale cached description passed to the model could cause subtle tool-call errors that are annoying to debug.

This is exactly the kind of agent-infra pain that is easy to miss until it becomes a bill or latency problem. The tool-list bloat detail is useful because it names a concrete failure mode, not just “too many tokens.” Curious: do you see teams wanting per-server/per-tool usage visibility too, or is the gateway meant to stay invisible once configured?

Hey, congrats!Could you please elaborate on benchmarking the solution - how did you measure the success rate, and what benchmarks did you use?

The tool list bloat before you even start a task is so real, glad someone is fixing it at the gateway layer instead of inside each agent. Does it handle servers that change their tool list at runtime, or is the catalog cached per session? Congrats on shipping.

MCPs definitely eat into the token usage at ridiculous rates. How is your service different from other similar solutions?

Hi Product Hunt 👋I'm Tyler, the maker of ConduitI kept adding MCP servers to my AI tools, and the more I added, the slower and less reliable my agents got. The reason surprised me: every MCP server loads its entire tool list into the model's context on every single request. On my setup that was roughly 24,000 tokens of tool definitions sitting in context before I'd typed a word, and the model discards all of it between calls, so you pay for it again on the next one.Conduit fixes that. It's a local-first gateway that sits between your AI tools and your MCP servers. Each client connects to it once, and instead of exposing every tool, it exposes three meta-tools the agent searches on demand. The full catalog is still available; it just no longer sits in context on every request.I benchmarked it on a real setup: 97% less tool overhead per request, around 90% fewer total tokens, at the same task success rate. The full method and numbers are in the repo.This helps no matter how you work. On cloud models, those tokens are your bill. On local models, the tool definitions eat your context window. Either way, you stop paying for tools the agent never calls.A few things I focused on:• API keys stay in your OS keychain, never in a config file• Nothing phones home, it's fully local-first• Works with 17 clients today across Windows, macOS, and Linux• Free and open sourceI'd love your feedback, especially on which MCP servers or clients you'd like supported next. Thanks for checking it out 🙏