MCP服务器入驻Claude目录实战：20天、€52/月与完整避坑指南

我构建了一个旅行物流 MCP 连接器——6 个工具（租车、机场接送、旅游团、旅行 eSIM、行李寄存、航班赔偿），其中 3 个渲染为 MCP Apps 小组件。Remote Streamable HTTP，无认证，个人项目。

从空仓库到提交服务器用了四天，然后是二十天的等待：7 月 10 日提交给 Anthropic 连接器目录，7 月 30 日获批。

准备提交时，我几乎找不到任何关于这个流程的文字记录。所以这里是我的笔记——那些我希望一开始就知道的实际门槛、文档未记载的缓存规则（如果很晚才了解到它们，就会被坑），以及进入目录后从发布者视角看到的样子。

这不是一篇"什么是 MCP"的文章。它假设你有一个可运行的服务器，正在考虑是否要提交。

精简版，如果这正是你要的：

提交门户需要一个 Team 或 Enterprise 组织。最低是 2 个席位，不是 5 个——约 52 欧元/月。

不需要法律实体。我以个人作者身份提交的。

从提交到批准 20 天，我没有主动联系过一次。官方没有公布 SLA。

批准后默认进入 Community 层级，而且没有公布从该层级到 Verified 的路径。

你的工具集在连接时对所有已连接的用户冻结。描述可以随时编辑；工具列表不行。

从目录连接的，你的工具默认带有"always allow"。通过 URL 连接的则不会。同一台服务器。

剩下的内容是我如何了解到上述每一条，以及代价是什么。

唯一需要花钱的门槛

提交门户位于组织管理设置中，仅对 Team 或 Enterprise 组织开放。没有个人路径。

对于个人开发者，这意味着需要创建一个组织并支付 Team 计划费用。常被引用的最低要求是 5 个席位，这让我犹豫了好几周。错了：实际最低要求是 2 个席位——约 52 欧元/月（含增值税）。

这是入场的真实价格。这过程中的其他一切都是免费的。

我付钱前无法回答、现在仍然无法回答的问题是：这是入门费还是租金？批准后的列表在降级组织后还能存活吗？提交当天我就把这个问题书面发给了审核团队。一个月后，没有答案。在有人能证明不是这样之前，把它当作你需要列表时就一直订阅的订阅费——这是我目前运行的假设。

（52 欧元是我的本地增值税。你的会不同；比较税前数字。）

你不需要法律实体。我以个人作者身份提交的，表单中的所有权问题问的是你的 API 关系，不是你的公司结构。

7 月 10 日——通过管理门户提交。

7 月 30 日——获批为 Community 连接器。

7 月 30 日，几分钟后——发布。批准后的发布是自助的：一个 Publish 按钮，列表就上线了。

20 天，我没有主动联系过一次。官方没有公布 SLA；官方指导是"预期几周"。

提交表单实际检查什么

表单有 11 个步骤，部分内容在人工审核之前由机器强制执行：

它会实时连接你的服务器。表单填写中途，它会访问你的端点，统计你的工具和资源数量，并验证认证支持。我的提交显示"Tools: 6, Resources: 3, authless supported"——这是从我自己的实时服务器读回来的。所以填写表单时你的服务器必须在线且正确。

缺少 annotations.title 会立即被标记。我的工具没有设置标题。表单标记了这个问题，我添加了标题，重新部署，然后在同一会话中重新运行检查——通过了。修复后重试是可行的；你不需要从头开始。

公开的隐私政策和落地页是必需的。不是可选的，不是"即将推出"。两者都会被检查。

API 所有权问题比看起来更严格。选项区分第一方 API 和你合法代理的 API。我的连接器根据联属协议对合作伙伴的 API 进行实时调用，所以正确答案应该是"我们经授权代理合作伙伴的 API"——这没有任何阻碍地被接受了。不要声称你没有的所有权；这正是审核人员可以在一分钟内检查的事情类型。

审核人员说明是你最高杠杆的字段。我提供了触发每个工具的确切提示词，加上三个工具必须保持沉默的负面提示词。这把一个模糊的审核变成了 10 分钟的检查清单。我无法证明它加快了任何事情，但它零成本，而且表明你了解自己的触发面。

那条会坑到你的缓存规则

这是我最希望在第一天就知道的那条，因为它悄无声息地限制了你的路线图。

我是以烦人的方式发现它的。我上线了一个新工具，在我的生产服务器上用 tools/list 确认了它，打开了一个新的对话——客户端看不到它。没有任何东西损坏。客户端正在提供的是几天前我首次连接时缓存的工具列表。

