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: Local Package Flow

The current 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 local human approval for selected review-required calls
use the local email demo to understand read, draft, and blocked send flows

This 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.

Human Approval And Clear Agent Feedback

Human approval is now a local beta path.

Current builds support:

a tool result that clearly tells the agent: approval required, not executed
pending actions in the local dashboard
approve or reject for one exact pending action
a later agent retry with top-level approval_retry metadata, using the concrete retry shape in the FAQ
no generic "run anyway" button
no bypass around Core decisions, execution binding, or outcome recording

Approval does not execute the tool from the dashboard. Follow-up work should improve persistence, operator identity, retry guidance, and approval-state copy.

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, data-loss-prevention, 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>

Current setup work includes:

dashboard import from existing MCP client config
Detect servers
Import selected or import all
Agent Config generation for the protected MCP client entry
connection timeout and retry settings on the selected profile
inspection controls for initialize/tools-list without executing tools
Builder editing for normal policy controls and complete developer Policy JSON
Manual Policy mode when tool metadata is not loaded

Current and planned improvements:

easier first-run setup from ZIP downloads
clearer first-run copy for package users
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

Current packaging status:

Windows ZIP artifact built and smoke-tested
Linux tarball artifact built and smoke-tested in a Linux environment
bounded Linux credential CLI no-leak path smoke-tested with fake values
checksums generated for both artifacts
first-run docs included in the package
release notes match the tested scope

The Linux credential smoke does not prove desktop Secret Service availability, real-provider OAuth readiness, or production credential security.

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
data-loss-prevention guarantees
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.