Is this one MCP server for everything?
No. Your agent normally gets one MCP Boundary entry per profile:
gmail -> mcpboundary serve gmail github -> mcpboundary serve github postgres -> mcpboundary serve postgres
The same binary is used, but each profile is separate. Tools are not merged into one giant shared list.
Does MCP Boundary replace my MCP server?
No. It starts or connects to the downstream MCP server and sits in front of concrete tool calls.
Does transparent mode mean passthrough?
No. Transparent mode reduces first-run friction by exposing discovered tools unless policy says otherwise. Calls still go through the checked runtime path.
Does the dashboard approve calls?
For normal allowed or blocked calls, no approval is involved. For review_required calls, current builds can show a pending local approval. With the local operator token - the same dashboard edit token printed when the dashboard starts - the dashboard can approve or reject that exact pending item.
The dashboard still does not retry, force-run, resume, or start arbitrary tool calls. Approval is not execution. The agent must make a later call with top-level approval_retry metadata and the original arguments.
The retry is a new tools/call. Put approval_retry beside arguments under params, not inside the downstream tool arguments. Use the exact pending and approval IDs returned for the approved item, and resend the same tool name and original arguments:
If an approval says Needs context, the requested values are incomplete and cannot be reviewed safely. Reject it and ask the agent or client to resend explicit values. For list fields, an explicit empty list such as [] is reviewable; null is not.
What happens if a call is blocked?
The downstream server should not be called. Activity should show the decision and reason.
What if a call may have happened but the result is unclear?
Do not blindly retry. Check the remote system first. MCP Boundary should report unknown-result style outcomes honestly when final confirmation is not clean.
Does this make Gmail safe?
No. MCP Boundary can route configured Gmail MCP tool calls through a checked path, but it does not make arbitrary email actions safe. Use narrow policies, test with controlled accounts, and open send/delete/trash tools intentionally.
What if the agent claims it sent email, but nothing arrived?
Use Activity as the first source of truth. If there is no send row, the agent did not send that action through MCP Boundary. If the row is blocked, the downstream send tool should not have run. If the row is completed, the downstream server reported success.
MCP Boundary does not yet independently verify provider-side sent-folder or recipient delivery after a send. That is a planned follow-up for email profiles, not a current guarantee.
The same distinction matters for the agent: a blocked or failed send result should tell the agent "not sent"; an unknown final state should tell it "verification required". If the agent never routed a send tool call through MCP Boundary, MCP Boundary cannot correct a later free-text claim by itself.
Where are the full docs?
Use the website guides:
- Getting Started
- How It Works
- Real Gmail Setup
- MCP Tool Rules
- Tested Servers And Limits
- Glossary
- Known Limitations
Additional setup, authentication, and full policy manuals ship inside the downloaded ZIP/tarball under docs/mcpboundary/publish/guides/ and docs/mcpboundary/publish/tool_rules/.
Does Linux credential login always work?
No. Boundary credential-store/login on Linux depends on an OS keyring backend such as Secret Service.
The Linux package smoke exercises a bounded credential CLI unavailable/no-leak path with fake values and verifies that fake credential values do not leak to smoke files or logs. It proves the bounded credential_store_unavailable path, not a successful desktop keyring storage path, real-provider OAuth readiness, or production credential security.
Minimal or headless Linux environments may return credential_store_unavailable.