Publishing the MCP server to the official MCP Registry requires the published image to carry a name label. The registry validates that label against the server.json it is given and rejects a mismatch, so the label has to ship in the image before anything can be published. Nothing else about the registry entry touches this repo.
The label
io.modelcontextprotocol.server.name=<namespace>/stdapi-ai
The value must match the name in server.json exactly. Two namespace forms are possible and the choice is made outside this repo, at publish time:
io.github.stdapi-ai/stdapi-ai — authenticates by GitHub OAuth, needs Owner on the orgai.stdapi/stdapi-ai — authenticates by a DNS TXT record on the apex
Pick one before merging, since changing it later means republishing the image.
Where
The community image is built by .github/workflows/publish.yml. It has no LABEL lines in the Dockerfile; labels come from docker/metadata-action@v5 and are passed through as labels: ${{ steps.meta.outputs.labels }} to docker/build-push-action.
So either:
- add it to the
labels: input of the metadata-action step, which keeps every label in one place and is the existing mechanism, or
- add a
LABEL line to the final stage of the Dockerfile.
The first is preferred. Note that 1-17 moves the community image off Alpine to a Debian base, so apply this to the current branch rather than to main as it stands.
Verify
Do not check the Dockerfile or the workflow file. Check the pushed manifest:
docker buildx imagetools inspect ghcr.io/stdapi-ai/stdapi.ai-community:<tag> --format '{{json .Image.Config.Labels}}'A label that is present in the build context but absent from the pushed image is the failure mode this step exists to catch.
Done when
Publishing the MCP server to the official MCP Registry requires the published image to carry a name label. The registry validates that label against the
server.jsonit is given and rejects a mismatch, so the label has to ship in the image before anything can be published. Nothing else about the registry entry touches this repo.The label
The value must match the
nameinserver.jsonexactly. Two namespace forms are possible and the choice is made outside this repo, at publish time:io.github.stdapi-ai/stdapi-ai— authenticates by GitHub OAuth, needs Owner on the orgai.stdapi/stdapi-ai— authenticates by a DNS TXT record on the apexPick one before merging, since changing it later means republishing the image.
Where
The community image is built by
.github/workflows/publish.yml. It has noLABELlines in theDockerfile; labels come fromdocker/metadata-action@v5and are passed through aslabels: ${{ steps.meta.outputs.labels }}todocker/build-push-action.So either:
labels:input of themetadata-actionstep, which keeps every label in one place and is the existing mechanism, orLABELline to the final stage of theDockerfile.The first is preferred. Note that
1-17moves the community image off Alpine to a Debian base, so apply this to the current branch rather than tomainas it stands.Verify
Do not check the Dockerfile or the workflow file. Check the pushed manifest:
A label that is present in the build context but absent from the pushed image is the failure mode this step exists to catch.
Done when
metadata-actionimagetools inspecton the pushed image showsio.modelcontextprotocol.server.name