MCP Boundary

FAQ

Short answers about profiles, downstream servers, transparent mode, dashboard role, blocked calls, unclear outcomes, and Gmail claims.

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?

No. The dashboard shows setup, tools, policy, and activity. It does not approve, retry, force-run, or start arbitrary tool calls.

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:

  • docs/publish/README.md
  • docs/publish/getting-started.md
  • docs/publish/server-setup-and-auth.md
  • docs/publish/real-gmail.md
  • docs/publish/policies.md
  • docs/publish/tested-servers-and-limits.md