MCP 注册表

minia2a 发布的注册表记录 JSON 中只声明了 npm 包及 stdio 传输方式，remotes 字段为 null，导致下游客户端无法发现其托管端点。

读取 MCP 注册表的客户端不会主动探测服务器，而是读取并信任注册表中的记录；若记录未声明某种传输方式，客户端就会表现为该传输方式不存在。

MCP 注册表清单有一个顶层 remotes 数组，与 packages 平级；每个元素需声明传输类型（streamable-http 或 sse）和绝对 URL。

MCP 注册表记录是不可变的：一条记录一旦发布就被冻结，修改意味着发布新版本记录（版本号递增），而非编辑原记录。

在从官方 MCP 注册表抽取的 100 条记录样本中，85 条是仅声明 remotes（托管 URL 加无包）的记录，只有 15 条是基于包的记录。

minia2a 的托管传输方式被放在一条独立的、仅声明 remotes、不含 packages 数组的记录中，与其 stdio 包记录并存。

修复后，MCP 注册表现在返回 minia2a 命名空间下的两条记录（stdio 包和远程端点），此前该目录仅显示本地包。

如果开发者同时托管 MCP 服务器并作为包发布，注册表记录必须同时声明 packages 和 remotes 两者；仅声明 packages 的记录会让所有读取注册表的客户端认为托管端点不存在。

发现（discovery）与可用性（availability）的分离是分布式系统中的经典陷阱：服务在网络上完全可用，却可能在任何依赖静态描述的目录中不可见；MCP 注册表采取客户端只读记录、不主动探测的策略，与 DNS 解析器只查记录而不验证源站在线是同一逻辑。