Summary
The Docker container ignores the `MCP_MODE=stdio` environment variable and always runs in HTTP mode.
Problem
When running the container with `MCP_MODE=stdio`, the server still starts in HTTP mode:
docker run -e WEBEX_ACCESS_TOKEN=xxx -e MCP_MODE=stdio webex-mcp-server
# Still starts HTTP server on port 3000
Root Cause
In the Dockerfile (line 28), TRANSPORT=http is hard-coded:
ENV TRANSPORT=http
However, in mcpServer.js (line 146), the transport mode priority is:
const transportMode = (process.env.TRANSPORT || process.env.MCP_MODE || process.env.MODE || 'stdio').toLowerCase();
Since TRANSPORT takes highest priority, the hard-coded value always wins over MCP_MODE.
Solution
Remove the hard-coded ENV TRANSPORT=http from the Dockerfile. This allows users to control the transport mode at runtime via MCP_MODE or TRANSPORT environment variables, while defaulting to STDIO mode when neither is set.
Before (lines 25-28):
# Set environment variables
ENV NODE_ENV=production
# Set transport mode to HTTP for Smithery deployment
ENV TRANSPORT=http
After:
# Set environment variables
ENV NODE_ENV=production
# Transport mode controlled at runtime via MCP_MODE or TRANSPORT env var
# Defaults to STDIO if not set; use MCP_MODE=http for HTTP mode
Testing
After the fix:
# STDIO mode (default)
docker run -i -e WEBEX_ACCESS_TOKEN=xxx webex-mcp-server
# → Starts in STDIO mode
# HTTP mode (explicit)
docker run -e WEBEX_ACCESS_TOKEN=xxx -e MCP_MODE=http -p 3000:3000 webex-mcp-server
# → Starts HTTP server on port 3000
Impact
- Breaking change: No. Users who need HTTP mode can explicitly set MCP_MODE=http or TRANSPORT=http
- Default behavior change: Container now defaults to STDIO mode (aligns with MCP standard client usage like Claude Desktop)
---
