[FEATURE] Let marketplace plugins reference a released .mcpb bundle by URL with a SHA-256 pin, instead of committing the bundle to the marketplace repository

Problem

A plugin that ships a native MCP server has to embed it as an .mcpb bundle, since plugins may only declare remote or MCPB servers (#69940). For Claude Desktop the bundle must be part of the marketplace repository itself: referencing it by URL is rejected with

MCPB URL references are not allowed in plugins because the target can change after review

So every release of every native plugin adds a 35 to 50 MB binary to the marketplace repository's history, forever. A marketplace with three plugins is already over 100 MB after one week, and a bundle update means committing a new copy rather than pointing at the release that CI already built, signed and published.

The rule protects a real property: what was reviewed must be what gets installed. But a committed file is not the only way to get that property.

Proposal

Allow a marketplace to reference a bundle that lives outside the repository, as long as the reference carries a SHA-256 digest of the bundle. Two forms would cover it:

1. A plugin's mcpServers may point at an https URL ending in .mcpb, together with a digest, for example

``json
"mcpServers": {
"url": "https://github.com/owner/project/releases/download/v1.2.0/project-1.2.0-universal.mcpb",
"sha256": "6bfa50e3..."
}
``

1. A marketplace entry may use the existing archive source with its sha256 field, where the zip contains the plugin directory with the bundle inside.

A pinned digest is as immutable as a committed file: if the asset behind the URL changes, the digest no longer matches and the install is refused, which is exactly the outcome the review rule wants. The marketplace commit still records which bytes were reviewed, as sixty-four hex characters instead of fifty megabytes.

Current state, for reference

• Claude Code already accepts a URL in mcpServers and downloads the bundle into its plugin cache, and it already supports archive sources with a sha256 pin and https-only redirects. The Code side needs no change beyond honouring a digest on a bundle URL.
• Claude Desktop 2.2553.1.0 contains the code to download a plugin's bundle from a URL and to fetch archive sources. Two rules stop it from reaching GitHub releases: the archive must be same-origin with the marketplace URL, and the download refuses redirects, which every GitHub release asset performs. As far as I can tell the "not allowed after review" rejection is not produced by the Desktop client; it appears to come from the marketplace ingestion on the claude.ai side.

What the change would give

• Marketplace repositories stay small, and a bundle update is a one-line change that a release pipeline can make.
• The bundle installed by Desktop is byte-identical to the one the project's own CI built and signed, verifiable by anyone against the release page.
• Publishers who already build universal bundles in CI no longer need a second, manual copy step to get them in front of Desktop users.

Example

https://github.com/thegreystone/claude-plugins commits the bundles for three native plugins (rpg-mcp, mcp-email, mnemic), each built and published as a GitHub release asset by its own project. A small tool in that repository exists only to download the release asset and commit it. With a digest-pinned reference, that tool would write one line.