The important model:
Gmail MCP server owns Google login and token files. MCP Boundary owns the MCP execution boundary.
For the tested downstream-managed stdio Gmail path, the Google OAuth client type was Web application because the server used a local browser callback URL. Redirect URI host, port, and path must match exactly; localhost and 127.0.0.1 are not interchangeable.
Setup Shape
- Install the Gmail MCP server.
- Configure its Google OAuth client exactly as its README requires.
- Run the server's own auth flow.
- Confirm the server works directly.
- Add it to MCP Boundary with
auth_mode=downstream_managed. - Start with one read/list/metadata tool.
- Open draft/send/trash tools only when you intentionally test them.
Example:
From an extracted Linux package, use the package-local binary:
If MCP Boundary is installed on your PATH, the command may start with bare mcpboundary. Package-first examples use ./mcpboundary.
First Policy
Start narrow:
Copy exact native downstream tool names from your Gmail MCP server. The client-safe names shown to the agent may replace dots with underscores, but the Policy still uses the native name in downstream_tool_name. Another server may use different names.
What To Test First
First:
list labels search messages read metadata
Later:
create one controlled draft send one controlled test email apply one controlled label/trash action
Do not start by making every Gmail tool requestable.
Common Gmail Auth Issue
If Google shows redirect_uri_mismatch, add the exact URI shown by Google to your OAuth client. Match host, port, and path exactly.
A longer guide also ships inside the downloaded ZIP/tarball at docs/mcpboundary/publish/guides/real-gmail.md.