How to add the Docker MCP server to Codex

Adding the Docker MCP server gives Codex a single local gateway to Docker-managed MCP tools and catalog servers, so prompts can use containerized integrations without installing each MCP server runtime directly on the host.

Docker Desktop's MCP Toolkit exposes that integration as a local stdio launcher named MCP_DOCKER. The current connect flow writes an entry to ~/.codex/config.toml that runs docker mcp gateway run, and the same saved launcher can then be reviewed with codex mcp get or codex mcp list before a session starts using Docker-backed tools.

The workflow below assumes the docker mcp command is already available from Docker Desktop or a separately installed docker-mcp plugin. Connecting Codex changes the shared user-level configuration, so any already-open Codex session should be restarted afterward. If Docker Toolkit has no enabled catalog servers yet, the gateway still connects, but prompts only see Docker's own management tools until servers are added in Docker.

Steps to add the Docker MCP server to Codex:

  1. Connect Codex to Docker's MCP Toolkit with Docker's client connector.
    $ docker mcp client connect --global codex
    === System-wide MCP Configurations ===
    ##### snipped #####
    codex: connected
      MCP_DOCKER: Docker MCP Catalog (gateway server) (stdio)
    ##### snipped #####
    You might have to restart 'codex'.
    Tip: Your client is now connected! Use docker mcp tools ls to see your available tools

    Omitting --global currently fails with codex only supports global configuration. Re-run with --global or -g, and the saved entry goes into the shared ~/.codex/config.toml file for the current account.

  2. Retrieve the saved MCP_DOCKER entry in JSON to confirm that Codex stored a local stdio gateway launcher.
    $ codex mcp get MCP_DOCKER --json
    {
      "name": "MCP_DOCKER",
      "enabled": true,
      "disabled_reason": null,
      "transport": {
        "type": "stdio",
        "command": "docker",
        "args": [
          "mcp",
          "gateway",
          "run"
        ],
        "env": null,
        "env_vars": [],
        "cwd": null
      },
      "enabled_tools": null,
      "disabled_tools": null,
      "startup_timeout_sec": null,
      "tool_timeout_sec": null
    }

    The decisive fields are transport.type = stdio, transport.command = docker, and transport.args = ["mcp","gateway","run"]. Current Docker docs also describe profile-aware gateway runs; when a non-default Docker profile is required, the equivalent manual Codex entry is codex mcp add MCP_DOCKER -- docker mcp gateway run --profile web-dev.

  3. List the configured MCP servers and confirm that the MCP_DOCKER row is enabled.
    $ codex mcp list
    Name        Command  Args             Env  Cwd  Status   Auth
    MCP_DOCKER  docker   mcp gateway run  -    -    enabled  Unsupported

    Unsupported under Auth is expected because this is a local stdio server, not a remote HTTP endpoint with bearer-token or OAuth login.

  4. List Docker MCP tools to confirm that the gateway is returning tools to connected clients.
    $ docker mcp tools ls
    6 tools:
     - code-mode - Create a JavaScript-enabled tool that combines multiple MCP server tools.
     - mcp-add - Add a new MCP server to the session.
     - mcp-config-set - Set configuration for an MCP server.
     - mcp-exec - Execute a tool that exists in the current session.
     - mcp-find - Find MCP servers in the current catalog by name, title, or description.
     - mcp-remove - Remove an MCP server from the registry and reload the configuration.

    The verified default gateway returned six Docker management tools on this host. Additional enabled catalog servers increase that list, and prompts can use those server-specific tools only after the servers are added or enabled in Docker.

  5. Restart any already-open Codex session before the first Docker-backed prompt.
    $ codex

    A practical first prompt is Use Docker MCP to find the official GitHub server in the Docker catalog and summarize what it can do. The Docker gateway starts on demand the first time a prompt needs one of its tools.