feat(mcp-registry): publish custom tools server to mcp-registry

[Yuan325]

Description

This PR adds a new github action workflow to publish Toolbox to mcp-registry. This only publishes the custom tools server, prebuilt-tools will be added in a different PR once this is successful.

The workflow will be triggered on (1) any new release tag (v*) or (2) manually via GHA workflow dispatch. It will grab the version number from the server.json file.

The server.json file will be updated by release please during every release.

Note: server that are published in the mcp-registry is immutable. In cases where we successfully published a server and would like to make an update, we will have to update the version field in .registry/server.json and manually publish another server with a new version.

PR Checklist

Thank you for opening a Pull Request! Before submitting your PR, there are a
few things you can do to make sure it goes smoothly:

• Make sure you reviewed
  CONTRIBUTING.md
• Make sure to open an issue as a
  bug/issue
  before writing your code! That way we can discuss the change, evaluate
  designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)
• Make sure to add ! if this involve a breaking change

🛠️ Fixes #1659

Issue at mcp-registry to support GAR (#427)

[averikitsch]

Can you take a look at _meta to see if it's helpful?

"_meta": {
    "io.modelcontextprotocol.registry/publisher-provided":

Looks like its tracking the build system which may mean more trust.

[averikitsch]

Should we look into https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/generic-server-json.md#server-with-custom-installation-path for a non-container based package?

[averikitsch]

Can you update the developer.md with info? Thanks!

[averikitsch]

Lgtm. We should think about documentation on our website. I also slightly worry about the tools.yml the user writes will contain env vars which means it would require adding env vars to the docker run command.

[Yuan325]

@averikitsch Sounds good. There might still be changes after this merge to see if the publishing is successful. Once this publishes successfully, the next steps is to (1) add more flags/env vars, (2) publish each prebuilt tools, and (3) add docs.

I've added the _meta information in the design. Will look deeper into this after implementation of the prebuilt tools.

For non-container packages, it will have to be deployed in one of the supported package deployment. Are we looking to use the binaries deployed at GCS?