Bypass the default allowlist and force your custom MCP server to run in Docker with these three field-tested configuration hacks that bridge the gap between your local dev environment and rigid client tools.

Taming the Ghost: Adding Custom MCP Configurations to Docker

I remember the first time I hit this wall. I was trying to hook up a custom Postgres context server for legacy-billing-db-02 to our internal AI agent. I had the Docker image built, the tags were perfect, and the container spun up beautifully in the terminal. But the client application? It acted like my container didn’t exist. It just stared blankly at the configuration dropdown, offering me the same three “verified” options I didn’t need.

There is nothing quite as frustrating as a tool trying to protect you from yourself when you actually know what you’re doing. If you are reading this, you probably have an MCP (Model Context Protocol) image that isn’t on the “approved” list, and you need it running yesterday. Let’s fix that.

The “Why”: It’s About Communication, Not Just Containers

Here is the root of the headache. Most MCP clients (like Claude Desktop or Cursor) expect to talk to a local binary via stdio (Standard Input/Output). They aren’t inherently designed to know that your binary is actually a Docker container living in an isolated namespace.

When an MCP is “unsupported,” it usually just means the client doesn’t have a pre-baked recipe to construct the docker run command for you. It doesn’t know which ports to map or that it needs to attach to the container’s standard input to send JSON-RPC messages. We have to manually build that bridge.

The Fixes

Here are the three ways I handle this at TechResolve, ranging from the quick config edit to the heavy artillery.

Solution 1: The Config Injection (The Quick Fix)

This is the method I use 90% of the time. Most MCP clients rely on a JSON configuration file (often located at ~/Library/Application Support/Claude/claude_desktop_config.json or similar). Instead of pointing the config to a local binary, we point it to the Docker executable and pass the container parameters as arguments.

The trick is the -i flag. You must run it interactively so the MCP protocol can pass messages over the pipe.

{
  "mcpServers": {
    "my-custom-mcp": {
      "command": "docker",
      "args": [
        "run",
        "-i", 
        "--rm",
        "--env-file", ".env.local",
        "my-org/custom-mcp-image:latest"
      ]
    }
  }
}

Pro Tip: Always use --rm. Since these clients spawn a new process every time they connect, you don’t want to wake up to find 500 stopped containers explicitly named mcp-zombie-499 cluttering up your disk space.

Solution 2: The Shell Wrapper (The “It Just Works” Fix)

sometimes the JSON parser in these tools gets finicky about arguments, especially if you have complex volume mounts or network flags for things like dev-redis-01. In those cases, I stop fighting the JSON syntax and write a simple shell script wrapper. This makes the MCP client think it’s just calling a local binary.

Create a file named run-mcp.sh and make it executable:

#!/bin/bash

# Darian's Wrapper for Legacy MCP
# Usage: point your MCP config 'command' to this file path

# Ensure we have the latest logic
docker pull my-org/custom-mcp-image:latest > /dev/null 2>&1

# Run it. Note we aren't using -t (tty), just -i (interactive)
# TTY can mess up the JSON-RPC signals.
exec docker run \
  -i \
  --rm \
  --network host \
  -v $(pwd)/data:/app/data \
  my-org/custom-mcp-image:latest "$@"

Then, simply point your config command to /path/to/run-mcp.sh with no arguments. It’s cleaner and easier to debug permissions here than inside a massive JSON string.

Solution 3: The ‘Nuclear’ Option (Stdio Proxy)

If you are dealing with a complex container stack (maybe your MCP needs to talk to other containers in a specific Docker Compose network), the direct docker run command might fail because of networking isolation. The client running on your host machine can’t reach the services inside the bridge network easily.

In this scenario, I use a “Nuclear” approach: I run the container in the background permanently via Docker Compose, and use docker exec to proxy the connection. This is hacky, but it saves the day when networking gets weird.

{
  "mcpServers": {
    "persistent-mcp": {
      "command": "docker",
      "args": [
        "exec",
        "-i",
        "mcp-persistent",
        "node", 
        "build/index.js" 
      ]
    }
  }
}

This bypasses the container startup latency entirely. The container is already running on prod-network-bridge, and you are just tunneling the stdio into it. It’s incredibly fast, though it requires you to manage the container lifecycle manually.

Pick the one that fits your architecture. For most of you, Solution 1 is the golden ticket. Just remember: if you forget the -i flag, the lights are on but nobody is home.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions