heku turns MCP servers into a config file. No more custom auth, transport, and tool boilerplate for every API you plug into an agent. Point it at an HTTP API, a database, gRPC, or another MCP server. A tiny manifest exposes config dicovery tools first, so the LLM lazily discovers tools only when needed. Context stays lean, credentials stay isolated, tools hot-reload mid-session. Apache 2.0. The boilerplate harness I kept rewriting by hand.
No reviews yetBe the first to leave a review for Heku
Maker
📌
Hello all,
First off, thank you for taking the time to go through this.
My name is Ruchit and I build custom agent harnesses for different business domains. Across all the harness projects I've built so far, I kept feeling restricted by MCP — not because anything's wrong with the protocol, but because we've been implementing it from the wrong perspective.
So I built heku. Adding Postman, Jira, or Bitbucket capabilities to my agent is no longer a long list of steps, it's a few clicks through a config. Any API, whether it's your own product or something you use daily like GitHub, becomes an MCP tool through a hot-reloaded config.
The part I'm most excited about: agents can now correct their tools, not just call them. You can add new tools mid-session, pulling from a config I've already pre-seeded in the heku Hub registry. You can grow your API surface into MCP tools in seconds, in the same conversation.
I also added lazy discovery, so the manifest stays around 700 tokens. Those are just discovery tools that let the agent find and load the real tools when it needs them, instead of dumping everything into context up front.
It's Apache 2.0, install is npm i -g @rapidthoughtlabs/heku. I'm the solo builder behind it and I'll be around all day, would genuinely love your feedback, especially from anyone running MCP in production.
What's been your biggest friction with MCP so far?
Report
How does tool hot-reloading mid-session actually work without confusing the model mid-conversation, especially when schemas change?
Report
Maker
@fatmanurcink2r Heku only exposes 3-4 tools for discovery of the tools from the configs it manages. Only you know what capabilities your model has, agent then uses to 4 tools to implicitly discover exact tools it need to call using heku search tool and makes the call to that tool. This allows a tiny manifest but also makes heku a black box to your agent. If you are building a bespoke solution, you call list_config tool and save its result into the system prompt and make sure it refresh the tool call before next user message comes in, that way your agent will always remain updated what configs it has already which will also bring down the tool calls needed to search the right tool. Hope this helps!
Report
the lazy discovery via a tiny manifest is genuinely clever, keeps the context window from bloating when you point it at a dozen APIs. love that credentials stay isolated too.
How does tool hot-reloading mid-session actually work without confusing the model mid-conversation, especially when schemas change?
@fatmanurcink2r Heku only exposes 3-4 tools for discovery of the tools from the configs it manages. Only you know what capabilities your model has, agent then uses to 4 tools to implicitly discover exact tools it need to call using heku search tool and makes the call to that tool. This allows a tiny manifest but also makes heku a black box to your agent. If you are building a bespoke solution, you call list_config tool and save its result into the system prompt and make sure it refresh the tool call before next user message comes in, that way your agent will always remain updated what configs it has already which will also bring down the tool calls needed to search the right tool. Hope this helps!
the lazy discovery via a tiny manifest is genuinely clever, keeps the context window from bloating when you point it at a dozen APIs. love that credentials stay isolated too.