MCP Spotlight: Docker MCP Server — The Container Operations Bridge With mcp:// Catalog Protocol, MCP Toolkit, and the Container-Default Reference for Agents

Server: Docker MCP Catalog by Docker Coverage: Docker Hub Catalog (300+ MCP servers) · Runtime execution via MCP Toolkit · Container operations (docker CLI, docker compose) License: Apache 2.0 (Docker CLI), varies by catalog server (most MIT) Transport: stdio or HTTP via Docker MCP Gateway · Auth: Image signatures + catalog verification Docs: docs.docker.com/ai/mcp/ · hub.docker.com/mcp · mcp.docker.com

The MCP ecosystem in 2026 has hundreds of servers — but the distribution problem is real. The "install every MCP server from npm" approach trusts every package publisher, repeats the security verification per-server, and forces the user to manage processes for every server. The "host every MCP server yourself" approach duplicates the work every team would otherwise repeat. The "give the agent nothing" approach blocks every workflow that benefits from rich tool ecosystems.

The official Docker MCP infrastructure by Docker is the bridge that resolves this. Not a single server — a complete platform for MCP server discovery, verification, runtime isolation, and lifecycle management: the Docker Hub MCP Catalog at hub.docker.com/mcp (300+ curated MCP servers with provenance metadata), the MCP Toolkit for runtime execution via the Docker MCP Gateway, and signed image verification for supply-chain safety. Built directly on Docker's existing container ecosystem — the same runtime ships 50+ billion images per year.

This is the MCP-server-distribution and runtime default for AI agents in 2026. Same Docker primitives the platform is famous for, applied to MCP.

The Architecture: Three Layers

Docker's MCP infrastructure is built in three layers, each addressing a different problem:

Layer 1: Docker Hub MCP Catalog (hub.docker.com/mcp)

The catalog is a verified registry of MCP servers, curated by Docker and the open-source community. Each server listing includes:

• Image signature — cryptographically signed by the publisher
• Provenance metadata — built from this commit on this CI runner
• Tool summary — what tools the server exposes, what they do
• Required credentials — what API keys / tokens the server needs
• Documentation — how to configure, how to use

For example, the catalog entry for the GitHub MCP server includes:

name: github
publisher: github
signature: sha256:...
provenance: https://github.com/mcp/github/actions/runs/...
tools:
  - name: create_issue
    description: "Open a new GitHub issue"
    parameters: [...]
  - name: list_pull_requests
    description: "List PRs matching criteria"
    parameters: [...]
secrets:
  - env: GITHUB_TOKEN
    description: "GitHub Personal Access Token"
    required: true
docker_image: mcp/github:latest

The catalog is the answer to "which MCP server should I trust?". Every entry has provenance, signature, and clear documentation. The user browses, picks, installs — all with a single command.

Layer 2: Docker MCP Toolkit (Runtime Execution)

The toolkit is the runtime layer. It runs MCP servers as Docker containers, isolated by default, with:

• Filesystem isolation — each server's filesystem is its own container layer
• Network isolation — by default no network access; explicit --network opt-in per call
• Secret brokering — API keys injected at runtime from Docker's secret store, never visible to the agent
• Resource limits — CPU, memory, disk quotas per server
• Health checks — automatic restart on failure
• Multi-server orchestration — the toolkit runs all your MCP servers as one stack

For example:

# Install the MCP Toolkit
docker mcp toolkit install

# Browse the catalog
docker mcp catalog ls

# Install a server
docker mcp server install github

# Run a query
docker mcp run github create_issue --repo=centerbit/facio.bot \
                                    --title="..." --body="..."

Layer 3: Docker MCP Gateway (HTTP Transport)

The gateway is the HTTP/streamable-HTTP bridge for remote MCP clients. Agents connecting over HTTP (not stdio) hit the gateway, which dispatches to the right containerized server.

For SaaS products or multi-tenant deployments, the gateway is essential:

docker mcp gateway start
# Gateway listens on localhost:8080
# /mcp/github → github MCP container
# /mcp/stripe → stripe MCP container
# /mcp/filesystem → filesystem MCP container (sandboxed)

The gateway is the single ingress for all MCP traffic. Each request is authenticated, authorized, dispatched. The agent doesn't need to know which container hosts which server.

The Killer Combination: Verified Catalog + Isolated Runtime