客户端在连接时缓存你的工具集合，并持有它直到用户手动打开连接器设置并点击"Refresh tools list"。不是几分钟。是无限期。

我用三天做了五个实验来映射这个边界：

经得起全部五个实验检验的心智模型：接口在连接时冻结；它背后的行为是实时的。

以上都是我 2026 年 7 月底测试的观察到的客户端行为。这不是文档化的契约，任何版本更新都可能改变——如果它变了，我会更新这篇文章。

实际后果：

在分发前确定你的工具集。昨天连接的用户不会看到你明天发布的工具。永远不会，除非他们执行一个他们没有理由执行的手动操作。

在分发前也要完善你的小组件。我以为小组件 HTML 是实时资源，可以在发布后改进。不行——我用一个内边距修复证明了自己是错的，那个修复直到 Refresh 才生效。

描述可以随时编辑。这是一个真正的逃生舱：工具描述是你的触发面和搜索索引，你可以在发布后继续调整它们。

如果你需要限制某个工具的行为，在处理器中做，不要在元数据中做。元数据按用户冻结；处理器代码在每次调用时运行。注解负责声明；处理器负责执行。

那么什么时候停止构建并提交？

这是缓存规则迫使你面对的问题，我花了比应该花的时间更长才回答出来。这里混淆了两件独立的事情，让我把它们分开。

你的服务器可以随时更改。列表指向一个 URL。没有人重新审批你的代码。发布修复、切换数据源、重写处理器——这些都不涉及目录。

你的接口实际上不能。不是因为被禁止，而是因为缓存：分发后添加的工具只触达新连接。每个已经连接的人会保留他们第一天获得的表面，直到他们执行一个他们没有理由执行的手动操作。所以实际的答案不是"永远冻结"，而是：之后你添加的任何东西只服务未来用户，永远不会服务你的现有用户群。

这重新构建了停止构建的决策。它不是"我的产品完成了吗？"而是"这个表面是否足够宽，让我乐意把它提供给本月连接的任何人？"正是出于这个原因，我在提交前发布了全部六个垂直领域——不是因为六是正确的产品，而是因为之后添加的工具对最先到来的用户是不可见的。

你的列表是一份独立的副本，它永远不会自动更新

我是几周后仔细阅读自己的发布者设置才发现这一点的。

你的列表携带着你自己工具名称的副本。提交时，向导会探测你的实时服务器并记录它发现的工具名称。然后这个列表作为可编辑字段存在于列表中——它不跟随你的服务器。发布第七个工具后，列表仍然宣传六个，直到你去编辑它，而那个编辑在生效前需要审核。

为什么它听起来比实际上更重要：设置页面明确说明那些宣传的名称为连接器建议提供动力。所以发现表面读取的是你的列表，而不是你的服务器。你的列表没有宣传的工具即使你的服务器完美运行，对建议也是不可见的。介于客户端缓存和这个之间，"稍后添加"是一个比看起来要弱得多的选项。

其余的编辑规则，既然它们不一致到值得记住的程度：

列表元数据（标语、描述、分类、链接、图标）：可编辑，生效前需审核。我在一个已发布的列表上提交了一批这类内容，然后观察发生了什么：状态保持 Published，旁边有"pending changes in review"的提示。编辑不会让你下架。

宣传的工具和提示词名称：可编辑，生效前需审核。

给审核人员的测试说明：立即保存，无需审核。

用例、数据处理、合规问答：一旦发布永久锁定。更改它们意味着给审核团队发邮件。

Display name：可编辑，但会触发完整复审，且被标记为影响现有用户。slug 永不变更。

所以你在提交前最需要慎重考虑的字段，并非你以为的那些。没有人提醒你，合规问题的答案是单向的。

那个页面上唯一既无法编辑也无法申请的是 Verified 级别——详见下文。

Widget 确实会渲染——包括在移动端

没有任何地方明确回答过，第三方连接器的 MCP Apps widget 是否真的会在 claude.ai 中渲染，还是这只是第一方集成的特权。答案是：它们确实会渲染。网页版和移动端均支持，图片从通过 csp.resourceDomains 声明的外部域名加载，点击按钮时会弹出原生"打开外部链接"确认框。

需要注意的是：会渲染 widget 的工具会被归类为交互式工具，这在工具注册表中需要选择性加入（opt-in）。对于已经连接过你服务器的用户，这不会阻止调用——但如果你依赖发现功能，这是额外的考量因素。

审批后：两个级别

目录分为两个级别，这比徽章所显示的更为重要：

Community——通过自动检查。这是默认结果。

Verified——由 Anthropic 人工审核，获得勾选标记。

