docker mcp gateway always starts in stdio mode

[jbrinnand]

The docker mcp gateway appears to ignore any other transport besides stdio. The server I am running uses sse. The gateway appears to disregard all configuration parameters and always starts up with -l docker-mcp-transport=stdio.

As a result the 'initialize' method fails with: 'Can't start account-mcp: failed to connect: calling "initialize": invalid character '.' looking for beginning of value'. Basically, the gateway appears not to be able to run in any other transport mode except stdio. Is this by design?

Following the instructions for building a catalog, the following steps were followed:

1. Build a custom config ./custom-config-v-0.0.7.yaml
   `registry:
   account-mcp:
   description: "Springboot MCP Server that accesses MariaDB."
   title: "Springboot MariaDB MCP Server"
   type: "server"
   image:
   tools:

   • name: getAllAccounts
     description: "Retrieve all accounts from the database."
     command: "getAllAccounts"
   • name: getAccountById
     description: "Retrieve an account by its ID."
     command: "getAccountById"
   • name: getAccountByName
     description: "Retrieve an account by its name."
     command: "getAccountByName"
   • name: searchAccountsByPartialName
     description: "Search accounts by partial name."
     command: "searchAccountsByPartialName"
     command:
     - "-p"
     - "8080:80"`

2. Create a custom catalog:
   docker mcp catalog create my-custom-catalog

3. Add the custom catalog to the catalog
   docker mcp catalog add my-custom-catalog account-mcp ./custom-catalog-v-0.0.7.yaml --force

4. Enable the catalog
   docker mcp server enable account-mcp

5. Run it.
   docker mcp gateway run --catalog my-custom-catalog --verbose --debug-dns

• Reading configuration...
  • Reading registry from registry.yaml
  • Reading catalog from [my-custom-catalog.yaml]
  • Reading config from config.yaml
  • Reading tools from tools.yaml
• Configuration read in 909.167µs
  MCP server not found: dockerhub
  MCP server not found: duckduckgo
• Using images:
  • my-custom-image
    Images pulled in 1.815717833s
• Those servers are enabled: account-mcp, dockerhub, duckduckgo
• Listing MCP tools...
  • MCP server not found: dockerhub
  • MCP server not found: duckduckgo
  • Running with [run --rm -i --init --security-opt no-new-privileges --cpus 1 --memory 2Gb --pull never -l docker-mcp=true -l docker-mcp-tool-type=mcp -l docker-mcp-name=account-mcp -l docker-mcp-transport=stdio] and command [-p 8080:80]

  Can't start account-mcp: failed to connect: calling "initialize": invalid character '.' looking for beginning of value

0 tools listed in 7.45121075s

• Starting OAuth notification monitor
• Starting OAuth provider loops...
• Watching for configuration updates...

Initialized in 9.269585542s
Start stdio server

• Connecting to OAuth notification stream at http://localhost/notify/notifications/channel/external-oaut

However, this command works as expected and an npx:inspector can successfully connect to the server and run the tools:

docker run --rm -i -p 8080:80 my-custom-image --init --security-opt no-new-privileges --cpus 1 --memory 2Gb --pull never -l docker-mcp=true -l docker-mcp-tool-type=mcp -l docker-mcp-name=account-mcp -l docker-mcp-transport=sse --transport=sse --endpoint=/sse

Of course my-custom-image obscures the server image.

[slimslenderslacks]

@jbrinnand You're right, we'll need to give you a way to specify non-stdio transports in your custom catalog. We have this issue from a while back.

#6

I have heard a few authors asking about local containers needing support for streamable so this is potentially becoming a more popular pattern.

[jbrinnand]

@slimslenderslacks Thanks for the validation. It is very helpful. Since streamable HTTP is the new MCP "standard for a remote transport mechanism", configurable custom catalogs with parameters for sse or streamable should become a more popular pattern. It makes the framework more adaptive to change. It has my vote.