MCP Boundary
Wrap selected MCP tool calls before they create real effects.
Import an existing MCP config, place one server behind the boundary, inspect the available tools, define a guarded profile, and export a replacement client config for local preview.
Current scope: local developer/operator preview for selected MCP tool calls.
What you can do today
A practical local preview for one wrapped MCP server.
MCP Boundary is for builders and operators who want to test a decision boundary on a real agent-tool path before downstream effects happen.
Connect
- Import an existing MCP config.
- Wrap one MCP server.
Guard
- Expose selected tools.
- Configure explicit policy inputs.
Inspect
- Inspect tools, policy, runtime facts, activity, and profiles.
Export
- Export a replacement MCP client config.
- Run local stdio now.
Setup flow
From existing config to replacement client config.
Start from a client config you already use, define the guarded profile, then point the agent client at the replacement config for local preview.
01
Existing MCP config
02
Impact Boundary profile
03
Selected tools
04
Policy/runtime facts
05
Replacement config
06
Agent through boundary
Tool-call path
What happens on a tool call.
Blocked calls create no downstream effect. The agent receives structured feedback and can submit a corrected new request.
Structured feedback can guide
a corrected new request.
Same bad request repeated
→ loop stopped.
Structured feedback can guide
a corrected new request.
Same bad request repeated
→ loop stopped.
Guarded profiles
A profile says what is wrapped and how calls are handled.
What the profile controls
A profile defines which server is wrapped, which tools are exposed, and how selected calls are handled before admitted work can execute.
It keeps the requestable surface explicit for local preview instead of treating every MCP tool as safe.
- wrapped server
- one MCP server placed behind the boundary
- exposed tools
- selected requestable tools, not an arbitrary surface
- call handling
- how selected calls are checked before execution
- policy inputs
- explicit inputs used by the Core decision
- diagnostics
- local inspection of tools, facts, activity, and outcomes
Diagnostics
Make the boundary inspectable during local preview.
The preview is designed to show what was exposed, what was checked, and what happened after the Core-owned decision.
Local inspection
localhost diagnostics
Tool surface inspection
what the wrapped server exposes
Policy snapshot
the inputs used for this guarded profile
Runtime facts
observed state bound to the request
Activity
selected requests and decisions
Local diagnostics
reasons and outcomes for local review
Current limits
Narrow preview, explicit non-claims.
MCP Boundary should be evaluated as a local preview for selected tool calls, not as a broad safety or compatibility layer.
Current scope
- - local developer/operator preview
- - selected MCP tool calls
- - localhost diagnostics
Not claimed
- - production security
- - DLP
- - prompt-injection detection
- - arbitrary MCP tool safety
- - full MCP capability coverage
- - durable enterprise audit
- - broad GitHub/Gmail/DB compatibility
Deferred / outside this preview
- - remote HTTP transport notes
- - broader compatibility validation
- - durable audit design
Early Access Setup
€139 one-time for the first 15 setup slots.
Includes one focused setup session for one real MCP workflow.
For builders and small teams working with real MCP servers or agent-tool workflows.
We help you wrap one existing MCP server or workflow, inspect the available tools, define one guarded profile, and document which actions should be allowed, reviewed, or blocked.
You get short written notes for the tested workflow: what was exposed, what should be allowed, what should be reviewed, and what should be blocked.
This is not a full security audit, hosted enterprise platform, or ongoing managed support. It is a focused setup to test MCP Boundary on one real agent-tool workflow.
Beyond MCP
The Core works without MCP too.
MCP Boundary is the current product surface. The underlying Core pattern can also sit behind a custom adapter for your own application, API, workflow, or internal tool. Build your own adapter, or contact us to discuss one concrete boundary path.