MCP Boundary by Impact Boundary Labs
Documentation navigation

MCP Boundary

Roadmap

Public-facing roadmap for MCP Boundary local release work, approval, email verification, setup, dashboard, packaging, compatibility, and non-claims.

MCP Boundary is built around one idea:

let agents use useful MCP tools, but make concrete actions visible, bounded,
and policy-controlled.

This roadmap is public-facing. It describes what we are working on, not a promise that every item is already available.

Current Focus: First Public Local Release

The first release focuses on a local workflow:

  • install mcpboundary locally
  • add an MCP server profile
  • route agent tool calls through MCP Boundary
  • inspect tools and activity in the local dashboard
  • start with transparent behavior
  • harden behavior with explicit policies
  • use the local email demo to understand read, draft, and blocked send flows

The first release is not a hosted gateway and not a production security product. It is a scoped local tool for developers and operators who want more visibility and control around MCP tool calls.

Next: Human Approval And Clear Agent Feedback

The next major product area is human approval.

Today, policies can allow or block tools. A future approval flow should support:

  • a tool result that clearly tells the agent: approval required, not executed
  • a dashboard queue for pending actions
  • approve or reject for one exact pending action
  • no generic "run anyway" button
  • no bypass around Core decisions, execution binding, or outcome recording

This matters especially for actions like sending email, changing files, updating tickets, or touching production-like systems.

Next: Email Action Verification

Email is a key use case.

The intended path is:

  • read email metadata
  • create drafts
  • send only when intentionally enabled
  • record exactly what happened
  • tell the agent when an email was not sent
  • avoid letting the agent claim success when the tool did not succeed

Planned follow-up work:

  • clearer agent-facing send statuses
  • post-send verification where a provider or downstream MCP server can safely confirm sent-folder state
  • better guidance for Gmail-like downstream-managed OAuth servers
  • more tested email server candidates

This is not an email safety, DLP, or prompt-injection protection claim.

Setup And Onboarding

We want adding a server to feel close to adding an MCP server in an agent:

powershell
mcpboundary add-server gmail -- <server command>

Planned improvements:

  • easier first-run setup from ZIP downloads
  • clearer profile import from existing MCP client configs
  • better dashboard setup flow
  • stronger explanations for auth setup
  • fewer technical words on first-run screens

The goal is not to hide how MCP works. The goal is to make the first successful run easier.

Dashboard Improvements

The dashboard should help users understand what is happening.

Planned improvements:

  • clearer profile/server switcher
  • better multi-profile workspace view
  • less card-heavy layout where table-like views are easier to scan
  • clearer difference between setup/discovery mode and running agent mode
  • better empty states and explanations
  • better activity details for blocked, failed, unknown, and completed calls

The dashboard is still a local visibility and setup surface. It should not become an unbounded remote admin console.

Packaging

Near-term packaging work:

  • refreshed Windows ZIP artifact
  • Linux artifact
  • checksums
  • clear first-run docs for ZIP users
  • release notes that match the tested scope

Future packaging work may include installers or additional platforms, but those should come after the ZIP flow is reliable.

More MCP Server Compatibility

We will keep testing real MCP servers.

Current evidence is intentionally scoped. A server may be:

  • verified for discovery only
  • verified for one read-only call
  • verified for draft or send flows
  • blocked by auth setup
  • blocked by provider access
  • blocked by transport or protocol mismatch

Future compatibility work should add more candidates without claiming universal support.

Later: Larger Workspace Control

Longer-term ideas:

  • one dashboard showing many configured profiles
  • helper process for starting/stopping several local Boundary profiles
  • better diagnostics for several running MCP servers
  • optional richer policy authoring flows

This does not mean one shared remote gateway for every MCP server. The current model remains local and profile-based.

What We Do Not Plan To Claim

MCP Boundary should stay honest about what it does.

We do not plan to claim:

  • production security
  • universal MCP tool safety
  • DLP
  • prompt-injection protection
  • hosted multi-tenant gateway behavior
  • that all Gmail, Outlook, GitHub, database, browser, or filesystem servers work
  • that sending email is safe by default

When a path is verified, it should be documented as exactly that path, with the server, auth model, tool, and limitation clearly named.