1. 从一个“没人发现”的小产品说起去年年底我把自己做的一个小工具挂到了网上功能很垂直——帮独立开发者批量检查落地页的 SEO 基础项比如 title 长度、meta 描述缺失、H1 重复、图片 alt 为空这类琐碎但影响收录的问题。上线三个月自然流量每天不到二十个 UV转化率倒还行但基数太小基本等于自娱自乐。问题出在哪我复盘了很久。不是产品不行是发现路径太长。用户得先知道有这么个东西再打开浏览器注册粘贴网址等结果。每一步都在流失。而与此同时我注意到一个明显的变化身边越来越多的开发者开始把日常任务交给 AI 代理去跑——写代码用 Claude Code改 bug 用 Cursor查资料用带联网能力的对话助手。这些代理已经能读文件、跑命令、调 API但它们不知道我的产品存在更没法主动去用它。这就是我决定给小产品写一个 MCP server 的直接动机。MCP 是 Model Context Protocol 的缩写简单说它是一套让 AI 代理和外部工具之间“对话”的约定。写完之后的效果是当用户在 Claude、Cursor 这类支持 MCP 的客户端里提出“帮我检查一下这个落地页的 SEO 问题”时代理能自动发现我的工具、调用它、拿到结构化结果甚至根据我的定价规则给出报价。整个过程用户不需要离开对话窗口也不需要知道我的产品叫什么名字。这篇文章我会把整件事拆开讲清楚MCP server 到底是什么、为什么它能让 AI 代理“发现”你的产品、agent-to-agent commerce 这个趋势意味着什么、我具体怎么实现的、踩了哪些坑、以及如果你也想给自己的小产品接上这条路应该从哪一步开始。适合独立开发者、做 SaaS 小工具的人、以及对 AI 代理生态感兴趣但还没动手的读者。不需要你之前写过 MCP我会把关键概念用生活化的方式讲明白。2. MCP server 到底是什么为什么它成了 AI 代理的“插座”2.1 用一句话解释 MCPAI 世界的 USB-C你可以把 MCP 理解成 AI 代理和外部能力之间的标准插座。在 MCP 出现之前每个 AI 客户端想接一个外部工具都得自己写一套适配代码Claude 有一套Cursor 有一套别的客户端又有一套。工具提供方要维护 N 份对接逻辑累且容易出错。MCP 把这个关系反过来了。工具方只需要按协议实现一个 server暴露自己的能力有哪些工具、每个工具接受什么参数、返回什么结构任何支持 MCP 的客户端都能直接连上来用。就像 USB-C 接口统一了充电和数据传输你不需要为每个设备准备不同的线。具体到技术层面一个 MCP server 通常暴露三类能力Tools工具代理可以主动调用的函数比如“检查 SEO”“生成报告”。这是最核心的一类也是我这次主要实现的部分。Resources资源代理可以读取的数据类似文件或数据库记录。Prompts提示模板预置的提示词模板帮代理更好地使用这些工具。对独立开发者来说最有价值的是 Tools。因为它意味着你的产品能力可以被代理当成一个函数来调用而不是让用户去学你的界面。2.2 为什么代理需要“发现”能力而不是硬编码这里有个关键区别值得单独说清楚。早期的 AI 工具集成基本是硬编码的开发者提前在客户端里写死“如果用户问 SEO就调用某某 API”。这种方式的问题是工具列表是静态的新增一个工具就得改客户端代码普通开发者根本没机会被集成进去。MCP 的“发现”机制改变了这一点。代理在运行时可以查询 server 暴露了哪些工具、每个工具的用途描述是什么。当用户的请求和某个工具的描述匹配时代理就会调用它。这意味着你的产品能不能被用上取决于你的工具描述写得好不好而不是取决于你有没有关系把它塞进某个客户端的白名单。这对小产品是巨大利好。你不需要谈合作、不需要买流量只需要把工具描述写清楚、参数设计合理就有机会被代理在合适的场景下选中。我实测下来工具描述里把“什么时候该用我”写明白被调用的概率会明显提升。2.3 agent-to-agent commerce 意味着什么再往深一层看这件事的意义不只是“被调用”而是交易本身可以由代理之间完成。当代理能发现工具、调用工具、拿到结果它自然也能处理付费环节根据工具返回的报价信息决定是否继续、是否升级到付费档、是否把结果转给用户确认。这就是 agent-to-agent commerce 的雏形。传统的 SaaS 付费流程是用户看到定价页、比较、注册、绑卡、使用。而在代理场景下流程变成代理发现工具、评估能力、读取报价、在授权范围内完成调用、把结果和费用一起汇报给用户。用户看到的只是一个结果和一笔小额支出中间的摩擦被抹平了。我这次给小产品加的报价能力就是朝这个方向迈的一小步。代理调用检查工具时免费档返回基础结果同时附带一个结构化的报价对象说明完整报告需要多少费用、包含哪些额外项。代理可以把这个信息呈现给用户用户确认后代理再发起付费调用。整个链路是机器可读的不需要人去点网页。3. 动手之前先想清楚你的产品该暴露什么3.1 不是所有功能都适合做成 MCP 工具我一开始的想法很贪心想把产品的所有功能都暴露出去。后来发现这是错的。MCP 工具的设计原则和网页功能设计完全不同网页可以有很多按钮、很多页面用户自己探索但代理调用工具时每一次调用都要消耗上下文和推理成本工具太多、太碎代理反而不知道该用哪个。我的做法是先问自己三个问题这个功能能不能用一句话说清楚它解决什么问题它的输入输出是不是结构化的、可预期的它是不是用户会在对话里自然提出的需求三个都满足的才做成工具。比如“检查单个 URL 的 SEO 基础项”满足“管理我的历史检查记录”就不满足——后者更适合做成 Resource 让代理读取而不是做成一个需要参数的工具。3.2 工具粒度粗一点还是细一点这是设计时最纠结的地方。粒度太细比如把“检查 title”“检查 meta”“检查 H1”拆成三个工具代理得调用三次每次都往返一次网络慢且费 token。粒度太粗比如一个“全面检查并修复”工具参数复杂、返回巨大代理处理起来也吃力。我最后选的是中等粒度一个“检查”工具负责诊断返回结构化的问题列表一个“报价”工具负责根据问题数量给出费用估算。两个工具职责清晰代理容易理解调用次数也少。实测下来代理在大多数场景下只需要调用一次检查工具就能给出有用回答。提示工具数量控制在 3 到 7 个之间是比较舒服的区间。太少显得能力单薄太多会让代理的选择困难调用准确率下降。3.3 描述文案比代码更重要这点我必须强调。MCP 工具的description字段是代理决定要不要调用你的唯一依据。它不像网页有视觉设计帮你吸引点击代理只能读文字。所以描述要写得像给一个新同事交代任务说清楚这个工具做什么、什么时候用、输入是什么格式、返回什么。我最初的描述写得很技术化类似“执行 SEO 规则引擎并返回违规项”。结果代理很少调用它因为它不知道这跟用户的“帮我看看网站有没有问题”有什么关系。改成“检查一个网页的 SEO 基础问题当用户想知道页面为什么没被搜索引擎收录、或者想优化落地页时使用”之后调用率明显上来了。4. 核心实现从零搭一个能被代理调用的 MCP server4.1 技术选型与最小依赖我选的是官方提供的 SDK语言用 TypeScript。原因很实际我的小产品后端本来就是 Node 生态复用现有代码成本最低而且 MCP 的官方示例和文档里 TypeScript 版本最完整遇到问题好查。最小依赖其实很少核心就是 SDK 本身加一个传输层。传输方式有两种常见选择传输方式适用场景我的选择stdio本地运行客户端直接拉起进程开发调试阶段用HTTP/SSE远程服务多客户端共享正式上线用我最终上线用的是 HTTP 方式因为我的检查逻辑跑在服务器上用户本地不需要装任何东西。stdio 方式适合那种纯本地工具比如读写本地文件的场景。4.2 定义工具参数 schema 怎么写才不容易出错工具的参数用 JSON Schema 描述。这里有个坑我踩过参数类型和必填项一定要写严格。我一开始把 URL 参数写成可选结果代理有时候不传服务端报错代理拿到错误后也不知道怎么补救整个对话就卡住了。正确的做法是把必填参数标成required并且在描述里给出格式示例。比如 URL 参数我会写“完整的网页地址必须以 http:// 或 https:// 开头例如 https://example.com/landing”。代理看到示例后传参的准确率会高很多。另外返回值的结构也要稳定。我定义了一个固定的返回格式一个issues数组每项包含type、severity、message三个字段。代理拿到这种结构后能很自然地把它转述给用户或者做进一步处理。如果返回值每次结构都不一样代理的后续推理就会乱。4.3 报价逻辑让代理能读懂“多少钱”报价这块是我花时间最多的地方。核心思路是报价必须结构化且包含足够信息让代理做决策。我返回的报价对象大概长这样currency货币单位amount金额tier档位名称比如 basic、fullincludes这个价格包含哪些内容valid_until报价有效期代理拿到这个对象后可以把它转述给用户也可以根据用户之前的授权直接决定是否购买。我特意加了valid_until因为价格可能会变代理需要知道这个报价什么时候过期避免拿着旧价格去下单。注意报价信息不要藏在自然语言里。我见过有的实现把价格写成“完整报告只需 9.9 元”代理要解析这句话才能拿到数字很容易出错。结构化字段才是正道。4.4 错误处理代理最怕“沉默失败”代理调用工具失败时如果服务端只返回一个 500 错误、没有说明代理就完全不知道发生了什么只能告诉用户“出错了”。体验很差。我的做法是所有错误都返回结构化的错误对象包含错误码和人类可读的说明。比如 URL 格式不对返回INVALID_URL加一句“提供的地址格式不正确请检查是否包含 http 前缀”。代理拿到这个信息后可以自动重试或者提示用户修正而不是直接放弃。5. 联调实录在 Claude 和 Cursor 里跑通全流程5.1 本地调试先用 stdio 把逻辑跑顺正式部署前我在本地用 stdio 方式把整个流程跑了一遍。这一步的价值在于快速验证工具定义和返回结构不用每次都部署到服务器。调试时我会在客户端里输入各种刁钻的请求比如“帮我看看这个页面”“这个网址有什么问题”“我的落地页收录不好”观察代理是否能正确选中我的工具、参数是否传对、返回是否被正确解读。这个阶段我发现了一个问题代理有时候会把整个网页内容当成参数传进来而不是只传 URL。原因是我的参数描述不够明确。改成“只传网页地址不要传网页内容”之后问题解决了。5.2 部署到远程HTTP 传输的注意事项部署到服务器后用 HTTP 传输。这里有几个实际要注意的点鉴权远程 server 必须做鉴权否则任何人都能调用你的付费工具。我用的是简单的 token 机制代理在请求头里带上 token。超时检查逻辑如果跑得慢要设置合理的超时并且返回明确的超时错误让代理知道可以重试。并发多个代理同时调用时要保证报价和扣费逻辑是线程安全的避免同一个报价被重复使用。5.3 在 Cursor 里配置 MCP serverCursor 对 MCP 的支持比较直接在设置里找到 MCP 相关配置填入 server 的地址和鉴权信息即可。配置完成后Cursor 的代理就能在对话中调用我的工具。我实测的场景是在 Cursor 里让代理帮我检查一个正在开发的落地页代理自动调用了我的工具返回了问题列表还根据报价信息问我要不要生成完整报告。5.4 在 Claude 里配置 MCP serverClaude 桌面版的配置方式类似也是在设置里添加 MCP server。这里有个细节不同客户端对工具描述的解析方式略有差异同一个描述在 Cursor 里能被正确理解在 Claude 里可能需要微调措辞。我的经验是描述里多用动词和场景词比如“检查”“诊断”“当用户想……时使用”跨客户端的兼容性会更好。6. 踩过的坑与排查速查表6.1 代理不调用我的工具怎么办这是最常见的问题。排查顺序我总结成一张表现象可能原因排查方法完全不调用工具描述太技术化改成场景化描述加入“当用户想……”偶尔调用描述和其他工具重叠检查是否有功能相近的工具明确差异化调用但传参错参数 schema 不清晰加格式示例标严格必填调用后报错返回结构不稳定固定返回字段错误也结构化6.2 报价被代理误解的几种情况我遇到过代理把报价金额当成字符串处理、或者把有效期忽略的情况。解决办法是在描述里明确字段类型并且在返回示例里给出一个完整的报价对象。代理看到示例后解析准确率会高很多。6.3 性能与成本的实际感受MCP 调用本身开销不大主要成本在代理的推理上。工具返回的内容越长代理处理越慢、越贵。所以我的原则是返回必要信息不返回冗余内容。比如检查结果只返回问题项不返回整个页面的 HTML。7. 这条路接下来还能怎么走写完这个 MCP server 之后我的小产品确实多了一条被发现的路。虽然目前通过代理来的调用量还不大但趋势很明显越来越多的任务会由代理发起而不是由人打开网页发起。对独立开发者来说早点把自己的能力做成代理能调用的形式相当于在一条新渠道上提前占了位置。我接下来打算做的几件事一是把报价逻辑做得更细支持按问题严重程度分级定价二是增加一个 Resource让代理能读取我的产品文档回答用户关于功能的问题三是观察不同客户端对工具描述的偏好持续优化文案。如果你也想动手我的建议是从一个最小的工具开始先跑通“被发现、被调用、返回结果”这个闭环再考虑报价和商业化。工具描述多改几版观察代理的调用行为比闷头写代码有用得多。这个领域变化很快但底层逻辑很稳让代理能理解你、调用你、信任你你就多了一个不需要用户主动找上门的入口。