Melra Puts a Gate Between Your AI Agent and the Tools It Should Not Touch

Melra Puts a Gate on Risky MCP Calls

Melra is a new open-source tool that tries to solve one of the least glamorous, most important problems in AI agent development: what happens when your agent calls a tool it should not have called. Posted to Show HN on October 20, 2026, Melra, short for Modular Execution Layer for Reliable Autonomy, is an Apache-2.0 local MCP runtime that sits between an agent and its tools. It checks each call against a policy, asks a human for approval on risky actions, verifies the evidence a tool claims, and keeps a redacted receipt for every call.

That sounds boring until you have watched an agent delete the wrong file, send the wrong email, or retry a payment because a timeout made it think the first attempt failed. Those are not hypothetical failures. They are the everyday failure modes of agents that can act in the real world, and they are the reason many teams are nervous about giving agents write access to production systems. Melra's answer is to add a layer whose whole job is to say wait, check, and prove it, before anything irreversible happens.

How the Melra MCP Runtime Works

MCP, the Model Context Protocol, is how agents connect to tools, data sources, and services. The agent asks for a tool call, and the MCP server runs it. Melra sits in the middle of that exchange. When a call comes in, Melra checks it against a policy you define, so a read-only research task cannot suddenly become a database write. For risky actions, it requests human approval instead of letting the agent proceed on its own. It also verifies declared evidence, meaning it checks that a tool's claimed result actually matches what happened, rather than taking the tool's word for it.

Two design choices stand out. First, mutations are dispatched at most once per task. That rule directly targets the double-spend, double-send, double-delete problem, where a retry after a timeout creates a second, unwanted effect. Second, calls with uncertain outcomes, like timeouts, are parked for reconciliation rather than replayed. Instead of guessing whether the first attempt worked and trying again, Melra holds the call aside until a human or a reconciliation process can confirm what actually happened. That is slower than blind retry, and that is the point. For agents that touch money, data, or customer systems, slow and correct beats fast and duplicated.

Why This Matters for Developers Building Agents

If you are building agents today, you have probably already built a version of this yourself, badly, in application code. A check here, a confirmation prompt there, a log line somewhere else, all of it tangled into the agent's logic and hard to audit. Melra pulls that concern into one place, with a receipt per call that is redacted, so sensitive data does not end up in logs by accident. That separation matters for debugging, for compliance, and for the moment when something goes wrong and you need to answer a simple question: who did what, when, and with whose approval?

The project labels itself alpha, and that label should be taken seriously. It installs with a single command that writes itself into your chosen MCP client's config, which is convenient, but alpha software that sits in the path of every tool call deserves careful testing before it touches production. The right way to try Melra is on a non-critical agent first, with a narrow policy, and with the receipts actually reviewed, not just collected. If the approval flow annoys developers on safe actions, the policy is too broad. If it never triggers, the policy is too narrow. Tuning that balance is the real work, and it is work every agent team has to do eventually.

Melra in Context: the Agent Tooling Wave

Melra arrived in the same week as other agent tooling, including Gauge CLI, which runs real coding agents against a product to find where they get stuck, covered in our Gauge CLI article. The two tools solve opposite sides of the same problem. Gauge finds where agents break in testing. Melra tries to stop them breaking things in production. Together, they point to a maturing field: the first wave of agent tools was about making agents more capable, and the current wave is about making them safer, more observable, and easier to trust with real work.

That shift is overdue. The history of developer tools is full of moments where capability ran ahead of safety, and the correction always arrived in the form of boring infrastructure: linters, tests, code review, and deployment gates. Melra is an attempt to build the deployment gate for agents, before a high-profile agent mistake forces everyone to build one in a panic. It may not be the tool that wins that role, but the role itself is now clearly needed.

Should You Try Melra?

Try it if you are building agents that call tools with side effects, especially in a team setting where you need approvals and audit trails. Skip it for now if your agents only read data and produce text, because the extra layer adds complexity without much benefit. Either way, the design principles are worth stealing, even if you do not adopt the tool: dispatch mutations at most once, park uncertain calls instead of replaying them, require approval for risky actions, and keep a receipt you can actually read later. Those four rules would prevent a surprising number of agent incidents, with or without Melra.