MCP Spotlight: Docker MCP Toolkit + Catalog + Gateway — The Reference Stack for Running, Curating, and Discovering MCP Servers at Scale

Stack: Docker MCP Toolkit · Catalog · Gateway · cagent · by Docker License: Apache 2.0 / Open Source · Maintainer: Docker (the container company) Server count: 300+ curated MCP servers in the official Docker Catalog Components: Toolkit (CLI) · Catalog (server registry) · Gateway (server runtime + discovery) · cagent (multi-agent runtime) Companion servers: mcp-find (dynamic discovery) · mcp-add (on-demand install) · mcp-exec (per-tool execution) Docs: docs.docker.com/ai/mcp-catalog-and-toolkit/

The MCP ecosystem has grown to 300+ first- and third-party servers, each with its own runtime, configuration, secrets management, and lifecycle. The "run each MCP server as a separate process" model is fine for one or two servers; it's unmaintainable at scale. The "give the agent access to npm and let it install whatever" model is a security incident waiting to happen. The naive "vendor-curated list of MCP servers" model doesn't scale across teams, organizations, or regulated environments.

Docker's MCP Toolkit + Catalog + Gateway + cagent is the reference architecture for the operational layer of the MCP ecosystem. It's not a single MCP server — it's the infrastructure that lets you run, curate, discover, and compose MCP servers at scale. Docker took its 12+ years of container experience and applied it to the new problem: how do you run untrusted MCP code in a controlled, observable, governed way?

This is the runtime substrate of the MCP ecosystem in 2026. If you're running more than a handful of MCP servers, you need this stack.

The Architecture: Four Components

The Docker MCP stack is composed of four complementary pieces:

1. Docker MCP Catalog

A curated registry of 300+ MCP servers, organized by category:

• Official vendor servers — GitHub, Notion, Linear, Sentry, Stripe, Cloudflare, etc.
• Community servers — third-party MCP servers vetted by Docker
• Local utility servers — Filesystem, Memory, Sequential Thinking, etc.
• Specialized domain servers — Bioinformatics, finance, security, etc.

The Catalog is browsable at hub.docker.com/mcp. Each server entry includes the tool surface, the required credentials, the source repository, the license, the verification status, and a one-line install command.

For organizations, Docker also supports Custom Catalogs — curated sub-catalogs scoped to a team, business unit, or compliance boundary. Instead of exposing all 300+ servers, the org defines exactly which servers are available. The agent discovers only what the org has approved.

2. Docker MCP Toolkit (CLI)

The CLI for managing MCP servers and profiles:

# List available MCP servers
docker mcp catalog ls

# Show details on a specific server
docker mcp catalog show github

# Create a profile (a named collection of MCP servers)
docker mcp profile create dev-tools --servers github,notion,linear,sentry

# Add a server to a profile
docker mcp profile add-server dev-tools --server stripe

# Set secrets for servers in the profile
docker mcp profile secret set github --key GITHUB_PERSONAL_ACCESS_TOKEN

# Run the profile as a gateway
docker mcp gateway run --profile dev-tools

# Or expose the gateway via the stdio MCP protocol
docker mcp gateway stdio --profile dev-tools

The Toolkit handles setup, authentication, and security behind the scenes. The user doesn't deal with npx install paths, npm package versions, or configuration files. The Toolkit enforces version pins, secret isolation, and server verification.

3. Docker MCP Gateway

The runtime layer that executes MCP servers on demand:

• Server lifecycle — starts MCP servers as Docker containers when needed, stops them when idle
• Tool routing — directs tools/call requests to the right server
• Secret injection — passes secrets to servers without exposing them to the agent's context
• Dynamic discovery — implements the mcp-find and mcp-add tools for on-demand server composition

The Gateway is the boundary between the agent's context (which has zero secrets, zero filesystem access, zero server-management primitives) and the operational MCP servers (which need secrets, need filesystem access, need lifecycle management).

For multi-tenant or multi-environment setups, the Gateway supports running multiple profiles simultaneously. Each profile has its own secret scope, its own server set, its own audit trail.

4. cagent

The multi-agent runtime built on the MCP Gateway. cagent lets you define multi-agent systems in YAML:

version: "1"
agents:
  root:
    model: openai/gpt-5
    description: "Engineering assistant with full tool access"
    toolsets:
      - type: mcp
        command: docker mcp gateway run --profile dev-tools
  reviewer:
    model: anthropic/claude-sonnet
    description: "Code reviewer (read-only)"
    toolsets:
      - type: mcp
        command: docker mcp gateway run --profile read-only
    inline_sub_agents: true
orchestrator:
  model: anthropic/claude-sonnet
  strategy: delegate
  agents:
    - root
    - reviewer

