fix: default Docker image to stdio transport (closes #33, #35)

[MatthewJamisonJS]

Problem

Dockerfile:28 hardcodes ENV TRANSPORT=http, forcing every container to start an HTTP server on port 8080. This breaks:

• Docker MCP Gateway (Docker image doesn't work with Docker MCP Gateway (TRANSPORT=http hardcoded) #35) — spawns containers over stdio, never sends HTTP, times out.
• Gemini CLI via Docker MCP catalog (Issue with gemini #33) — same root cause.

Fix

Remove the line. index.ts:40 already defaults to stdio when TRANSPORT is unset:

const TRANSPORT_TYPE = (process.env.TRANSPORT || 'stdio') as 'stdio' | 'http'

 RUN chmod +x dist/index.cjs

-# Set HTTP transport mode by default
-ENV TRANSPORT=http
-
 EXPOSE 8080
 ENTRYPOINT ["node", "dist/index.cjs"]

HTTP mode still available via -e TRANSPORT=http.

Validation

$ env -u TRANSPORT REF_API_KEY=test node dist/index.cjs
Ref MCP Server running on stdio

$ TRANSPORT=http PORT=8081 REF_API_KEY=test node dist/index.cjs
Ref MCP Server running on HTTP at http://localhost:8081/mcp

npm run check passes.

Smithery

smithery.yaml declares startCommand.type: http. Smithery's own migrate_stdio_to_http cookbook ships a Dockerfile that does not set TRANSPORT and still deploys successfully — so Smithery injects it (or routes HTTP) at the platform level, and the Dockerfile ENV is redundant for that path.

Happy to do a Smithery test deploy of this branch before merging if you'd prefer empirical confirmation over the cookbook precedent.

Backwards compatibility

• docker run -e TRANSPORT=http -p 8080:8080 … unchanged.
• Smithery deployment unchanged (platform sets the env).
• New default unblocks stdio clients (Docker MCP Gateway, Gemini CLI, Cursor stdio).

Closes #33
Closes #35

[MatthewJamisonJS]

Quick update — pushed a87623d adding an env: block to smithery.yaml.

Was poking around how other runtime: container projects handle this and ran into blockscout/mcp-server's smithery.yaml:

env:
  BLOCKSCOUT_MCP_TRANSPORT: "http"

Their inline note — "Use environment variables to configure the container at runtime" — plus the project-config schema showing env: as a top-level field, suggested the cleanest path was declaring TRANSPORT: "http" there instead of in the Dockerfile. That way Smithery still gets HTTP, and the image defaults to stdio for everyone else.

If a different shape would fit your setup better, totally happy to revise — just wanted to surface what I found.