基础篇
进阶篇
高频篇
精选篇
手写篇
面经篇
AI 篇
原理篇
每日一题
小程序题库
  • 知识卡片碎片时间过考点
  • 场景篇按分类整理的大前端场景考点
  • 历年面经按年份追踪真实考点
  • 算法题库NEW在线编码即时判题
  • 专项自测100 题快速查漏
  • 前端基础
    • HTTP从报文一路讲到 HTTPS
    • 浏览器渲染、事件循环、进程
    • 计算机基础Linux、网络、操作系统
  • 进阶专项
    • 设计模式23 种模式怎么用
    • 前端系统进阶学习大型项目工程化
    • 前端综合文章长期沉淀的实践文
  • 工程与工具
    • Node学习指南从环境搭建到服务端
    • NPM工作流script、依赖与发布
    • Docker容器化部署上手
    • Canvas图形与动画实战
  • 路线与导图
    • 思维导图知识点全景图
    • 学习路线按图索骥不跑偏
  • 动态
    • 公众号动态公众号历史文章
    • 博客动态站长的技术博客
    • 开发者导航常用工具与文档站
    • AI 热点每日 AI 资讯与动向
AI 工作台
简历
旧版
AIHT
内容
精选全部 AI 动态热点榜AI 日报收藏
分类
模型行业编程产品技术观点开源
更多
Agent 接入
返回首页开发者导航
AIHT
精选 / 资讯详情
8.0
热点
AI SCORE
技术实践2026-11-04 04:11

远程 MCP 服务上架渠道与审核门槛

dev.to · AI#MCP#开发者生态#服务分发
Editor brief · 编辑速览

作者结合三个服务的发布经历,比较官方 MCP Registry、Claude、ChatGPT 和 Google 的收录路径及审核限制。文章区分实际提交经验与文档要求,并指出被目录索引不代表可在助手中直接安装。

文章思维导图
Knowledge map
拖拽缩放
AI deep read

AI 深度解读

远程 MCP server 做完以后,去哪里登记,才能让用户找到并接入?作者亲自发布了 3 个服务,结论是:先上官方 MCP Registry,再准备 Claude、ChatGPT 的目录审核,其他聚合站主要用来增加曝光。

这篇值得读的地方,是作者交代了哪些已经办成、哪些还在等审核,也指出两个容易漏掉的门槛:OAuth 回调地址和工具注解。不过,登记成功、被网站收录、能从助手内安装,是三件需要分开看的事。

先分清登记、收录和助手内安装

作者在 2026-10-31 将 3 个服务发布到官方 MCP Registry。截至 2026-11-03,四个主要入口里的进度是:

  • 官方 MCP Registry 已上线,状态为 active。
  • aeo-backlink 从 2026-10-31 起等待 Claude Connectors Directory 审核。
  • ChatGPT app directory 的提交材料已经准备好,但尚未提交。
  • Google Connected Apps Platform 尚未申请。

Glama 另外从 Registry 自动收录了这 3 个服务,作者也完成了认领。但被 Glama 搜到,不等于能在助手里直接安装。

上线服务、登记目录和通过商店审核,是不同阶段的成果。

作者认为,当时值得优先考虑的是官方 Registry、Claude 和 ChatGPT 的目录,以及 Google 的预览平台。其他入口也有价值,只是性质不同:Smithery 支持通过 CLI 按 URL 发布,mcp.so 使用网页表单,部分精选列表接受 pull request。作者提交给 Docker MCP Catalog 和 awesome-remote-mcp-servers 的 PR,当时仍在等待审核。

还有一些网站只是跟踪器:它们索引其他地方已有的服务,并不存在可供开发者直接提交的入口。原文建议先做 Registry,再补发现渠道,因为部分目录本来就会从 Registry 导入数据,PulseMCP 就是其中之一。

官方 Registry 的关键,是证明域名归你控制

官方 Registry 当时没有审核队列。发布流程是安装 mcp-publisher、验证域名控制权,再提交 server.json;工具可以通过 Homebrew 安装。

命名空间由域名反写而来。作者控制 advancelabs.dev,因此使用 dev.advancelabs/aeo-search、dev.advancelabs/aeo-visibility 和 dev.advancelabs/aeo-backlink。服务实际部署在 aeo.advancelabs.dev 子域名下,也成功使用了根域名对应的命名空间。

验证时,需要生成 Ed25519 密钥对,将公钥以单行形式放到域名的 /.well-known/mcp-registry-auth,格式为 v=MCPv1; k=ed25519; p=,后面接公钥内容。该路径必须直接返回 HTTP 200,不能重定向。自动跳转到 www,或者补一个尾部斜杠,都可能让验证失败。

接着配置 server.json:$schema 指向 https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json,在 remotes 中添加类型为 streamable-http 的条目,并填写服务端点。

下面两条命令完成登录验证和发布:

mcp-publisher login http --domain advancelabs.dev --private-key <hex>
mcp-publisher publish server.json

注意第一行的 <hex> 是私钥占位符;对外公开的验证路径放的是公钥。

另一个小坑是描述长度。原文给出的上限是 100 个字符,他们有一条描述写了 101 个字符,在自己的预检查中失败。发布完成后,还要从 Registry 取回条目,确认状态确实是 active。

这些步骤主要验证身份和登记格式。作者后面发现的 OAuth 和工具元数据问题,并没有阻止 Registry 发布。

商店审核为什么会卡在 OAuth 和工具注解上

Claude 的提交入口是 claude.ai/directory/manage,需要任意付费 Claude 套餐。服务必须使用公开 HTTPS;如果接入需要认证的服务,就要使用 OAuth 2.0,公共数据则可以不设认证。

