feat: publish to registry

[paoloricciuti]

Partially address #42

Something to figure out:

1. Currently, I fetch a pinned version of mcp-publisher...they suggest fetching the latest, but that feels like an absurd safety hazard. Should we find a way to automate the update of that?
2. Similarly, we should technically find a way to keep the release version in the package.json in sync with the version in server.json...can changesets do that? Another option would be to write a custom step in the release.yml workflow that pushes the change in the open PR, but I currently have no idea how to do it.
3. This also means that we only push to the registry when we publish a new version of the package...I think this is probably fine, but since we release the remote one on merge, it will mean the two will be slightly out of sync. Not a big deal imho.
4. We could technically use svelte.dev as the name instead of io.github.sveltejs, but we need to add a TXT DNS record. Not a big deal, we just need to decide if we want to do it.

[changeset-bot]

🦋 Changeset detected

Latest commit: 3fbc786

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/mcp	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
mcp	Ready	Preview	Comment	Oct 8, 2025 3:21pm

[pngwn]

Looks good!

Things are nicely separated minimising risk.

The challenge with the publish-mcp workflow is that although it does segregate permissions appropriately, an attacker would be able to access an oidc token which is essentially a (temporary) key to the vault, so ensuring the integrity of that binary is critical.

I've commented a way i think we can do that.

[pngwn]

Are these binaries checked into the repo? A release can be overwritten while a commit hash cannot, so a hash would be safer.

Github releases now have automatic sha256 checksums, so if we can pin down the exact build we want to use, we can get the checksum from here and include the actual checksum in this workflow, and confirm that it matches the binary before we execute anything.

That would give about as much security as we can reasonably have (a long as we are happy with the repo at a specific commit/ release) as sha256 collision attacks are essentially impossible.

on Linux:

sha256sum ./path/to/binary

on mac:

shasum -a 256 ./path/to/binary

The value provided by the above command needs to match the binary we copy paste from github.

[paoloricciuti]

Will add the Sha check

[pngwn]

Re-reviewed.

Additionally, there is a risk of a mitm attack here. We should restrict the protocol and tls version:

--proto '=https'            # restrict to https
--proto-redir '=https'      # restrict redirects to https
--tlsv1.2.                  # restrict to modern tls version

We should also fail on non 2xx:

-fL # instead of just -L

Additionally we should download without streaming to tar until we have verified the checksum.

After we have verified the checksum we should extract only the expected file:

tar -xzf mcp-publisher-binary.tar.gz -C tmp

We should also reset permissions on the tar:

--no-same-owner 
--no-same-permissions

Then we can add the permissions back when we install

install -m 0755  tmp/mcp-publisher

[paoloricciuti]

Ugh that sounds complex...will try later and ask you for a new review 🧡

[pngwn]

Longterm, we should encourage the maintainers to generate github attestations for releases which would offer a little more security. But this is a close second.

[pngwn]

I think we can merge this in and tweak it later. The risk is pretty low right now, despite checking a variety of checksums against a single binary. We can harden that up in another pass.