Add RubyGems (rubygems.org) as a supported package registry type

Summary

Ruby-based MCP servers cannot be listed via their native package registry today. rubygems.org is the standard distribution channel for Ruby CLI apps, but the only workarounds are an OCI image or an mcpb download. This proposes "registryType": "rubygems".

{
  "packages": [
    {
      "registryType": "rubygems",
      "identifier": "widget-mcp",
      "version": "1.2.3",
      "runtimeHint": "gem",
      "transport": { "type": "stdio" }
    }
  ]
}

Runtime

RubyGems has a single-shot runner, gem exec, shipped with RubyGems 3.3+ (bundled with Ruby 3.1+):

gem exec --silent --conservative --gem <identifier> -v <version> -- <command> [args]

--silent is required: without it, first-run install progress goes to stdout and corrupts the JSON-RPC handshake. --conservative reuses an already installed matching version and runs offline.

Two caveats I'm aware of at present: gem exec installs into the user's regular GEM_HOME, with no isolated store and no cleanup, and a pre-existing Ruby 3.1+ is required (unlike npx or uvx, nothing can provision Ruby itself).

Ownership verification

The gemspec metadata hash carries the server name:

spec.metadata["mcp_name"] = "io.github.username/widget-mcp"

The registry reads it from GET https://rubygems.org/api/v2/rubygems/{name}/versions/{version}.json, which returns gemspec metadata verbatim, so a single call covers gem existence, version existence, and the ownership token. rubygems.org has no README API, so the mcp-name: README token used by PyPI, NuGet, and cargo is not available here.

For context: #1055 proposed [package.metadata] mcpName for cargo, but the merged PR used a README token. RubyGems differs in that gemspec metadata is exposed per version through the API, so the manifest is a natural place for this token.

Metadata key naming

The one point worth settling before the PR is the key name, since it becomes part of the publishing contract and is hard to change afterwards. I propose mcp_name.

Gemspec metadata keys are snake_case throughout, including every key rubygems.org itself recognizes: source_code_uri, changelog_uri, bug_tracker_uri, funding_uri, rubygems_mfa_required. A camelCase key would be the odd one out in any gemspec, and there is no single spelling across the registry to be consistent with in the first place (mcpName in package.json for npm, mcp-name: in the README for PyPI, NuGet, and cargo). The key an author writes should read as native Ruby.

I have a working implementation following docs/contributing/add-package-registry.md, so if there are no objections to mcp_name I will open the PR with it.

Start with docs/contributing/add-package-registry.md, then inspect the existing package registry implementations and their tests to understand the integration points. Verify the proposed rubygems registry type, gem exec runtime behavior, and mcp_name metadata lookup against the stated RubyGems API contract; done means the type can be validated and run consistently with existing registries.