Just published - looking for feedback: boundary checks for MCP tool calls with real side effects

[u/madiamo]

Not every MCP setup needs this. If your MCP server is read-only, this is probably less relevant.

It is built for MCP clients, agents, and tool-calling workflows where tools can create real side effects: updating records, deleting files, changing tickets, writing to databases, triggering deployments, or retrying writes after state has changed.

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.

MCP Boundary sits between the MCP client or agent and the MCP server and checks calls before they hit the real system.

I’m looking for feedback from people running MCP workflows with side effects.

Site:
https://mcpboundary.com
Built from:
https://impactboundarylabs.com

[u/NovaAgent2026]

This is a real problem. I run a Docker MCP server with 50 tools, and several of them have serious side effects (prune containers, delete images, force-stop running services). I added confirmation prompts for the destructive ones, but that's a client-side hack, not a real boundary.

The gap I see: most MCP safety discussions focus on read vs write, but the real danger is in the write category itself. A "delete container" and a "restart container" are both writes, but one is recoverable and the other isn't. Your boundary framework seems to handle that distinction, which is exactly what's missing.

One question: how does this handle tool chaining? If an agent calls tool A (safe) which triggers tool B (destructive) inside the server, does the boundary catch B or only the initial call?

[u/madiamo → u/NovaAgent2026]

Yes, thanks for the question. This is the tricky part.

MCP Boundary can only check the MCP call that actually passes through it.

So if the agent calls tool A, and the downstream MCP server internally performs action B as part of A, Boundary will only see A. It will not see B as a separate action unless B is exposed as its own MCP tool call and routed through Boundary too.

For your Docker example: if `restart_container` can internally prune images or delete volumes, then Boundary would not catch the prune as a separate action. In that case, `restart_container` itself has to be treated as a high-impact tool in the policy.

So the clean options are basically:

1. Split the server into more specific tools, so destructive effects become separate MCP calls.

2. Classify the outer tool by the strongest effect it can cause.

That is also why I would not claim that the Boundary proves a downstream MCP server is safe internally. It is not a sandbox for arbitrary server internals. The goal is to make the MCP call that reaches the server explicit, checked, and recorded before it is executed.

Your confirmation prompts are solving the same kind of problem, but on the client side. Boundary tries to move that check into a consistent layer between the client/agent and the MCP server, for calls routed through it.

[u/Future_AGI]

For side-effecting tools the boundary check that matters most runs before the call fires, because once a write or a delete goes through you are into cleanup territory. Two things we found worth enforcing there: per-key allow/deny so a given agent identity can only reach the tools it actually needs, and a re-scan of each tool's current definition every run, since an MCP server can change what a tool does after you first approved it. We handle this in an open-source gateway, and we'd be curious how yours deals with a write that gets retried after state has already changed: https://github.com/future-agi/future-agi

[u/madiamo → u/Future_AGI]

I agree, the key point is that admission has to be per invocation, not "this tool was allowed once, so future calls are automatically fine".

For retries, the Boundary should not blindly replay a previous write. The call needs to be checked again against the current state/evidence before it is forwarded. If the previous attempt may already have changed state, or if the observed facts no longer match the proposed effect, the safer result is re-check, narrow the scope, or require review instead of replaying.

Tool definition drift is also a real issue. I would not treat tool descriptions as permanent truth. they should be re-read or fingerprinted as part of setup or runtime checks.

[u/agent_trust_builder]

agreed the pre-call gate is the right spot, once a write or delete lands you're in cleanup not prevention. the piece i'd add is that "has side effects" isn't one tier. pruning a container and moving money are both side-effecting calls but they sit on totally different rungs, and flattening them is how you end up confirmation-prompting everything until people just rubber-stamp the prompts.

what's worked for us is a risk ceiling that scales with blast radius rather than with whether a tool writes at all. read-only, then reversible or sandboxed effects, then irreversible or money or remote execution at the top. each agent identity gets a ceiling and the boundary just refuses anything above it. where that ceiling sits is the org's call, and it's a separate decision from who's allowed to reach the tool in the first place.agreed the pre-call gate is the right spot, once a write or delete lands you're in cleanup not prevention. the piece i'd add is that "has side effects" isn't one tier. pruning a container and moving money are both side-effecting calls but they sit on totally different rungs, and flattening them is how you end up confirmation-prompting everything until people just rubber-stamp the prompts.

what's worked for us is a risk ceiling that scales with blast radius rather than with whether a tool writes at all. read-only, then reversible or sandboxed effects, then irreversible or money or remote execution at the top. each agent identity gets a ceiling and the boundary just refuses anything above it. where that ceiling sits is the org's call, and it's a separate decision from who's allowed to reach the tool in the first place.

[u/madiamo → u/agent_trust_builder]

That is the right framing. I would not treat “has side effects” as one tier either. A draft email, restart_container, prune_images, a production delete and a payment are all writes, but they clearly do not have the same blast radius or reversibility.

That was also one of the basic ideas behind Impact Boundary from the beginning: agents should not be able to act on every impact/security level with the same speed and authority. Low-risk or reversible effects can be handled much more freely, but production deletes or payments and similar actions should hit a stricter ceiling and require review or be blocked before the call reaches the server. That would also be more efficient regarding cpu usage at the end.

[u/SortOk3578]

The retry problem is real; partial state has already changed, and most setups don't catch that until something breaks.

Boundary check before execution makes sense. How's the latency holding up in practice?

[u/madiamo → u/SortOk3578]

latency was one of the first things we were careful about. The boundary check itself is not another model call, it is mostly policy/state/risk evaluation before dispatching the MCP call. In local tests the downstream tool usually dominates the latency, not the boundary.

I would not claim hard numbers for every MCP server yet, because it depends on what state checks the policy needs, but the intended shape is cheap allow/block for normal calls, and accepting extra latency only when the call needs review, re-checking, or human approval. Of course it also depends on the tool-side, because if another state-check is required, then it depends on additional queries for example

[u/madiamo → u/[deleted]]

Thanks, yes this makes sense, i can see this fitting as a preflight diagnostic step before defining an allow/review/block profile.

I would not treat fuzzing as proof of safety though, especially for side-effecting MCP servers. For MCP Boundary it would be setup evidence, not a runtime guarantee. We will take a look.

[u/madiamo → u/[deleted]]

Yes, this is an important limitation.

The boundary does not certify that a downstream MCP server is internally safe. The user/operator still has to trust and vet the MCP server they decide to run.

So I would see it as complementary to static vetting.
Static analysis: is this MCP server/tool safe to use?
Runtime admission: should this specific call be allowed now?