从 Community 升级到 Verified 没有公开发布的流程——没有标准、没有触发条件、无处申请。我直接询问了支持团队，被告知标准也不在他们的知识库中；之后我又向审核团队提出了这个问题，但尚未收到回复。如果你的计划依赖于按时间表获得 Verified 认证，目前没有任何时间表可依赖。如果你知道实际运作方式，我真心希望听听。

我最初理解错了：我以为聊天中"可能提供帮助的连接器"（Connectors that could help）建议面板是按 Verified 级别筛选的，因为在我的测试中，一个 Community 级别的连接器被忽略，而三个 Verified 级别的连接器则被推荐。文档给出了不同的说法——每个目录条目都有资格参与推荐，排名取决于使用量。所以这不是徽章的门槛，而是排名的门槛：使用量接近零的连接器无论是否通过认证都会被淹没在下方。第一天的实际效果相同，但策略完全不同：真正的杠杆是使用量，而非徽章。

权限的意外之处

这是我在文档中从未找到的、提交 Listing 最有力的论据。

当你通过 URL 连接自定义连接器时，每个工具默认都是"询问"（ask）状态——用户在每个新对话中都会收到权限提示，直到手动切换。

当你从目录列表连接同一服务器时，每个工具默认都是"始终允许"（always allow）。零权限提示。界面按注释将工具分组——"只读工具"（Read-only tools）和"交互式工具"（Interactive tools）——每组都有自己的三向开关。

相同的代码、相同的端点、相同的工具。唯一的区别在于来源。目录审批被客户端视为对服务器的信任，从而消除了首次使用的全部摩擦步骤。

如果你正在权衡 €52/月与"我可以直接给人一个 URL"哪个更值——这才是电子表格里没有的东西。

发布者仪表板，及其字段的真正含义

已发布的连接器在管理设置中获得一个指标仪表板。每天更新一次，最多有 24 小时的延迟，并且会隐藏调用次数少于 5 的窗口。

四个字段，第一个是陷阱：

Directory Rank。工具提示很明确：按过去 30 天内尝试连接的账户排名。它衡量的是连接尝试，而非使用量。你的排名在用户点击 Connect 时上升，无论他们是否实际调用过工具。

Tool Call Users (30d)。调用过工具的不同账户数。这是你的真实用户数，会比你预期的小得多。

Tool Calls (30d) 和 Error Rate (30d)。不言自明。

排名和健康状态是在 Anthropic 的代理层计算的，因此只有通过 Claude 的流量才会被统计——这与你自有服务器的情况恰好相反。详见下文。

我不会引用自己的数据。发布五天后只是一个点，不是一条曲线，一个点只能说明作者有多不耐烦。

"可见"的实际含义

仪表板显示的是连接数。它不显示浏览量，而这是两个截然不同的量级。

提交表单允许你提供自定义图标 URL，我的指向自己的域名。这意味着每次目录渲染我的卡片时，我自己的访问日志都能看到。

我不会附上数据，也不会声称那些都是人类在查看我的卡片——客户端预取整个列表栏会产生相同的日志行，我目前还无法区分两者。但即使只有一小部分是真实的人，数量仍然比我的连接数高出几个数量级。

这足以得出我需要的唯一结论：对于新的 Listings 来说，稀缺的从来不是曝光度。目录让新条目出现在大量流量面前。稀缺的是将曝光转化为 Connect 点击——这意味着你的图标、名称和一句话简介在第一天所做的工作，比所有工具描述加起来还要多。我在工具上花了数天时间，却只花了一个小时写简介。比例错了。

回头去检查你自己的列表设置

发布感觉像终点线，但实际上不是——这是我踩过的坑。

发布者设置页面有一组可选字段，标记为仅由审核团队先前设置的——作者详情、纯英文权限说明、面向 API 和 Code 用户的集成代码片段、截图轮播（每张图片都配有它所演示的提示词），以及一个声明你的连接器附带可视化界面的复选框。

我的这些字段在发布后空置了三天，我从未向下滚动查看它们。我只是因为寻找另一个问题的答案时才去看了一眼。

其中两个字段只需纯复制粘贴，花了十分钟。如果这能节省你的起草时间，以下是我填入的确切内容。

Claude API——通过 mcp_servers 参数添加到 Messages API 请求中（需要 MCP connector beta header）：

{
  "type": "url",
  "url": "https://api.triplogistics.app/mcp",
  "name": "trip-logistics-assistant"
}

Claude Code——一行代码，无需 API key，因为服务器是公开且只读的：

claude mcp add --transport http trip-logistics https://api.triplogistics.app/mcp