The two highest-leverage pieces of the Docker MCP infrastructure:

Verified catalog (supply-chain trust)

The catalog verification chain:

1. Publisher identity — verified by Docker (GitHub org membership, domain ownership)
2. Image signature — signed with sigstore/cosign, verified at pull time
3. Provenance — in-toto attestation, build-from-commit, CI attestations
4. Catalog review — Docker's editorial review for quality and security
5. Continuous scanning — vulnerability scanning on every push

The agent (and the operator) gets defense-in-depth on every MCP server. A compromised publisher can't slip a trojaned image through; a compromised CI can't bypass the signature; a vulnerable base image gets flagged automatically.

Isolated runtime (blast-radius containment)

The toolkit's isolation:

┌───────────────────────────────────────────────┐
│ MCP Client (e.g., Claude Code, Cursor)        │
└────────────────────┬──────────────────────────┘
                     │ stdio or HTTP
                     ▼
┌───────────────────────────────────────────────┐
│ Docker MCP Gateway                            │
│  - Auth                                       │
│  - Authorization                              │
│  - Dispatch                                   │
└─────┬─────────┬─────────┬─────────┬───────────┘
      │         │         │         │
      ▼         ▼         ▼         ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ github  │ │ stripe  │ │ filesys │ │ sentry  │
│  MCP    │ │  MCP    │ │  MCP    │ │  MCP    │
│(isolate)│ │(isolate)│ │(isolate)│ │(isolate)│
└─────────┘ └─────────┘ └─────────┘ └─────────┘

Each MCP server runs in its own container with its own filesystem, its own network namespace, its own resource limits. The agent's blast radius is bounded per server — a compromised GitHub MCP can't read the Stripe credentials.

Combined with Facio's HITL approval gating and per-tool RBAC, the agent's surface is defense-in-depth: catalog verification + runtime isolation + RBAC + HITL + audit trail.

The Catalog at hub.docker.com/mcp

The Docker MCP Catalog at hub.docker.com/mcp has 300+ servers spanning the major platforms. Categories:

Developer Workflow

• GitHub — issues, PRs, code, actions
• GitLab — issues, MRs, CI
• Linear — issues, projects, cycles
• Jira — issues, projects
• Sentry — error tracking
• PagerDuty — incident response

Productivity

• Notion — pages, databases
• Confluence — pages, spaces
• Slack — messages, channels
• Microsoft 365 — Word, Excel, PowerPoint, Outlook

Infrastructure

• Cloudflare — workers, R2, D1, DNS
• AWS — broad coverage via search+execute
• Vercel — deployments, projects
• Render — services, databases

Payments

• Stripe — customers, subscriptions, refunds
• PayPal — payments, subscriptions
• Square — inventory, orders

Communication

• Resend — email, contacts, broadcasts
• Twilio — SMS, voice
• SendGrid — email

Storage

• AWS S3 — buckets, objects
• Cloudflare R2 — objects, buckets
• Google Drive — files, folders
• Dropbox — files, folders

Search

• Brave Search — independent web index
• Tavily — AI-optimized search
• Google Custom Search — Google's index

Utilities

• Filesystem — local file access (sandboxed)
• Fetch — read web pages (Markdown conversion)
• Memory — persistent knowledge graph
• Sequential-Thinking — structured reasoning
• Time — IANA timezone math

For each, the catalog includes verified provenance and clear setup instructions.

The mcp:// URL Protocol

Docker introduced the mcp:// URL protocol for declarative MCP server installation:

# Install a server via URL
docker mcp install mcp://github

# Install with config
docker mcp install mcp://github?token=${GITHUB_TOKEN}

# Run a query
docker mcp run mcp://github create_issue --repo=centerbit/facio.bot --title="..."

The mcp:// URL scheme standardizes how MCP servers are referenced — in documentation, in AI agent prompts, in CI/CD pipelines. An agent can say "install mcp://github" and the platform handles the rest.

This is the same pattern as https:// for HTTP, git:// for Git, docker:// (or docker run) for Docker images. mcp:// becomes the canonical URL scheme for MCP servers.

The docker mcp CLI

The Docker MCP CLI is the single command surface for everything MCP-related:

# Catalog operations
docker mcp catalog ls                    # List catalog
docker mcp catalog search "github"       # Search catalog
docker mcp catalog info github           # Detailed info

# Server operations
docker mcp server ls                     # Installed servers
docker mcp server install github         # Install from catalog
docker mcp server remove github          # Remove
docker mcp server update github         # Update to latest

# Run-time operations
docker mcp run github create_issue ...  # Run a tool directly
docker mcp logs github                   # View logs
docker mcp restart github                # Restart

# Toolkit operations
docker mcp toolkit install               # Install the toolkit
docker mcp toolkit upgrade               # Upgrade
docker mcp gateway start                 # Start the gateway

# Configuration
docker mcp config set github.token=...   # Set secrets per server
docker mcp config ls                     # Show config

The CLI is the operational interface. It's what the agent uses (via exec), it's what the operator uses, it's what CI/CD uses.

For Compose-style orchestration:

# docker-mcp.yml
servers:
  github:
    image: mcp/github:latest
    env:
      GITHUB_TOKEN: ${secrets.github_token}
  filesystem:
    image: mcp/filesystem:latest
    args: ["/projects", "/scratch"]
  sequential-thinking:
    image: mcp/sequentialthinking:latest

secrets:
  github_token:
    source: docker-secret

networks:
  default:
    driver: bridge

The entire MCP server fleet runs from one declarative file. docker mcp stack up and the entire team has its MCP infrastructure.

Facio Integration

# docker-mcp.yml — Facio's recommended pattern
servers:
  github:
    image: mcp/github:latest
    env:
      GITHUB_TOKEN: ${credentials.GITHUB_PERSONAL_ACCESS_TOKEN}
    cap_add: []          # no capabilities
    read_only: true       # filesystem read-only
    pids_limit: 100
    mem_limit: 512m
    cpus: 0.5

  stripe:
    image: mcp/stripe:latest
    env:
      STRIPE_SECRET_KEY: ${credentials.STRIPE_RESTRICTED_KEY}
    cap_drop: ["ALL"]
    networks: [private-net]

  filesystem:
    image: mcp/filesystem:latest
    args: ["/projects"]
    volumes: ["./projects:/projects:rw"]
    read_only: false     # only this one can write
    cap_drop: ["ALL"]

Facio's audit trail captures every MCP call routed through the gateway, with the originating server, the tool, the parameters, and the result. The gateway is the single chokepoint where audit can be enforced.

For HITL workflows, the toolkit's isolation + Facio's gating is defense-in-depth:

Layer	Enforcement
Catalog verification (Layer 1)	Publisher identity, image signature, provenance
Runtime isolation (Layer 2)	Container boundaries, no host access
Secret brokering (Layer 2)	Secrets injected at runtime, never in agent context
Per-tool RBAC (Facio)	Destructive-hint annotations on the tool surface
HITL approval (Facio)	Human-in-the-loop for consequential operations
Audit trail (Facio)	Tamper-evident log of every call

For multi-agent setups (planner + executor + reviewer), each agent runs in its own MCP context with its own toolkit instance, its own audit trail, its own credential set.

For multi-tenant SaaS setups (one MCP fleet per customer), each tenant has its own docker-mcp.yml with its own credential scoping. Tenant isolation at the runtime level.

Quickstart

# 1. Install the Docker MCP Toolkit
docker mcp toolkit install

# 2. Browse the catalog
docker mcp catalog ls

# 3. Install a server
docker mcp server install github

# 4. Configure credentials (secrets are stored securely)
docker mcp config set github.token=ghp_...

# 5. Verify it works
docker mcp run github list_issues --repo=facebook/react --limit=5

# 6. For your AI agent, point it at the gateway:
docker mcp gateway start
# Agent connects to localhost:8080 via stdio or HTTP

Use Cases

Team-wide MCP provisioning: "Set up the team's MCP fleet: GitHub, Linear, Stripe, Filesystem, Sentry. Configure with our shared credentials." docker-mcp.yml → docker mcp stack up.

Multi-tenant SaaS isolation: "Per-tenant MCP server provisioning — each customer gets their own credential-scoped instances." Per-tenant docker-mcp.yml + per-tenant credentials.

CI/CD MCP testing: "Run our MCP test suite in CI using the catalog." docker mcp catalog ls in CI → automated MCP integration tests.

Server lifecycle management: "Update all installed MCP servers to latest versions, restart with zero downtime." docker mcp server update * + rolling restart.

Catalog browsing / discovery: "Show me MCP servers for X use case." docker mcp catalog search.

Custom MCP server distribution: "Publish our internal finance-data MCP server to the catalog for other teams to use." Docker build + push + catalog review.

Resource quota enforcement: "Set up per-server CPU/memory limits so a runaway agent can't DoS the host." container resource limits.

Audit-trail-ready access: "All MCP traffic should be audit-logged centrally." gateway-level audit logging.

Server health monitoring: "Show me the health and resource usage of all running MCP servers." docker mcp stats + health endpoints.

Cross-platform MCP portability: "My MCP stack definition should work on Mac, Linux, and Windows developer machines." docker-mcp.yml portable via Docker.

Security hardening: "Drop all Linux capabilities from MCP server containers by default. Only GitHub needs network access." cap_drop: ["ALL"] + per-server network policies.

Secret rotation: "Rotate the GitHub token for our MCP server without downtime." New secret pushed → toolkit reloads → rolling restart.

Version pinning: "Pin our MCP servers to specific versions for production stability." image tags with SHA digests.

Dev/staging/prod parity: "Same MCP stack runs in dev, staging, prod with different credentials." Same docker-mcp.yml, different config layers.

Local development: "Developers can run the same MCP stack locally with personal credentials." Docker Compose profile.

Disaster recovery: "Restore the team's MCP server configuration from version control." git-tracked docker-mcp.yml.

Custom registry support: "Host our internal MCP catalog for company-only servers." Self-hosted MCP registry.

Audit export: "Export the MCP call log for SOC2 compliance." Gateway → logs → SOC2-ready export.

Compliance evidence: "Prove that every MCP server is signed, scanned, and isolated." Catalog metadata + container isolation evidence.

Migration to MCP: "Migrate our custom tool integrations to standardized MCP servers from the catalog." Catalog → install → migrate agent integrations.

The Platform-Approach-to-MCP Pattern

The Docker MCP infrastructure's defining innovation — treating MCP servers as container images with all the platform primitives — is the design lesson the entire MCP ecosystem should learn.

Why platform-approach wins:

• Distribution — same docker pull the world knows
• Verification — image signatures, provenance, scanning (already solved for containers)
• Isolation — same container isolation that ship billions of containers per year
• Lifecycle — start, stop, update, restart (already solved for containers)
• Resource limits — same CPU / memory / disk controls as for any container
• Compose — declarative multi-server orchestration (docker-compose style)
• Logging — centralized logs per server (same as any container)
• Monitoring — health, stats, traces (same as any container)
• Secrets — Docker's secret brokering works for MCP credentials
• Multi-platform — runs identically on Linux, macOS, Windows

Docker didn't reinvent MCP. Docker applied its existing platform to MCP. The result is the most mature MCP infrastructure available in 2026.

For the broader MCP ecosystem, the Docker approach is the production-readiness roadmap:

1. Distribute via Docker Hub (or compatible registry)
2. Sign images + provide provenance
3. Run isolated by default
4. Broker secrets at runtime
5. Orchestrate via Compose-style files
6. Centralize logging + monitoring
7. Provide a catalog with editorial review

These are the primitives containers shipped decades ago. Applying them to MCP makes the entire ecosystem enterprise-ready.

Bottom Line

The Docker MCP infrastructure is the MCP-server-distribution, runtime, and lifecycle default for AI agents in 2026. The Docker Hub MCP Catalog (300+ verified servers), the MCP Toolkit (isolated runtime execution), and the MCP Gateway (HTTP dispatch) form the complete platform the MCP ecosystem needed.

For any team deploying MCP in production — solo developers, growing startups, regulated enterprises — the Docker MCP infrastructure provides the same primitives that ship billions of containers per year. Verified images, isolated runtimes, brokered secrets, declarative composition, centralized logging.

For the broader MCP ecosystem, Docker's approach is the design lesson every MCP server should follow. Distribute via container registries. Sign and provenance every image. Run isolated. Orchestrate declaratively. When MCP inherits the container ecosystem's primitives, MCP becomes enterprise-ready by default.

Install the toolkit (docker mcp toolkit install), browse the catalog (docker mcp catalog ls), pick your servers, and your agent has the world's MCP ecosystem — verified, isolated, orchestrated.

---

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