每个工具都需要 title,以及 readOnlyHint 或 destructiveHint 注解。还要提供文档、隐私政策、支持联系方式、图标和审核测试账号。列表 slug 一旦确定就不能更改,新条目会自动扫描,默认显示为 Community。

ChatGPT 的材料更多:先在 Developer Mode 测试,再从 OpenAI Platform dashboard 提交。除组织验证、公开 HTTPS 服务,以及网站、支持、隐私政策和服务条款 URL 外,还要在 /.well-known/openai-apps-challenge 提供 token,完成域名验证。

审核证据包括 5 个正向测试、3 个负向测试、审核演示视频,以及一个没有 MFA 的审核账号。认证选项是 none、OAuth 或 mixed,因此围绕用户粘贴 API key 设计的流程,按原文所述并不适配这套提交入口。

作者自己的第一个问题,就是 OAuth 只接受本机回环地址。这个限制原本出于安全考虑:允许一个回调地址,就相当于信任该地址接收用户的 Google 授权码。但托管在云端的客户端无法使用开发者本机的回环地址。

他们因此精确增加了 3 个回调:

  • Claude:https://claude.ai/api/mcp/auth_callback。
  • ChatGPT:https://chatgpt.com/connector/oauth/{callback_id}。
  • ChatGPT 旧入口:https://chatgpt.com/connector_platform_oauth_redirect。

Claude Code 则使用任意端口的本机回环重定向。作者还测试了近似地址,拒绝 http、子域名、相似主机名、额外路径、查询参数和片段,避免为了兼容客户端而放宽整个白名单。

第二个问题是,他们的 32 个工具全部没有注解,虽然这些工具实际上都是只读的。修复方式是在共享工具类型里将 annotations 设为必填,让新增工具必须声明操作性质。

Google 的情况更早期。按原文,Connected Apps Platform 于 2026-10-28 公布预览,应用可进入 Search 的 AI Mode 和 Gemini app,远程 MCP server 需要 OAuth 2.1,并在 Google Connected Console 管理。开发者通过 developers.google.com/connected-apps 申请,分阶段开放。至于美国开发者优先,原文只说有一则报道如此描述,作者没有申请,也没有亲测。

我的判断

我认同作者把 Registry 放在第一步。它能先建立可核验的发布记录,也可能被其他目录自动导入。但原文没有提供曝光、安装量或转化率的对照数据,「四个地方最重要」仍是作者的经验判断,不能据此认定其他渠道没有价值。

证据范围也要划清。作者实测完成的是 Registry 发布、Glama 收录认领,以及自身服务的修改。Claude 仍在审核,ChatGPT 尚未提交,Google 尚未申请。后三个平台的要求来自他们查阅的 2026 年 10 月下旬文档,不能写成已经走通的审核攻略。

Registry 登记成功,不能证明服务已经满足助手商店的上架要求。

OAuth 回调白名单和工具注解确实值得提前做。前者决定客户端能否完成登录,后者让客户端知道工具声称会不会写入或删除数据。但只读注解只是声明,服务端仍需保证真实行为与之匹配。

原文还有一个没有展开的问题:aeo-visibility 需要用户自备 Perplexity key,而作者又指出 ChatGPT 提交入口不适配粘贴 API key 的流程。这项认证设计要如何调整,文中没有答案,不能替他们补成已经兼容。

对于只给自己或小团队使用的服务,直接配置客户端也有现实价值。是否投入完整商店审核,应当看目标用户从哪里发现服务、是否需要在助手内安装,而不是把收集目录数量当作发布目标。

能拿来做什么

  • 准备公开远程 MCP 服务时,先检查域名验证路径能否直接返回 200,再检查 server.json 的 schema、streamable-http 配置和 100 字符描述限制。这些适合放进发布前检查,减少重复提交。
  • 用 Node 编写 MCP 工具时,可以参考作者的做法,在共享类型中强制填写 annotations,同时检查实际操作是否符合声明。只写注解,不能替代权限约束。
  • 准备接入托管助手时,提前逐项核对 OAuth 回调,分别处理云端回调和本机回环地址,并覆盖近似地址的拒绝测试。面向 ChatGPT 审核,还应准备 5 个正向、3 个负向测试及完整审核材料。
  • 想直接体验作者的服务,可以先在 Claude Code 添加 aeo-search。它提供 20 个工具,覆盖 Google Search Console、GA4 和 Bing Webmaster,并通过 Google 登录:
claude mcp add --transport http aeo-search https://aeo.advancelabs.dev/api/mcp/search/mcp

注意 --transport http 和完整端点路径,添加后还需要运行 /mcp 完成认证。另外两个服务分别是提供 5 个 AI 引用检查工具的 aeo-visibility,以及提供 7 个提及、链接机会、竞品链接来源和外联草稿工具的 aeo-backlink;三者共 32 个工具,按作者说明全部只读。

Original source

本文由 AI 通读原文后重新编写,观点部分为站内判断,细节以原文为准,来源 dev.to · AI,原文版权归原作者所有。

阅读原文
上一篇
OpenAI披露Astra一周硬件设计实践
下一篇
AI 生成应用上线前的密钥泄露自查

资讯速览

dev.to · AI · 2026-11-04 04:11

AI 评分 8.0 / 10

相关标签

#MCP#开发者生态#服务分发

继续阅读

  • Siri 开放第三方应用操作与任务组合
  • OpenAI披露Astra一周硬件设计实践
  • AI 生成应用上线前的密钥泄露自查
  • Bruster 以原生 WebView 执行浏览器自动化
  • Kitaru借MLOps机制实现Agent持久执行