The orchestrator delegates tasks to the right agent based on the work. The root agent has full read/write access. The reviewer agent is read-only. The orchestrator picks the right one for each task.

For production setups, cagent enables the principle of least privilege at the agent level: the agent that reviews code doesn't need write access. The agent that deploys needs write access but not delete access. Each agent runs with the right scope.

The Dynamic MCP Pattern: Discovery + Composition

The single most important innovation of the Docker MCP Gateway is Dynamic MCP — the ability for the agent to discover, add, and compose MCP servers on-demand during a conversation.

The Gateway exposes three meta-tools:

mcp-find: Search the catalog

mcp-find(query="documentation generation")
  → Returns matching servers from the catalog with descriptions and tool counts

mcp-find(query="Stripe payments", category="official")
  → Returns official Stripe-related servers

The agent searches the catalog (or a custom catalog) using natural language. The result is a list of servers with descriptions, not raw npm packages. The agent picks the right one based on the description.

mcp-add: Install on demand

mcp-add(server="github")
  → Asks for approval (operator policy)
  → Pulls the server image from the catalog
  → Verifies the signature
  → Starts the container
  → Returns the new tool surface

mcp-add(server="notion", profile="dev-tools")
  → Adds to the named profile

The install is operator-approved (configurable policy), verified (signature check), and sandboxed (container isolation). The agent can compose its own tool surface within the bounds the operator has set.

mcp-exec: Per-tool execution

mcp-exec(tool="github.create_pull_request", parameters={...})
  → Routes to the right MCP server (github)
  → Executes the tool with the right credentials (injected from profile secrets)
  → Returns the result

The agent sees a unified tool surface across all installed MCP servers. The Gateway handles the routing, the credential injection, the lifecycle. The agent doesn't need to know that github.create_pull_request lives in the github MCP server container.

The Security Architecture

The Docker MCP stack addresses the four major security concerns with the MCP ecosystem:

1. Server verification

Every server in the Docker Catalog is verified — Docker checks the source repository, the publisher identity, the license, and the build provenance. The image is signed, and the Gateway verifies the signature before starting the container.

2. Credential isolation

Secrets are stored in the Toolkit's secret store, scoped to a profile, and injected into the server's environment at start-time. Secrets never appear in the agent's context, never appear in tool call parameters, never appear in audit logs. The Gateway acts as the credential broker.

3. Process isolation

Each MCP server runs in its own container, with its own filesystem, its own network namespace, its own resource limits. A compromised MCP server can't read the host filesystem, can't communicate with other servers, can't exceed its CPU/memory quota.

4. Tool-level RBAC

The Gateway supports per-tool RBAC. The agent can be configured to:

• Allow github.list_repositories (read-only) autonomously
• Soft-confirm github.create_pull_request (write, visible to team)
• Hard-confirm github.delete_branch (destructive, irreversible)

The RBAC layer is the policy layer. The Gateway enforces it before routing the tool call.

Facio Integration

# 1. Install Docker Desktop 4.37+ or Docker Engine with Compose V2
# 2. Install the Docker MCP Toolkit
docker mcp toolkit install

# 3. Create a profile for the agent
docker mcp profile create facio-dev --servers \
  github,notion,linear,sentry,stripe,cloudflare,filesystem,postgres,sequential-thinking

# 4. Set secrets
docker mcp profile secret set github --key GITHUB_PERSONAL_ACCESS_TOKEN
docker mcp profile secret set notion --key NOTION_TOKEN
# ... etc for each server

# 5. Add the Gateway to your MCP client
{
  "mcpServers": {
    "facio-dev": {
      "command": "docker",
      "args": ["mcp", "gateway", "run", "--profile", "facio-dev"]
    }
  }
}

Facio's audit trail captures every Gateway-routed tool call with the server, the tool, the parameters, the result, and the timing. For a regulated team (SOC2, ISO 27001, HIPAA), this is the complete MCP-execution record: "Agent called github.create_pull_request at 14:32 UTC, server github container started, tool executed, PR #1234 created, server container stopped."

For HITL workflows, the Gateway's per-tool RBAC is the natural enforcement layer:

Tool Category	Severity	Suggested Gate
*_list_*, *_get_*, *_search_*	Read	None — autonomous
*_create_* (new resource)	Write, contextual	Soft confirm
*_update_* (existing resource)	Write, contextual	Soft confirm
*_delete_*, *_archive_*	Write, destructive	Hard confirm + reason required
*_merge_*, *_deploy_*, *_cancel_*	Write, destructive	Hard confirm + reason required
mcp-add (install new server)	Write, structural	Hard confirm (changes the tool surface)

The mcp-add tool deserves special attention — installing a new MCP server changes the agent's tool surface, which is a structural change to the agent's capabilities. Facio should require hard confirmation with the operator reviewing the server's identity, verification status, and scope before the install proceeds.

