fix(registry): Docker MCP Catalog → docker run install (closes #483)#484
Merged
Conversation
…ocker:// URL) Two stacked bugs were preventing 'Add server from Docker MCP Catalog' from ever working: 1. internal/registries/search.go — parseDocker left ServerEntry.URL empty, then constructServerURL synthesised 'docker://mcp/<name>'. The frontend treated any non-empty URL as an HTTP transport and issued POST 'docker://mcp/sqlite' → 'unsupported protocol scheme: docker' (the user-visible error in #483). Fix: parseDocker now emits InstallCmd 'docker run -i --rm mcp/<name>' (matching the parseFleur pattern for OCI servers) and constructServerURL no longer fabricates URLs for protocolDocker. 2. frontend/src/services/api.ts + types/api.ts + views/Repositories.vue — the backend contract serialises install_cmd / connect_url in snake_case, but the Vue code read server.installCmd / server.connectUrl (camelCase), so the value was always undefined. With #483's URL gone, the second bug surfaced as 'Either url or command parameter is required'. Fix: read snake_case consistently (matches source_code_url etc. already used elsewhere in the same file). Regression tests: - TestParseDocker asserts InstallCmd populated, URL empty. - TestConstructServerURL/docker_protocol_returns_empty asserts no synthetic URL. End-to-end verified via curl (REST + MCP tool call) and Playwright- style Chrome flow: a sqlite catalog entry now lands as {protocol:stdio, command:docker, args:[run,-i,--rm,mcp/sqlite]}, auto-quarantined for review. Refs: #483
Deploying mcpproxy-docs with
|
| Latest commit: |
d0819c4
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b0c395f1.mcpproxy-docs.pages.dev |
| Branch Preview URL: | https://fix-483-docker-catalog-insta.mcpproxy-docs.pages.dev |
📦 Build ArtifactsWorkflow Run: View Run Available Artifacts
How to DownloadOption 1: GitHub Web UI (easiest)
Option 2: GitHub CLI gh run download 26142774386 --repo smart-mcp-proxy/mcpproxy-go
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #483. Adding a server from the Docker MCP Catalog repository now produces a valid stdio config (
docker run -i --rm mcp/<name>) instead of the syntheticdocker://mcp/<name>URL that the frontend then mis-classified as an HTTP transport.Two stacked bugs were both blocking the flow — fixing #1 alone surfaces #2.
Bug 1 — backend:
parseDockerproduced a fake URLinternal/registries/search.goleftServerEntry.URLempty inparseDockerand thenconstructServerURLfilled the gap withdocker://mcp/<name>. The frontend treats any non-emptyserver.urlas an HTTP endpoint, so the MCP client triedPOST docker://mcp/sqlite→unsupported protocol scheme: docker(the exact error in #483).Fix:
parseDockernow emitsInstallCmd: "docker run -i --rm mcp/<name>"(matching the OCI pattern thatparseFleurwas already using), andconstructServerURLno longer fabricates URLs forprotocolDocker. TheURLfield is reserved for HTTP/SSE endpoints.Bug 2 — frontend: snake_case vs camelCase mismatch
The backend contract (
contracts.RepositoryServer) serialisesinstall_cmdandconnect_urlin snake_case, butfrontend/src/{services/api.ts,types/api.ts,views/Repositories.vue}were readingserver.installCmd/server.connectUrl(camelCase). Alwaysundefined. Pre-fix, Docker entries fell through toserver.url(the fakedocker://value), so this latent bug was hidden behind Bug 1.Fix: read
install_cmd/connect_urlconsistently, matchingsource_code_urletc. already used in the same file.Regression tests
TestParseDockerassertsInstallCmdpopulated andURLempty.TestConstructServerURL/docker_protocol_returns_emptyasserts no synthetic URL.Verification
End-to-end verified locally:
curl /api/v1/registries/docker-mcp-catalog/servers?q=sqlitereturnsinstall_cmd: "docker run -i --rm mcp/sqlite", nourl.upstream_serversvia MCP with that command/args registers the server cleanly as{protocol: stdio, command: docker, args: [run,-i,--rm,mcp/sqlite]}.Follow-up
A larger registry modernisation is being drafted under
specs/051-registry-modernization/— adopt the canonicalregistry.modelcontextprotocol.iov0 schema (packages[]/remotes[]), retire stale fallbacks (Smithery, Azure demo), and unify the parsed payload so the frontend doesn't have to guess transport frominstallCmdvsurl. This PR is the narrow, ship-now half.Refs: #483