MCP Boundary v0.1.3 - boundary checks for MCP tool calls with real side effects (last build was broken, now fixed. Agent loop stopped in the shown example)
Follow-up to my post from two weeks ago. People downloaded it, but that build (v0.1.0) was broken - it likely wouldn't even start, and we didn't catch it at the time. It's fixed now (v0.1.3). Reposting for anyone who tried that version and wrote it off - it actually runs now.
>The problem we are trying to solve is: tool access is not the same as impact permission. A model or agent may be allowed to call a tool, but that does not always mean this specific write, delete, update, or retry should happen now.
A few things you can do with it:
- restrict arguments, not whole tools (for example, allow sending only to approved recipient domains)
- bind writes to observed state, so a write does not run if the world changed since the read
- see every call, decision, reason, and outcome in a local dashboard
MCP Boundary checks each call against your policy and the current state before it hits the real system. It then allows it, blocks it, or asks the agent to refresh state - and when it blocks, the agent gets a structured reason it can act on, not just an error.
It runs locally, and wraps your existing command-based (stdio) MCP servers within 2 minutes.
It is not an enterprise gateway, a DLP system, or a prompt-injection detector, and it only covers calls routed through it.
I'm looking for feedback from people running MCP workflows with side effects - especially where the policy model is too strict or too loose for your setup.
Site: https://mcpboundary.com