For multi-environment setups (one profile per environment), the pattern is one profile per environment with its own secrets and its own audit trail:

# Production profile (read-only by default, specific write exceptions)
docker mcp profile create prod-readonly --servers github,notion,sentry

# Staging profile (full read/write for staging tools)
docker mcp profile create staging-dev --servers github,notion,sentry,stripe-test,filesystem,postgres-staging

# Dev profile (everything, no production credentials)
docker mcp profile create dev --servers github,notion,linear,sentry,stripe-test,filesystem,postgres-dev

The agent switches context per environment. The audit trail is per-environment. The HITL gating is per-environment.

Quickstart

# 1. Install Docker Desktop 4.37+ (or Docker Engine + Compose V2)

# 2. Initialize the MCP Toolkit
docker mcp toolkit install

# 3. Browse the catalog
docker mcp catalog ls | head -30
docker mcp catalog show github

# 4. Create your first profile
docker mcp profile create my-first --servers filesystem,sequential-thinking

# 5. Run the gateway
docker mcp gateway run --profile my-first

# 6. Connect your MCP client to the gateway
# (Client config: command = "docker", args = ["mcp", "gateway", "run", "--profile", "my-first"])

Use Cases

Multi-tenant SaaS agent infrastructure: One Gateway instance per customer, each with their own profile, their own secrets, their own audit trail. The SaaS orchestrates the Gateway fleet, but each customer's data is isolated.

Regulated-team agent deployment: Custom catalog scoped to compliance-approved servers. The agent can only discover what the compliance team has vetted. RBAC enforces additional gates per server.

Multi-environment dev workflow: dev / staging / prod profiles. The agent switches context per environment. Production credentials are isolated to the prod profile. Dev credentials never touch prod.

Multi-agent orchestration: cagent with planner agent + executor agent + reviewer agent. Each agent has a different profile with different tool access. The orchestrator picks the right one for each task.

Team onboarding: New engineer joins the team. You install the team-wide MCP profile on their laptop. They get instant access to every server the team uses, with the team's default credentials pre-configured. No manual setup.

Server discovery for new use cases: "I need to integrate with Twilio for SMS. Find the Twilio MCP server in the catalog and add it to my profile." mcp-find → mcp-add → ready to use.

Disaster recovery: "Replicate our MCP profile to the backup region." Profile is YAML, secrets are in the secret store, the Gateway config is declarative. Recovery is docker mcp profile create ...; docker mcp profile secret set ....

Compliance audit: "Show me every MCP server the agent has used in the last 90 days, who installed each, and what tools were called." Gateway audit log → structured report.

Cost optimization: "List all running MCP server containers and their resource usage. Kill any that haven't been used in 7 days." Gateway introspection → cleanup.

The Dynamic MCP Pattern: A Template

The Dynamic MCP pattern (discover → add → execute) is the design lesson every "MCP at scale" architecture should copy. The agent shouldn't be limited to a static tool surface. It should be able to discover what it needs, install it with operator approval, and execute through it.

For vendors building MCP infrastructure:

• Expose discovery — let agents search your catalog
• Expose install — let agents add servers with policy gates
• Expose execute — provide a unified tool-call surface across all servers
• Enforce verification — sign every server image
• Isolate credentials — broker secrets at the gateway, not in the agent

The future of MCP is not "one agent, one server, one connection." It's "one agent, hundreds of servers, dynamic composition, governed by the gateway."

Bottom Line

The Docker MCP Toolkit + Catalog + Gateway + cagent is the reference infrastructure stack for the MCP ecosystem in 2026. 300+ curated servers, dynamic discovery and composition, container-isolated execution, signature verification, credential brokering, per-tool RBAC, multi-agent orchestration. Apache 2.0 / open source, maintained by Docker.

For any team running more than a handful of MCP servers — and especially for any team running MCP in a regulated, multi-tenant, or production environment — this is the missing layer. The Toolkit handles setup. The Catalog provides the registry. The Gateway provides the runtime, the credential broker, and the policy enforcement. cagent provides the multi-agent orchestration. Together, they turn MCP from "a list of servers I installed" into a governed, observable, scalable runtime.

For the broader MCP ecosystem, this is the design lesson every "MCP infrastructure" project should learn. The agent's tool surface shouldn't be static. The server execution shouldn't be unverified. The credentials shouldn't be exposed. The lifecycle shouldn't be manual. Docker's stack is what the rest of the ecosystem will converge toward.

docker mcp gateway run --profile your-profile and your agent has the entire MCP ecosystem, governed.

---

MCP Spotlight is a series covering servers and infrastructure that give AI agents real capabilities. Every entry is evaluated for design quality, ecosystem impact, and integration fit with Facio's HITL-first agent runtime.