它们上方有一个相关字段"适用产品"（Works with），驱动目录自己的过滤器。如果你的列表声称支持 API 和 Claude Code 作为适用平台，但这两个框是空的，你就只是在做声称而没有提供相应的操作说明。

最后那个复选框是今天值得勾选的。浏览目录你会看到一些卡片带有 Interactive 徽章。我的没有——尽管其他所有界面都识别服务器为交互式的。提交向导的实时探测统计了我的 widget（"Resources: 3"）。连接器自己的权限界面将我六个工具分类为"交互式工具（3）"和"只读工具（3）"，直接从服务器提供的注释中读取。客户端知道，但目录不知道。

所以徽章并非来自服务器声明的内容。最可能的原因是那个未勾选的复选框。我已经勾选了；在撰写本文时该变更仍在审核队列中，所以将其视为一个强假设而非已证实的机制。无论如何这不是 Verified 级别的特权：社区列表也可以拥有它。

所以：在发布后，去检查你自己设置中的每个字段，包括折叠部分以下的字段。目录不断开放曾经属于审核团队的控件，而当这种情况发生时没有人会通知你。

四个没人提醒你的运营问题

记住仪表板部分提到的代理这一点——这是它的另一面。Anthropic 只统计通过 Claude 的流量；你自己的服务器统计一切，而其中大部分不是人。

发布到 MCP Registry 后，爬虫集群蜂拥而至。几天之内，我的 /mcp 端点每天收到大约 2000 次请求，来自扫描器、评分引擎和索引器，每隔几分钟就访问一次，用合成参数调用我全部六个垂直领域的工具。它们不会产生负载，但会污染你的数据库：我记录了 861 次工具调用，几乎全是机器人。按 user-agent 和来源 IP 对流量分类，否则你自己的使用数据就是自欺欺人的谎言。加上分类器之后，我终于看到了第一个真实的外部调用——来自亚美尼亚的一张 eSIM 订单请求。

所有客户端共享同一批出口 IP。每个 claude.ai 用户访问你时都来自相同的几个 IP 地址，因此激进的单 IP 限速策略会误伤真实用户而非攻击者。限速要设得宽松一些，并专门关注那些 IP 段的 429 日志。这也意味着无认证的服务器完全无法区分其用户。这是设计层面的固有局限，不是日志记录的缺口。

实现 SIGTERM 的优雅关闭。我的首次上线期间，一个工具调用还在执行中被直接杀掉了。现在服务器会在退出前完成所有进行中的请求。否则每次部署都会对正在对话的用户造成一次小型故障。

slug 一旦锁定就永久不变，发布后的编辑需要重新审核。元数据编辑（标语、描述、链接、图标）会排队作为待处理变更，而你的列表保持在线；名称变更则强制触发完整复审。像选域名一样选择你的 slug。

如果重来我会怎么做

更早冻结工具集。我后期才添加两个垂直领域，被迫在时间压力下重新验证所有内容，纯粹是因为缓存规则。

在上线前构建机器人过滤器，而不是之后。两周的指标数据都无法使用。

不要把徽章当作目标。Usage 驱动排名，排名驱动推荐。其他一切都是下游。

先写审核者说明。强迫自己列出每个工具必须触发的精确提示词——以及绝对不能触发的那些——这是对你的工具描述最好的一次设计审查。我的两个描述因此改了。

以上所有内容的一个限制

我第一次提交就通过了，所以这里写的都是happy path。我不知道被拒绝是什么样子的：如何沟通、反馈有多具体、以及需要重新提交多少内容。如果你经历过那个过程，我更愿意链接你的文章而不是猜测。

为什么仍然值得做

目录中列出了几百个连接器，而实际野外的 MCP 服务器有数千个。审核队列是瓶颈，这种不对称对任何愿意排队的人来说都是有利的。提交前我检查了自己的分类，有好几个根本没有任何结果。

我将在 8 月底发布后续：曲线而非点，包括当一个列表从"新"货架上掉下来时会发生什么——还没有人写过这个。

那个连接器，如果你想看通过审核的是什么：在 Claude 目录搜索 "trip logistics"，或者 triplogistics.app。披露：连接器中的预订链接是联盟链接——在列表和网站上都有说明。

我也在考虑为其他人做这件事——不是知识，那都在上面而且免费的，是动手的部分：在你提交之前审查你的服务器和你的提交材料，让你第一次就通过。如果觉得有用，在评论区说一声；我在评估这是否值得做。

如果你正在提交过程中，遇到了我没有覆盖的东西——尽管问。我会回答，并把修正内容合并到这篇文章中。