Repository navigation
feat(targets): Add mcp-registry target for the official MCP Registry - #945
Merged
Merged
Conversation
Publish an MCP server's server.json to the MCP Registry through its HTTP API. The target sets the manifest version to the release version, checks that each npm package is published with a matching mcpName, skips versions that are already listed and match, publishes with GitHub Actions OIDC or a MCP_GITHUB_TOKEN fallback, and verifies the new listing. Closes #944 Co-Authored-By: BYK <burak.kaya@sentry.io>
Contributor
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Address CodeQL findings: escape every character of the npm package name (keeping the leading @ like npm does) instead of only the first slash, and match the OIDC endpoint in tests by URL origin instead of a string prefix.
BYK
requested changes
Oct 31, 2026
The registry already checks, on publish, that each npm package version exists and that its mcpName matches the server name, and it returns a specific error when a fresh version has not reached npm yet. Drop the duplicate npm polling and mcpName check instead of guessing how long npm takes to serve a new version. If npm is still behind, the publish fails with the registry's message and a re-run resumes at this target.
BYK
approved these changes
Oct 31, 2026
8 tasks done
BYK
added a commit
to getsentry/publish
that referenced
this pull request
Oct 31, 2026
Craft's new `mcp-registry` target (getsentry/craft#945) logs in to the MCP Registry with GitHub Actions OIDC. Without that, it falls back to a long-lived `MCP_GITHUB_TOKEN` secret, which we'd rather not add. For OIDC to work, the workflow that runs Craft needs `id-token: write`. **Change:** add `id-token: write` to the existing workflow-level `permissions`. I didn't use a job-level block because it would replace the workflow-level permissions instead of merging with them, so the job would have to restate the rest. As a result, `waiting-for-ci` can also request OIDC tokens. It only runs this repo's own scripts and already holds `packages: write`. **Why it works in the Craft container:** Craft runs as a `docker://getsentry/craft:latest` step. The runner's `ContainerActionHandler` passes `ACTIONS_ID_TOKEN_REQUEST_URL` / `ACTIONS_ID_TOKEN_REQUEST_TOKEN` into container steps when the job has `id-token: write`, and those are the variables the target reads. **Namespace:** the registry grants OIDC tokens the `io.github.<owner>/*` namespace of the repo that runs the workflow. That's `getsentry` here, which matches `io.github.getsentry/sentry-mcp`. I haven't tested this end to end yet. The first release that includes the target will be the real test. **Things to note:** this lets any step in this workflow request an OIDC token for `getsentry/publish`. That only matters if some cloud account trusts tokens from this repo. Publishing still runs in the `production` environment behind the `accepted` + `ci-ready` gates. `pnpm test` and `pnpm lint` pass. <!-- junior-session-footer:start --> <!-- junior-conversation-id:local%3Aweb%3A0ab4fc2bd5a2e23f2c25efcf --> -- [View Session in Sentry](https://sentry.sentry.io/explore/conversations/local%3Aweb%3A0ab4fc2bd5a2e23f2c25efcf/?project=4510944073809921) <!-- junior-session-footer:end --> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: BYK <126780+BYK@users.noreply.github.com>
sentry-junior Bot
added a commit
to getsentry/toolkit
that referenced
this pull request
Nov 1, 2026
Craft 3.5.0 ships the `mcp-registry` target (getsentry/craft#945), and getsentry/publish now grants `id-token: write`, so the target can use GitHub Actions OIDC. Add it to the `packages/cli` workspace after the npm targets, require Craft 3.5.0, and remove the Publish MCP Registry workflow it replaces.
This branch was previously deployed
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
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.
Adds an
mcp-registrytarget that publishes an MCP server'sserver.jsonto the MCP Registry. It does in Craft what getsentry/toolkit's.github/workflows/mcp-registry.ymldoes today.For the release version, the target:
versionand everypackages[].versionin the manifest to the release version, in memory only.npmpackage, checks that npm serves that exact version and that itsmcpNameequals the manifestname. When listed afternpm, this is a short readiness check (at most 12 tries, 10s apart) to cover propagation lag, not the old 10-minute poll./v0.1/servers/<name>/versions/<version>. A 404 means publish. A 200 that matches the manifest (ignoring$schema) is a no-op success, so re-running a release is safe. A 200 that differs is an error, because registry versions are immutable. Any other status is an error./v0/publish, then checks that the listing matches and its status isactive.Auth: It calls the registry's HTTP API directly instead of downloading
mcp-publisher. These are the same callsmcp-publishermakes: by default, it gets a GitHub Actions OIDC token whose audience is the registry origin (the registry checks this) and exchanges it at/v0/auth/github-oidc. Without OIDC, it exchangesMCP_GITHUB_TOKEN, the same env varmcp-publisherreads, at/v0/auth/github-at. The registry gives OIDC tokens publish access toio.github.<repository owner>/*. Craft's other targets already use plainfetch, so there's no binary to pin or verify by checksum.Dry run: It still runs the read-only npm and listing checks. It doesn't wait for npm, authenticate, or publish.
Follow-ups outside this repo:
.github/workflows/mcp-registry.ymland add the target to itspackages/cliworkspace config (context: feat(mcp-server): Ship @sentry/mcp-server as a slim bundle that shares CLI auth toolkit#1731).id-token: writetoday. To use OIDC there, that job needs the permission. Otherwise, it needsMCP_GITHUB_TOKEN.Closes #944
Co-Authored-By: BYK burak.kaya@sentry.io
via BYK.
--
View Session in Sentry