feat: make stdio transport default for Docker MCP Gateway compatibility #541
Conversation
Reviewer's GuideSwitches the Docker image’s default transport from HTTP to stdio for Docker MCP Gateway compatibility and adds Docker MCP Registry metadata plus example configuration for Antigravity/Unity MCP usage. Sequence diagram for stdio default transport with Docker MCP GatewaysequenceDiagram
actor Dev as Developer
participant Gateway as Docker_MCP_Gateway
participant Registry as Docker_MCP_Registry
participant Docker as Docker_Engine
participant Container as unity-mcp_Container
participant Server as Unity_MCP_Server_stdio_default
Dev->>Gateway: Browse_catalog_and_select_unity-mcp
Gateway->>Registry: Get_server_metadata
Registry-->>Gateway: Return_server_yaml_for_unity-mcp
Gateway->>Docker: docker_run mcp/unity-mcp (default_CMD)
Docker-->>Gateway: Container_started
Docker->>Container: Start_process "uv run mcp-for-unity"
Container->>Server: Launch_Unity_MCP_Server_with_stdio_transport
Gateway-->>Server: Attach_stdio_streams
Gateway->>Server: MCP_initialize
Server-->>Gateway: MCP_initialize_result
Dev->>Gateway: Send_tool_request
Gateway->>Server: MCP_request_over_stdio
Server-->>Gateway: MCP_response_over_stdio
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
📝 WalkthroughWalkthroughUpdates the Docker entrypoint to run Changes
Sequence Diagram(s)(omitted — changes are configuration, manifest, and a simple entrypoint swap; not a multi-component control-flow change) Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Since the Docker image now defaults to stdio and doesn’t actually listen on port 8080, consider either removing
EXPOSE 8080or adding a brief comment clarifying that it’s only needed when users opt into HTTP transport. - In
docker/mcp-registry/server.yaml, thedisable_telemetryandlog_levelparameters are typed as generic strings even though they behave like a boolean and an enum; tightening these types (e.g.,type: booleanandenumfor log level) would make the config more self-documenting and reduce misconfiguration.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Since the Docker image now defaults to stdio and doesn’t actually listen on port 8080, consider either removing `EXPOSE 8080` or adding a brief comment clarifying that it’s only needed when users opt into HTTP transport.
- In `docker/mcp-registry/server.yaml`, the `disable_telemetry` and `log_level` parameters are typed as generic strings even though they behave like a boolean and an enum; tightening these types (e.g., `type: boolean` and `enum` for log level) would make the config more self-documenting and reduce misconfiguration.
## Individual Comments
### Comment 1
<location> `docker/mcp-registry/server.yaml:39-44` </location>
<code_context>
+ parameters:
+ type: object
+ properties:
+ disable_telemetry:
+ type: string
+ description: Disable anonymous telemetry (true/false)
+ log_level:
+ type: string
+ description: Logging level (DEBUG, INFO, WARNING, ERROR)
</code_context>
<issue_to_address>
**suggestion:** Consider using more specific types/enums for config parameters instead of free-form strings.
`disable_telemetry` and `log_level` are declared as plain strings but only accept specific values. If supported by the MCP registry schema, consider:
- `disable_telemetry`: `type: boolean` instead of a "true/false" string.
- `log_level`: `type: string` with an explicit `enum: [DEBUG, INFO, WARNING, ERROR]`.
This tightens validation and makes valid values clearer to clients.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| disable_telemetry: | ||
| type: string | ||
| description: Disable anonymous telemetry (true/false) | ||
| log_level: | ||
| type: string | ||
| description: Logging level (DEBUG, INFO, WARNING, ERROR) |
There was a problem hiding this comment.
suggestion: Consider using more specific types/enums for config parameters instead of free-form strings.
disable_telemetry and log_level are declared as plain strings but only accept specific values. If supported by the MCP registry schema, consider:
disable_telemetry:type: booleaninstead of a "true/false" string.log_level:type: stringwith an explicitenum: [DEBUG, INFO, WARNING, ERROR].
This tightens validation and makes valid values clearer to clients.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In @docker/antigravity-mcp-config.example.json:
- Around line 1-13: The JSON uses the wrong top-level key and invalid Docker
args: replace the "servers" root key with "mcpServers" and update the
"dockerMcp" entry (command "docker", args array) to use a proper docker run
invocation (e.g., start with "run", include options like "--rm", "-p", the image
name such as "ghcr.io/docker/mcp-gateway:latest", and any container flags like
"--port" and "--transport") or, if you intend to call a separate CLI binary,
change the "command" from "docker" to that executable; ensure the "dockerMcp"
object retains "type": "stdio".
In @docker/mcp-registry/server.yaml:
- Around line 24-26: The YAML currently pins source.commit (symbol:
source.commit) which is optional — either enable/verify an automated update
workflow that refreshes that commit pin for project (symbol: source.project or
the repo URL) and document the automation, or remove the source.commit field
entirely so the registry tracks the repo HEAD; update the manifest by deleting
the commit entry if you don't have automation, or keep it but wire/confirm the
automation that updates it.
- Around line 1-3: Update the Kubernetes manifest entry that currently sets
image: mcp/unity-mcp to the actual published image image:
msanatan/mcp-for-unity-server so the registry can pull it; locate the YAML key
"image: mcp/unity-mcp" in the manifest and replace the value accordingly, and
optionally pin to a content-addressable digest (sha256:...) for immutability if
you have the digest from the release workflow.
In @Server/Dockerfile:
- Line 33: Update the Dockerfile CMD that invokes the mcp-for-unity binary so it
explicitly passes the stdio transport flag; replace the current CMD ["uv",
"run", "mcp-for-unity"] invocation with one that includes "--transport", "stdio"
so the container uses stdin/stdout instead of defaulting to HTTP (ensure the CMD
array passed to the container includes the two additional arguments).
🧹 Nitpick comments (2)
Server/Dockerfile (1)
27-33: Potential confusion:EXPOSE 8080remains while default is stdio—clarify that 8080 is HTTP-only.
This is likely fine, but users may assume the container listens on 8080 by default when it won’t in stdio mode. Consider adjusting the comments to explicitly say “8080 is only used when--transport httpis set” (or dropEXPOSEif you don’t want to advertise it).Possible comment tweak
-# Default: stdio transport (Docker MCP Gateway compatible) -# For HTTP: docker run -p 8080:8080 <image> --transport http --http-host 0.0.0.0 --http-port 8080 +# Default: stdio transport (Docker MCP Gateway compatible). No ports are listened to in this mode. +# For HTTP (uses port 8080): docker run -p 8080:8080 <image> --transport http --http-host 0.0.0.0 --http-port 8080 CMD ["uv", "run", "mcp-for-unity"]docker/mcp-registry/server.yaml (1)
27-44: Use JSON Schema boolean type and enum constraint for better validation and UI generation.
Thedisable_telemetryparameter should betype: boolean(not string), andlog_levelshould includeenum: ["DEBUG", "INFO", "WARNING", "ERROR"]to constrain allowed values. MCP registry schemas support standard JSON Schema, enabling proper type validation and client UI improvements.Suggested changes
parameters: type: object properties: disable_telemetry: - type: string - description: Disable anonymous telemetry (true/false) + type: boolean + description: Disable anonymous telemetry log_level: type: string description: Logging level (DEBUG, INFO, WARNING, ERROR) + enum: ["DEBUG", "INFO", "WARNING", "ERROR"]
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
Server/Dockerfiledocker/antigravity-mcp-config.example.jsondocker/mcp-registry/server.yaml
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 468
File: Server/DOCKER_OVERVIEW.md:22-22
Timestamp: 2025-12-19T21:09:44.740Z
Learning: In the Unity MCP project, the Docker workflow (.github/workflows/publish-docker.yml) intentionally uses the DOCKER_USERNAME secret instead of hardcoding "msanatan" to allow users who fork the repository to publish to their own Docker Hub repositories, while the documentation (Server/DOCKER_OVERVIEW.md) correctly references the official image location "msanatan/mcp-for-unity-server" for end users.
📚 Learning: 2025-12-19T21:09:44.740Z
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 468
File: Server/DOCKER_OVERVIEW.md:22-22
Timestamp: 2025-12-19T21:09:44.740Z
Learning: In the Unity MCP project, the Docker workflow (.github/workflows/publish-docker.yml) intentionally uses the DOCKER_USERNAME secret instead of hardcoding "msanatan" to allow users who fork the repository to publish to their own Docker Hub repositories, while the documentation (Server/DOCKER_OVERVIEW.md) correctly references the official image location "msanatan/mcp-for-unity-server" for end users.
Applied to files:
docker/mcp-registry/server.yamldocker/antigravity-mcp-config.example.jsonServer/Dockerfile
📚 Learning: 2025-11-05T18:23:12.349Z
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 368
File: MCPForUnity/UnityMcpServer~/src/resources/menu_items.py:15-15
Timestamp: 2025-11-05T18:23:12.349Z
Learning: In Unity MCP, the `name` parameter in the `mcp_for_unity_resource` decorator is the external API name exposed to MCP clients (LLMs, AI agents). The command string passed to `async_send_command_with_retry` or `async_send_with_unity_instance` (e.g., "get_menu_items") is the internal command identifier that must match the C# side. These are decoupled, allowing external API naming to evolve independently of internal command routing.
Applied to files:
docker/mcp-registry/server.yaml
📚 Learning: 2025-10-03T22:11:46.002Z
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 301
File: docs/CUSTOM_TOOLS.md:54-62
Timestamp: 2025-10-03T22:11:46.002Z
Learning: In Unity MCP, the `description` parameter in the `mcp_for_unity_tool` decorator is technically optional but should always be included as a best practice. Without it, there's a higher chance that MCP clients will not parse the tool correctly. All Unity MCP tools should include the description in the decorator for compatibility.
Applied to files:
docker/mcp-registry/server.yaml
📚 Learning: 2025-10-13T13:41:00.086Z
Learnt from: JohanHoltby
Repo: CoplayDev/unity-mcp PR: 309
File: MCPForUnity/Editor/Helpers/ServerInstaller.cs:478-508
Timestamp: 2025-10-13T13:41:00.086Z
Learning: In the MCPForUnityTools feature (MCPForUnity/Editor/Helpers/ServerInstaller.cs), the design intentionally forces users to have only one .py file per MCPForUnityTools folder to keep file tracking simple. Package-style tools (subdirectories with __init__.py) are not supported.
Applied to files:
docker/mcp-registry/server.yaml
📚 Learning: 2025-11-27T21:09:35.011Z
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 401
File: MCPForUnity/Editor/Clients/Configurators/VSCodeConfigurator.cs:10-18
Timestamp: 2025-11-27T21:09:35.011Z
Learning: VS Code GitHub Copilot MCP configuration supports mcp.json files placed directly in the Code/User directory: %APPDATA%\Code\User\mcp.json on Windows, ~/Library/Application Support/Code/User/mcp.json on macOS, and ~/.config/Code/User/mcp.json on Linux. This is in addition to workspace-scoped .vscode/mcp.json files.
Applied to files:
docker/mcp-registry/server.yaml
📚 Learning: 2025-10-13T13:27:23.040Z
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 316
File: TestProjects/UnityMCPTests/Assets/Tests/EditMode/Resources.meta:1-8
Timestamp: 2025-10-13T13:27:23.040Z
Learning: UnityMcpBridge is a legacy project kept for backwards compatibility; MCPForUnity is the only active Unity plugin project. GUID collisions between UnityMcpBridge and MCPForUnity are acceptable.
Applied to files:
docker/mcp-registry/server.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Sourcery review
| { | ||
| "servers": { | ||
| "dockerMcp": { | ||
| "command": "docker", | ||
| "args": [ | ||
| "mcp", | ||
| "gateway", | ||
| "run" | ||
| ], | ||
| "type": "stdio" | ||
| } | ||
| } | ||
| } No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Antigravity MCP configuration JSON schema servers type stdio command args
💡 Result:
Antigravity (and related MCP clients) accept a JSON servers/mcpServers object where each server entry for a local stdio server is specified with a command string, an args array, and optional env. Example schema + minimal example:
Schema (fields)
- servers / mcpServers: object mapping server-name → server-config.
- server-config:
- type (optional in some clients; "stdio" for local stdio servers)
- command: string (executable)
- args: array of strings
- env: object (map of env var → value)
Example JSON:
{
"mcpServers": {
"local-server": {
"type": "stdio",
"command": "/path/to/mcp-server-binary",
"args": ["--port","0","--token","$MCP_TOKEN"],
"env": { "MCP_TOKEN": "replace-with-token" }
}
}
}
Sources: Antigravity MCP JSON examples and docs (shows mcpServers/servers with command/args/env). [1][2]
References:
[1] Antigravity MCP JSON/config examples.
[2] MCPHub (mcpServers / VS Code servers format; local (stdio) server example).
🌐 Web query:
Antigravity MCP Gateway Docker integration configuration
💡 Result:
Below is a concise guide to integrating Antigravity (MCP-enabled client) with a Docker-run MCP Gateway/servers, plus a minimal example configuration you can drop into Antigravity’s mcp_config.json.
Key points
- Antigravity accepts a local MCP server/gateway configured via mcp_config.json (commands/args/env). [1][2]
- Docker’s MCP Gateway (docker mcp) can run as the central proxy; clients connect to the Gateway rather than individual servers. You can also run individual MCP servers directly as Docker containers and point Antigravity at them. [2][3]
Example: run Docker MCP Gateway and enable a server
- Enable a server (example: duckduckgo) and run the gateway with SSE transport:
- docker mcp server enable duckduckgo
- docker mcp gateway run --port 8080 --transport sse
(These commands use the Docker MCP CLI described in Docker docs.) [2]
- Example mcp_config.json for Antigravity
Replace placeholders (TOKENs, image names) with your values. Put this JSON into Antigravity → Manage MCP Servers → View raw config.
{
"mcpServers": {
"local-mcp-gateway": {
"command": "docker",
"args": [
"run",
"--rm",
"-p",
"8080:8080",
"--name",
"mcp-gateway",
"ghcr.io/docker/mcp-gateway:latest",
"--port",
"8080",
"--transport",
"sse"
],
"env": {}
},
"duckduckgo-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--name",
"mcp-duckduckgo",
"ghcr.io/docker/mcp-server-duckduckgo:latest"
],
"env": {}
}
}
}
Notes and options
- Use docker mcp CLI (docker mcp server enable ) to install/manage servers instead of manually running containers when available; that integrates lifecycle with the Gateway. [2]
- If your Gateway runs separately (e.g., on a host or Docker Desktop), point Antigravity’s client entry to the Gateway address/port instead of starting the Gateway via mcp_config.json. Antigravity will connect to the Gateway’s exposed SSE/websocket endpoint. [1][2]
- For servers that require secrets, pass them via env in the mcp_config.json or use the docker mcp catalog/install workflows that support secure credential handling. [1][3]
- If building a Streamlit or custom client, enable SSE transport and maintain a persistent client session (common pattern shown in community examples). [4]
References
[1] Antigravity MCP server docs / MCPJungle examples (includes mcp_config.json format and Antigravity instructions).
[2] Docker docs — MCP Gateway usage and docker mcp CLI.
[3] Antigravity / MCP catalog Docker server examples (GitHub/Supabase/GitHub examples).
[4] Community example (background worker + SSE) for integrating clients with a running Gateway.
Would you like: (A) a ready-to-run docker-compose.yml for the Gateway + one server, or (B) a tailored mcp_config.json for a specific MCP server (e.g., Supabase, GitHub, DuckDuckGo)?
🏁 Script executed:
# Search the repository for Antigravity-related documentation or examples
find . -type f \( -name "*.md" -o -name "*.json" -o -name "README*" \) | head -20Repository: CoplayDev/unity-mcp
Length of output: 992
🏁 Script executed:
# Search for any references to Antigravity in the codebase
rg -i "antigravity" --type-list all -A 3 -B 3Repository: CoplayDev/unity-mcp
Length of output: 452
🏁 Script executed:
# Check if there are other config examples or schemas in the repo
fd -e json -e schema -e example | grep -i configRepository: CoplayDev/unity-mcp
Length of output: 131
🏁 Script executed:
cat -n docker/antigravity-mcp-config.example.jsonRepository: CoplayDev/unity-mcp
Length of output: 383
🏁 Script executed:
# Check if there are any docs in the docker directory
ls -la docker/Repository: CoplayDev/unity-mcp
Length of output: 320
🏁 Script executed:
# Search for any documentation about config format
rg -i "antigravity\|mcpServers\|mcp config" -A 5 -B 2Repository: CoplayDev/unity-mcp
Length of output: 45
Fix schema key and Docker command syntax — this config is invalid as written.
Root key must be "mcpServers", not "servers" per Antigravity's schema. Additionally, the args array ["mcp", "gateway", "run"] is not valid Docker syntax; docker does not accept mcp as a subcommand in that position.
Use the proper Docker image and arguments instead:
{
"mcpServers": {
"dockerMcp": {
"command": "docker",
"args": [
"run",
"--rm",
"-p",
"8080:8080",
"ghcr.io/docker/mcp-gateway:latest",
"--port",
"8080",
"--transport",
"sse"
],
"type": "stdio"
}
}
}Alternatively, if using Docker Desktop's docker mcp CLI tool, that is a separate executable and would require a different command value. Verify which approach is intended for this project.
🤖 Prompt for AI Agents
In @docker/antigravity-mcp-config.example.json around lines 1 - 13, The JSON
uses the wrong top-level key and invalid Docker args: replace the "servers" root
key with "mcpServers" and update the "dockerMcp" entry (command "docker", args
array) to use a proper docker run invocation (e.g., start with "run", include
options like "--rm", "-p", the image name such as
"ghcr.io/docker/mcp-gateway:latest", and any container flags like "--port" and
"--transport") or, if you intend to call a separate CLI binary, change the
"command" from "docker" to that executable; ensure the "dockerMcp" object
retains "type": "stdio".
| name: unity-mcp | ||
| image: mcp/unity-mcp | ||
| type: server |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the docker publish workflow mentioned in learnings
find . -name "*publish*docker*" -o -name "*docker*publish*" | head -20Repository: CoplayDev/unity-mcp
Length of output: 95
🏁 Script executed:
# Also look for the mcp-registry directory structure and any schema docs
find . -path "*/docker/mcp-registry*" -type f | head -20Repository: CoplayDev/unity-mcp
Length of output: 96
🏁 Script executed:
# Search for references to the image name in the codebase
rg "mcp/unity-mcp|msanatan.*mcp" --type yaml --type mdRepository: CoplayDev/unity-mcp
Length of output: 774
🏁 Script executed:
# Check if there's any docker build or publish configuration
find . -name "Dockerfile*" -o -name "docker-compose*" | head -20Repository: CoplayDev/unity-mcp
Length of output: 103
🏁 Script executed:
# Check the publish docker action to see what image name it actually pushes
cat -n ./.github/actions/publish-docker/action.ymlRepository: CoplayDev/unity-mcp
Length of output: 4819
🏁 Script executed:
# Check the Server Dockerfile for image configuration
head -50 ./Server/DockerfileRepository: CoplayDev/unity-mcp
Length of output: 884
🏁 Script executed:
# Look for any docker build or push commands in workflows
find ./.github/workflows -name "*.yml" -o -name "*.yaml" | xargs grep -l "docker" | head -5Repository: CoplayDev/unity-mcp
Length of output: 223
🏁 Script executed:
# Get the full content of the publish docker workflow action
cat -n ./.github/actions/publish-docker/action.ymlRepository: CoplayDev/unity-mcp
Length of output: 4819
🏁 Script executed:
# Find where the publish-docker action is called
rg "publish-docker" --type yaml -A 5 -B 2Repository: CoplayDev/unity-mcp
Length of output: 45
🏁 Script executed:
# Also check the release workflow specifically
cat -n ./.github/workflows/release.ymlRepository: CoplayDev/unity-mcp
Length of output: 6536
🏁 Script executed:
# Check what the entire server.yaml file contains
cat -n ./docker/mcp-registry/server.yamlRepository: CoplayDev/unity-mcp
Length of output: 1667
🏁 Script executed:
# Search for documentation about mcp-registry or Docker MCP format
find . -name "*mcp*registry*" -o -name "*registry*" | grep -i mcpRepository: CoplayDev/unity-mcp
Length of output: 84
🌐 Web query:
Docker MCP Registry manifest specification image field requirements
💡 Result:
Short answer — in Docker's MCP registry/catalog the top-level image field must be a Docker image reference (string). Recommended/expected rules:
- Required top-level string field named image. Use a valid Docker image reference (repository/name, with optional tag or digest). [1][2]
- Prefer a content-addressable reference (repository@sha256:) to pin the exact artifact. Docker examples and guidance use digest form such as mcp/duckduckgo@sha256:... . [2]
- For Docker-built MCP entries the image normally lives in the mcp/ namespace (mcp/), but self-hosted/pre-built images may point to other registries. [1][3]
- The image value must be a pullable image (i.e., registry + repo + tag or digest) so the MCP tooling/gateway can docker pull it. [2][3]
Sources: Docker MCP registry repo and docs (registry catalog/CONTRIBUTING), Docker blog/catalog examples. [1][2][3]
References
[1] docker/mcp-registry (GitHub) — catalog/registry guidance.
[2] Docker blog "Build a Custom MCP Catalog" (example using mcp/...@sha256).
[3] MCP catalog/configuration reference (image field described).
🏁 Script executed:
# Get the exact image name with any tag/digest used in actual publishing
git log --oneline -20 --grep="docker\|Docker" -- '.github/workflows/release.yml' 2>/dev/null || echo "No recent changes"Repository: CoplayDev/unity-mcp
Length of output: 142
🏁 Script executed:
# Check if there are any other references to the image name in config or docs
rg "mcp/unity-mcp|mcp-for-unity-server" --type md --type txt --type jsonRepository: CoplayDev/unity-mcp
Length of output: 721
Change image: mcp/unity-mcp to image: msanatan/mcp-for-unity-server.
The manifest references mcp/unity-mcp, but the repository actually publishes to msanatan/mcp-for-unity-server (as configured in .github/workflows/release.yml and documented in Server/DOCKER_OVERVIEW.md). The MCP registry will fail to pull a non-existent image. Update the manifest to point to the actual published image. Consider also pinning to a content-addressable digest for immutability.
🤖 Prompt for AI Agents
In @docker/mcp-registry/server.yaml around lines 1 - 3, Update the Kubernetes
manifest entry that currently sets image: mcp/unity-mcp to the actual published
image image: msanatan/mcp-for-unity-server so the registry can pull it; locate
the YAML key "image: mcp/unity-mcp" in the manifest and replace the value
accordingly, and optionally pin to a content-addressable digest (sha256:...) for
immutability if you have the digest from the release workflow.
| source: | ||
| project: https://github.com/CoplayDev/unity-mcp | ||
| commit: 4c9beaffdefadee03c07f00eb3e3b6c5294fc99d |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Docker MCP Registry manifest specification source commit field required
💡 Result:
Short answer: source.commit is optional (not required). The registry's Go type marks Commit as omitempty, and the registry uses it as a commit pin when present (there are automated workflows to keep pins updated). [1][2]
Sources:
- docker/mcp-registry Go types (Source.Commit is optional / has
omitempty). [1] - Article describing commit-pin usage and update workflow for Docker's MCP registry. [2]
source.commit is optional; confirm whether automated updates are in place or if it should be omitted.
The Docker MCP Registry supports commit pins via automated workflows to prevent staleness. If not using automation to update this pin, consider omitting the field entirely.
🤖 Prompt for AI Agents
In @docker/mcp-registry/server.yaml around lines 24 - 26, The YAML currently
pins source.commit (symbol: source.commit) which is optional — either
enable/verify an automated update workflow that refreshes that commit pin for
project (symbol: source.project or the repo URL) and document the automation, or
remove the source.commit field entirely so the registry tracks the repo HEAD;
update the manifest by deleting the commit entry if you don't have automation,
or keep it but wire/confirm the automation that updates it.
Server/Dockerfile
Outdated
| CMD ["uv", "run", "python", "src/main.py", "--transport", "http", "--http-host", "0.0.0.0", "--http-port", "8080"] | ||
| # Default: stdio transport (Docker MCP Gateway compatible) | ||
| # For HTTP: docker run -p 8080:8080 <image> --transport http --http-host 0.0.0.0 --http-port 8080 | ||
| CMD ["uv", "run", "mcp-for-unity"] |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
mcp-for-unity CLI default transport stdio documentation
💡 Result:
Short answer: The MCP framework’s STDIO transport is documented as the default transport (uses stdin/stdout); the mcp-for-unity server supports a CLI --transport option (e.g., --transport stdio) and includes stdio examples in its README. See: [1][2][3][4].
Sources
- STDIO transport docs (MCP Framework). [1]
- MCP transports overview showing STDIO is default. [2]
- unity-mcp GitHub README (CLI examples, note HTTP default in Unity UI; stdio available via --transport stdio). [3]
- PyPI/packaging example showing mcp-for-unity launched with --transport stdio. [4]
🌐 Web query:
unity-mcp mcp-for-unity default behavior no arguments
💡 Result:
If you run the Unity‑MCP server with no command‑line arguments, it uses the built‑in defaults: port 8080, plugin timeout 10000 ms, and the HTTP transport as the client transport (STDIO/streamableStdIO variants appear in some forks/configs but the official defaults are HTTP). Sources: [1][2].
Sources:
- IvanMurzak Unity‑MCP README (defaults: --port=8080, --plugin-timeout=10000, --client-transport=http). [1]
- CoplayDev / unity-mcp README (usage & defaults). [2]
Add --transport stdio flag to the CMD — mcp-for-unity defaults to HTTP transport (port 8080) when invoked with no arguments, not stdio. Explicitly pass --transport stdio to the command:
CMD ["uv", "run", "mcp-for-unity", "--transport", "stdio"]
Without this flag, the server will attempt to bind to HTTP instead of communicating via stdin/stdout as expected in a containerized MCP setup.
🤖 Prompt for AI Agents
In @Server/Dockerfile at line 33, Update the Dockerfile CMD that invokes the
mcp-for-unity binary so it explicitly passes the stdio transport flag; replace
the current CMD ["uv", "run", "mcp-for-unity"] invocation with one that includes
"--transport", "stdio" so the container uses stdin/stdout instead of defaulting
to HTTP (ensure the CMD array passed to the container includes the two
additional arguments).
- Changed Dockerfile CMD to use stdio transport by default - Added docker/ directory with MCP Registry server.yaml and Antigravity config example - stdio is required for Docker MCP Toolkit integration - HTTP transport still available via: --transport http --http-host 0.0.0.0 --http-port 8080
ayhanmalkoc
force-pushed
the
feature/docker-stdio-transport
branch
from
d5c6c19 to
6ddd1f9
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @docker/TEST_RESULTS.md:
- Line 10: Update each of the five fenced code blocks to include the correct
language specifier: add ```docker for the docker ps output block (NAMES STATUS
PORTS), ```json for the event stream response block (event: message), ```bash
for the docker logs output block (INFO: WebSocket /hub/plugin [accepted]),
```text for the plain text block (Sahne: TerminalScene), and ```bash for the log
entries block (INFO: 172.17.0.1 - "POST /mcp HTTP/1.1" 200 OK) so the markdown
conforms to MD040 and renders with proper syntax highlighting.
- Around line 3-10: TEST_RESULTS.md currently documents only HTTP transport
which contradicts the PR goal of making stdio the default; update
TEST_RESULTS.md to either (A) replace or augment the HTTP examples with stdio
verification steps demonstrating MCP over stdin/stdout (show how to run the
gateway/container and send/receive via stdio), including a note that
antigravity-mcp-config.example.json uses "type": "stdio", or (B) explicitly
label the file as HTTP fallback documentation and add a separate section with
stdio test verification steps that reference the
antigravity-mcp-config.example.json "type": "stdio" configuration to validate
the PR change.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
Server/Dockerfiledocker/TEST_RESULTS.mddocker/antigravity-mcp-config.example.jsondocker/mcp-registry/server.yaml
🚧 Files skipped from review as they are similar to previous changes (3)
- Server/Dockerfile
- docker/mcp-registry/server.yaml
- docker/antigravity-mcp-config.example.json
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 468
File: Server/DOCKER_OVERVIEW.md:22-22
Timestamp: 2025-12-19T21:09:44.740Z
Learning: In the Unity MCP project, the Docker workflow (.github/workflows/publish-docker.yml) intentionally uses the DOCKER_USERNAME secret instead of hardcoding "msanatan" to allow users who fork the repository to publish to their own Docker Hub repositories, while the documentation (Server/DOCKER_OVERVIEW.md) correctly references the official image location "msanatan/mcp-for-unity-server" for end users.
📚 Learning: 2025-12-19T21:09:44.740Z
Learnt from: msanatan
Repo: CoplayDev/unity-mcp PR: 468
File: Server/DOCKER_OVERVIEW.md:22-22
Timestamp: 2025-12-19T21:09:44.740Z
Learning: In the Unity MCP project, the Docker workflow (.github/workflows/publish-docker.yml) intentionally uses the DOCKER_USERNAME secret instead of hardcoding "msanatan" to allow users who fork the repository to publish to their own Docker Hub repositories, while the documentation (Server/DOCKER_OVERVIEW.md) correctly references the official image location "msanatan/mcp-for-unity-server" for end users.
Applied to files:
docker/TEST_RESULTS.md
🪛 markdownlint-cli2 (0.18.1)
docker/TEST_RESULTS.md
16-16: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
66-66: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
78-78: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
94-94: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
107-107: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Sourcery review
| ## Test Environment | ||
|
|
||
| | Component | Version/Status | | ||
| |-----------|---------------| | ||
| | Docker Desktop | Running | | ||
| | Unity Editor | 2022.3+ LTS | | ||
| | Python MCP Server | Container `unity-mcp-test` | | ||
| | Transport | HTTP (port 8080) | |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check the full TEST_RESULTS.md file
cat -n docker/TEST_RESULTS.mdRepository: CoplayDev/unity-mcp
Length of output: 3241
🏁 Script executed:
# Check the git log to understand the PR context
git log --oneline -10Repository: CoplayDev/unity-mcp
Length of output: 142
🏁 Script executed:
# Look for the PR title/message
git log -1 --format=fullerRepository: CoplayDev/unity-mcp
Length of output: 679
🏁 Script executed:
# Search for stdio transport references in the codebase
rg -i "stdio" --type-list | head -20
rg -i "stdio" -A 3 -B 3Repository: CoplayDev/unity-mcp
Length of output: 50785
🏁 Script executed:
# Check what files are in the docker directory
ls -la docker/Repository: CoplayDev/unity-mcp
Length of output: 390
🏁 Script executed:
# Check if TEST_RESULTS.md is new in this commit
git show --stat 6ddd1f9 | grep -A 20 "docker/"Repository: CoplayDev/unity-mcp
Length of output: 3562
🏁 Script executed:
# Check the Dockerfile to see what actually changed
git show 6ddd1f9:Server/Dockerfile | head -30Repository: CoplayDev/unity-mcp
Length of output: 692
🏁 Script executed:
# Check if there are any stdio transport examples in the docker/ additions
git show 6ddd1f9 -- docker/Repository: CoplayDev/unity-mcp
Length of output: 5189
TEST_RESULTS.md contradicts the PR's objective—document demonstrates HTTP transport while PR makes stdio the default.
This newly-added file shows only HTTP transport tests (curl to http://localhost:8080, POST to /mcp), but the PR is titled "make stdio transport default for Docker MCP Gateway compatibility" and the commit explicitly states stdio is required for Docker MCP Toolkit integration. The antigravity-mcp-config.example.json in the same directory correctly uses "type": "stdio", making the HTTP-only test results inconsistent with the PR's intent.
Either:
- Update TEST_RESULTS.md to demonstrate stdio transport (MCP over stdin/stdout) to validate the actual change, or
- Clearly label this as supplementary documentation of HTTP fallback capability and add separate stdio test verification.
🤖 Prompt for AI Agents
In @docker/TEST_RESULTS.md around lines 3 - 10, TEST_RESULTS.md currently
documents only HTTP transport which contradicts the PR goal of making stdio the
default; update TEST_RESULTS.md to either (A) replace or augment the HTTP
examples with stdio verification steps demonstrating MCP over stdin/stdout (show
how to run the gateway/container and send/receive via stdio), including a note
that antigravity-mcp-config.example.json uses "type": "stdio", or (B) explicitly
label the file as HTTP fallback documentation and add a separate section with
stdio test verification steps that reference the
antigravity-mcp-config.example.json "type": "stdio" configuration to validate
the PR change.
| | Docker Desktop | Running | | ||
| | Unity Editor | 2022.3+ LTS | | ||
| | Python MCP Server | Container `unity-mcp-test` | | ||
| | Transport | HTTP (port 8080) | |
There was a problem hiding this comment.
Add language specifiers to all fenced code blocks.
All 5 fenced code blocks lack language specifications, violating markdown lint rule MD040. Update each to specify the appropriate language:
- Line 16:
docker(docker ps output) - Line 66:
json(event stream response) - Line 78:
bash(docker logs output) - Line 94:
text(plain text output) - Line 107:
bash(log entries)
🔧 Proposed fixes for markdown linting
-```
+```docker
NAMES STATUS PORTS-```
+```json
event: message-```
+```bash
INFO: WebSocket /hub/plugin [accepted]-```
+```text
Sahne: TerminalScene-```
+```bash
INFO: 172.17.0.1 - "POST /mcp HTTP/1.1" 200 OKAlso applies to: 16-16, 66-66, 78-78, 94-94, 107-107
🤖 Prompt for AI Agents
In @docker/TEST_RESULTS.md at line 10, Update each of the five fenced code
blocks to include the correct language specifier: add ```docker for the docker
ps output block (NAMES STATUS PORTS), ```json for the event stream response
block (event: message), ```bash for the docker logs output block (INFO:
WebSocket /hub/plugin [accepted]), ```text for the plain text block (Sahne:
TerminalScene), and ```bash for the log entries block (INFO: 172.17.0.1 - "POST
/mcp HTTP/1.1" 200 OK) so the markdown conforms to MD040 and renders with proper
syntax highlighting.
1 participant
Summary
This PR updates the Dockerfile to use stdio transport by default, making it compatible with Docker MCP Toolkit/Gateway.
Changes
Why?
Docker MCP Gateway requires stdio transport for communication. This change enables Unity-MCP to be added to the Docker MCP Catalog for one-click installation.
HTTP Transport
HTTP transport is still available:![]()
--transport http --http-host 0.0.0.0 --http-port 8080
\\�ash
docker run -p 8080:8080
\\
Related
Summary by Sourcery
Set stdio as the default transport for the Unity MCP Docker image and add Docker MCP Registry/catalog configuration assets.
New Features:
Build:
Documentation:
Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.