Docker MCP Gateway centralizes multiple MCP servers and runs catalog servers in containers with explicit profiles, secrets and tool selection. It reduces direct host exposure but does not make third-party servers or deliberately granted permissions trustworthy.
Key takeaways
- Presents multiple containerized servers through one gateway.
- Supports profiles, catalogs, secrets, OAuth, discovery and call tracing.
- Container isolation depends on mounts, network policy and Docker daemon security.
What is Docker MCP Gateway?
Open-source gateway and Docker CLI plugin for running MCP servers in isolated containers behind one client connection. MCP standardizes how a compatible client discovers and invokes tools, but it does not make those tools safe automatically. The client, server, credentials and upstream service remain separate trust boundaries.
What tools does it expose?
- Create profiles containing selected MCP servers.
- Discover and filter tools, resources and prompts.
- Manage catalogs, secrets, OAuth and client connections.
- Run stdio or authenticated streaming transports.
The exact catalog can change by release, account, enabled feature or server configuration. Inspect the live tool list and JSON schemas before enabling it. A descriptive tool name is not an authorization control, and a read-sounding operation can still reveal sensitive metadata.
What is a safe first test?
Create a profile with one low-risk documentation server and expose only one tool. Inspect the container, mounts, network destinations and call log before adding any server that needs secrets or writable storage.
Use a test account or project, allow only the required tools and record the client configuration, server version and arguments. Verify the result directly in the upstream service. Add write tools only after read-only behavior, authentication expiry, error handling and audit logs have been reviewed.
What data and credentials can it access?
The gateway sees MCP requests and responses and passes declared credentials to configured servers. Enabled containers receive only the mounts, environment, secrets and network access granted by the operator.
Credentials should be supplied through the documented OAuth flow, a secret manager or a restricted environment variable, never pasted into prompts or committed to source. The upstream account should expose only the resources required for the pilot.
Which permissions should you grant?
- Access to a trusted Docker daemon.
- Only explicitly required container mounts and secrets.
- An allowlist of servers and tools for each client profile.
Prefer project-scoped, read-only or restricted tokens. Where the server offers tool filters, combine them with upstream authorization rather than treating filtering as the only control. Separate development and production identities and rotate test credentials after the evaluation.
What should a security review cover?
- Treat catalog entries and third-party images as untrusted.
- Keep HTTP bearer authentication and signature verification enabled.
- Never expose the Docker socket to an MCP server container.
Assume tool results can contain prompt injection or hostile content. Keep approval gates in application code for financial, administrative, destructive or public actions. Apply network restrictions, timeouts, output-size limits and audit logging at the host or gateway layer.
What are the main limitations?
- A compromised Docker daemon remains outside the gateway boundary.
- Third-party images outside Docker signing scope require separate trust decisions.
- Centralization can increase impact if profiles or gateway credentials are misconfigured.
This is a documentation-based profile checked on 2026-10-04; Anavem did not connect the server or test it against a live account. Tool catalogs, transport support, pricing, licensing and authentication methods can change. Verify the current first-party documentation before installation.