Feature request: surface target changes between server versions (listing swaps)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Read the registry’s per-version data model and API entry points, then review the listing-swap reproduction script linked in the issue. Work out how to expose changes in remote domains or package owners across versions and how clients could request approval on updates; the issue proposes both registry and client changes but names no files, tests, or acceptance criteria.
索引モデルが issue の本文から書いたものです。
説明
Problem. A user approves an MCP server by its registry name, but a client installs whatever that name resolves to today. Nothing tells the user when the target behind the name changes: a new remote domain, or a package now published by a different owner.
Data. We compared the current version of every server in the official registry with the first version published under the same name (10 Oct 2026 dump: 142,002 versions of 41,351 servers). 1,075 servers now reach a different remote domain or package owner than their first version; 698 of those kept the same title and description. Most are probably legitimate (rebrands, hosting moves, handovers), but a takeover looks identical. Aggregate method and reproduction script: https://github.com/bl014h/atpp/tree/main/research/listing-swap (no server is named).
Proposal. Two small, opt-in signals:
- Registry: expose, per version, whether its remote domains or package owners differ from the previous version (or from the first), so clients don't each have to diff history.
- Clients: when an installed server's target changes on update, ask again — the way a phone asks again when an app requests a new permission — instead of silently following the name.
Related: pinning by digest helps (@sha256: for OCI, exact versions for npm/PyPI), and npm/PyPI Sigstore build provenance lets a client check the package was built from the repository the listing declares.
For transparency: we (Redthread) run a daily signed scan of the registry that flags this as a target-stable check, and the verifier is open source. Happy to share the dataset or help with a reference implementation if the registry or client maintainers are interested.
- 主要言語
- Go
- スター
- 7.4k
- フォーク
- 1k
- 平均マージ
- 1日 9時間
- マージ済み PR（30日）
- 29
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/registry のほかの issue
-
3 registry records that cannot resolve for any client, and a caution about single-pass dead countsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/registry#1692 ·
メンテナーはふだん 1 日以内に返信
-
IsValidRemoteURL only blocks literal localhost/127.0.0.1 — misses [::1], 127.0.0.0/8, 0.0.0.0, and private/link-local addresses対応中かも @amitvijapur が 97 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
modelcontextprotocol/registry#1465 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 56/100
modelcontextprotocol/registry#1719 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 28/100
modelcontextprotocol/registry#1715 · コメント 14 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 8/100
modelcontextprotocol/registry#1708 ·
メンテナーはふだん 1 日以内に返信
modelcontextprotocol/registry の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
[flaky test] TestValidatorCommitterDropsEmptyStatusBatch: submits to the mock VC before its stream is registered対応中かも @liran-funaro が今日担当しました。 オープンcoordinator flaky-test race-condition testing
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
hyperledger/fabric-x-committer#876 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
garethgeorge/backrest#1426 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信
-
enhancement nav-pilot
難易度 2/5 半日 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信