Feature request: surface target changes between server versions (listing swaps)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 7.4k
- Fork
- 1k
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 37
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelcontextprotocol/registry
-
3 registry records that cannot resolve for any client, and a caution about single-pass dead countsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
modelcontextprotocol/registry#1692 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
IsValidRemoteURL only blocks literal localhost/127.0.0.1 — misses [::1], 127.0.0.0/8, 0.0.0.0, and private/link-local addressesCó thể đã có người làm @amitvijapur đã nhận 98 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
modelcontextprotocol/registry#1465 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 48/100
modelcontextprotocol/registry#1749 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 56/100
modelcontextprotocol/registry#1719 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 28/100
modelcontextprotocol/registry#1715 · 16 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của modelcontextprotocol/registry
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ovh/ovhcloud-cli#309 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Update Help Wanted issue searchĐang mởarea/docs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
layer5io/getnighthawk#380 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày