1. 一个独立开发者为什么需要给自己的产品配一个 MCP server去年年底我把自己的一个小工具挂到了线上功能不复杂就是帮用户做特定格式的数据清洗和结构化输出。上线之后流量一直不温不火靠搜索引擎和几个社区帖子带量增长曲线平得像一条直线。直到有一天我在调试自己的 AI 工作流时突然意识到一个问题我一直在用 AI 代理帮我处理各种任务但我的产品对 AI 代理来说是完全不可见的。AI 代理不知道它存在不知道它能干什么更不可能主动去调用它。这个认知让我开始认真研究MCP server这件事。MCP 全称是 Model Context Protocol简单说就是一套让 AI 代理能够发现、理解并调用外部能力的标准协议。你可以把它理解成 AI 世界的 USB 接口——以前每个工具都要自己写一套对接逻辑现在只要按照 MCP 的规范暴露自己的能力任何支持这个协议的 AI 客户端都能直接识别和使用。Claude Desktop、Cursor、以及最近越来越多的 AI 编程工具都在快速跟进这个协议。我当时的判断很直接如果 AI 代理正在成为用户和软件之间的新中间层那我的产品必须在这个中间层里有一个入口。这个入口不是网页不是 API 文档而是一个 AI 代理能读懂的 MCP server。更进一步我给它加上了报价能力——当 AI 代理发现这个工具并判断需要使用时它可以自动获取价格信息并完成调用决策。这就是agent-to-agent commerce的雏形代理之间自主完成服务发现、能力评估和交易决策。这篇文章我会完整拆解我是怎么从零给自己的小产品写了一个 MCP server中间踩了哪些坑协议的关键细节是什么以及为什么我认为每个独立开发者现在都应该认真考虑这件事。不管你是做 SaaS、做 API 服务还是做任何可以被程序调用的产品这套思路都能直接复用。2. MCP server 到底暴露了什么协议核心概念拆解2.1 三个核心原语Tools、Resources、PromptsMCP 协议定义了三类能力暴露方式理解它们的区别是写好 server 的第一步。Tools是最关键的一类代表可以被 AI 代理执行的操作。每个 tool 有名字、描述、输入参数的 JSON SchemaAI 代理根据这些信息判断什么时候该调用它。我的数据清洗产品核心能力就是通过 tool 暴露的——代理看到clean_and_structure这个 tool 的描述后就知道当用户需要把杂乱数据整理成结构化格式时可以调用它。Resources代表可以被读取的数据更像是文件或数据库查询结果。比如你可以暴露一个 resource 让代理读取产品的使用文档、定价表或者历史处理记录。Resources 和 Tools 的区别在于Tools 会产生副作用执行操作Resources 是只读的。Prompts是预定义的提示模板让代理可以快速调用特定场景的提示词。这个我用得比较少但对于需要引导代理按特定方式交互的场景很有用。我建议刚开始只需要专注做好 Tools因为这是代理真正用起来你的产品的入口。Resources 和 Prompts 可以后续按需补充。2.2 传输层选择stdio 还是 HTTPMCP server 的传输方式主要有两种选择哪种取决于你的部署场景。传输方式适用场景优点缺点stdio本地工具、桌面客户端零网络配置、启动快只能本地用、无法远程共享HTTP SSE云端服务、多用户可远程访问、支持并发需要处理鉴权、连接管理我的产品是云端服务所以选了 HTTP 传输。但如果你只是想让本地的 Cursor 或 Claude Desktop 调用一个本地脚本stdio 是最省事的方案——不需要端口、不需要鉴权、不需要处理断线重连。提示如果你选 HTTP 传输SSEServer-Sent Events连接的生命周期管理是最容易出问题的地方。代理端断线后不会自动清理服务端会话你需要自己实现超时回收机制。2.3 能力协商初始化握手时发生了什么MCP 连接建立时有一个初始化握手过程客户端和服务端互相声明自己支持的能力。这个阶段决定了后续能用什么功能。服务端在initialize响应里声明自己支持tools、resources、prompts中的哪些以及是否支持listChanged通知当工具列表变化时主动推送。我一开始忽略了这个握手的细节导致代理端一直报capability not supported。后来发现是我在响应里没有正确声明tools能力。这个坑很隐蔽因为协议本身不会给你明确的错误提示只是后续的tools/list请求会被拒绝。3. 从零实现一个带报价能力的 MCP server3.1 技术选型与项目骨架官方提供了 Python 和 TypeScript 两个 SDK。我选了 TypeScript 版本原因是我的产品后端本来就是 Node.js复用现有的业务逻辑最方便。如果你是从零开始Python SDK 的文档和示例更丰富一些社区讨论也更多。项目结构我建议这样组织mcp-server/ src/ index.ts # 入口传输层配置 server.ts # MCP server 实例和能力注册 tools/ clean.ts # 数据清洗 tool pricing.ts # 报价 tool lib/ auth.ts # 鉴权逻辑 rateLimit.ts # 限流 package.json tsconfig.json核心依赖就一个modelcontextprotocol/sdk不需要引入额外的框架。这个 SDK 的设计比较克制没有过度抽象直接照着文档写就行。3.2 定义 tool 的输入输出 Schema这是整个实现里最需要花心思的部分。AI 代理完全依赖你提供的描述和 Schema 来判断什么时候调用、怎么传参。描述写得不好代理要么不调用要么传错参数。我的数据清洗 tool 定义大概是这样{ name: clean_and_structure, description: 将杂乱的非结构化文本数据清洗并转换为标准 JSON 格式。适用于处理用户输入的地址、联系方式、订单信息等需要规范化的场景。, inputSchema: { type: object, properties: { raw_data: { type: string, description: 需要清洗的原始文本数据 }, target_format: { type: string, enum: [address, contact, order, custom], description: 目标结构化格式类型 }, custom_schema: { type: object, description: 当 target_format 为 custom 时指定自定义的字段结构 } }, required: [raw_data, target_format] } }这里有几个经验点值得展开。第一description要写清楚什么时候用而不只是这是什么。代理的决策逻辑是基于场景匹配的你告诉它适用场景它才能正确判断。第二enum类型比自由字符串好得多能大幅降低代理传错值的概率。第三可选参数要在描述里说明触发条件比如custom_schema只在特定target_format下才需要。3.3 报价 tool 的设计让代理自己做决策报价 tool 是整个 agent-to-agent commerce 的核心。它的设计思路和普通 tool 不太一样——它不是执行某个操作而是返回价格信息供代理决策。{ name: get_pricing, description: 获取数据清洗服务的实时报价。在调用 clean_and_structure 之前应先调用此工具确认价格以便向用户说明费用。, inputSchema: { type: object, properties: { operation: { type: string, enum: [clean_and_structure], description: 需要报价的操作类型 }, estimated_volume: { type: number, description: 预估处理的数据量字符数 } }, required: [operation] } }返回结构里我包含了单价、阶梯价格、以及一个currency字段。代理拿到这些信息后可以自主决定是否继续调用清洗 tool或者向用户报告价格等待确认。注意报价 tool 的描述里我特意写了在调用 clean_and_structure 之前应先调用此工具这是通过描述引导代理的调用顺序。MCP 协议本身没有强制调用顺序的机制只能靠描述来引导。3.4 鉴权与限流别让代理把你的服务打爆MCP server 暴露到公网后任何支持该协议的客户端都可能连接。如果没有鉴权你的服务很快会被滥用。我的方案是在 HTTP 传输层加一个 Bearer token 校验token 通过环境变量配置客户端连接时在 header 里带上。限流同样重要。AI 代理的调用频率可能远超人类用户——它可能在几秒内连续调用几十次。我用了基于内存的滑动窗口限流每个 token 每分钟最多 60 次调用。超过限制返回标准的 MCP 错误响应代理端会自己处理重试逻辑。这里有个细节限流错误不要直接断开连接而是返回一个带有明确错误码的响应。代理端看到错误码后可以选择等待重试如果直接断连代理可能会反复重连导致更严重的资源消耗。4. 调试与验证怎么确认代理真的能发现并调用4.1 用 MCP Inspector 做第一轮验证官方提供了一个叫 MCP Inspector 的调试工具可以在浏览器里直接连接你的 server查看暴露的 tools 列表手动触发调用检查返回结果。这是开发阶段最实用的工具比直接接 AI 客户端调试效率高得多。启动 Inspector 后填入你的 server 地址和鉴权 token它会自动完成初始化握手并列出所有可用 tools。如果握手失败或者 tools 列表为空问题一定出在能力声明或传输层配置上。我建议先用 stdio 模式在本地跑通确认 tool 定义没问题后再切到 HTTP 模式部署。4.2 在 Claude Desktop 和 Cursor 里实测Inspector 验证通过后下一步是在真实的 AI 客户端里测试。Claude Desktop 的配置方式是在配置文件里加上你的 server 地址{ mcpServers: { my-cleaner: { url: https://your-server.com/mcp, headers: { Authorization: Bearer YOUR_TOKEN } } } }Cursor 的配置类似在设置里找到 MCP 相关选项添加即可。配置完成后重启客户端然后在对话里用自然语言描述一个需要数据清洗的任务观察代理是否会主动调用你的 tool。我第一次测试时代理完全没有反应排查后发现是 tool 的 description 写得太技术化代理无法把它和用户的自然语言需求关联起来。把描述改成更贴近用户场景的表达后代理立刻就能正确识别并调用了。4.3 日志看清代理的每一次决策MCP server 端的日志是排查问题的关键。我建议至少记录以下几类信息连接建立和断开的时间戳、每次tools/list请求、每次tools/call的 tool 名称和参数、以及返回结果的摘要。但要注意日志里不要记录完整的用户数据尤其是涉及隐私的内容。我用了自定义的日志管理对敏感字段做脱敏处理只保留数据长度和结构信息用于调试。通过日志我发现了一个有意思的现象代理在调用清洗 tool 之前确实会先调用报价 tool而且会根据返回的价格信息调整后续行为。有一次测试中代理看到价格后主动向用户报告了预估费用并询问是否继续。这说明 agent-to-agent commerce 的链路是通的——代理不仅能发现服务还能基于价格做决策。5. 踩过的坑与实战经验5.1 描述质量决定一切这是我最深的体会。MCP server 的技术实现其实不难SDK 已经把协议细节封装得很好了。真正决定成败的是 tool 描述的质量。代理完全依赖描述来理解你的能力描述写得模糊代理就不会调用描述写得准确且场景化代理的调用准确率会大幅提升。我的经验是把描述当成写给一个聪明但完全不了解你产品的同事看。告诉他这个工具能做什么、什么时候该用、参数怎么填、会返回什么。不要假设代理应该知道任何背景信息。5.2 错误处理要区分类型MCP 协议定义了标准的错误码但实际使用中我发现代理对不同错误类型的反应差异很大。参数错误比如缺少必填字段代理通常能自己修正并重试服务端内部错误代理会放弃并告知用户限流错误代理会等待后重试。所以错误处理要分类参数问题返回明确的字段级错误信息帮助代理修正内部错误返回通用错误码避免泄露实现细节限流错误带上重试建议时间。5.3 版本兼容性问题MCP 协议还在快速演进不同客户端支持的协议版本可能不同。我在测试中发现 Claude Desktop 和 Cursor 对某些字段的处理方式有细微差异。解决方案是在初始化握手时正确声明自己支持的协议版本并对不同版本的客户端做兼容处理。提示如果你的 server 需要同时支持多个客户端建议在初始化阶段记录客户端声明的协议版本后续根据版本走不同的处理分支。5.4 报价策略的考量给 MCP server 加报价能力听起来很酷但定价策略需要仔细想。代理对价格的敏感度和人类用户不同——它不会因为看起来贵就犹豫但会因为性价比低而选择替代方案。我的策略是提供阶梯定价数据量越大单价越低这样代理在处理大批量任务时会优先选择我的服务。另外报价信息要尽可能结构化。除了价格数字我还返回了计费单位、最小计费量、以及是否有免费额度。这些信息帮助代理做更精确的成本估算。6. 这件事对独立开发者的意义写完这个 MCP server 之后我的产品多了一个全新的流量入口。虽然目前通过 AI 代理来的调用量还不大但增长趋势很明显。更重要的是这个入口的获客成本几乎为零——我不需要投广告不需要做 SEO只需要把能力按照标准协议暴露出去代理就会在需要的时候找到我。从更宏观的视角看agent-to-agent commerce 正在成为一个真实存在的渠道。当越来越多的用户习惯让 AI 代理帮他们完成任务时能被代理发现和调用的服务就会获得结构性优势。这就像早期做移动适配的网站——当时看起来是额外工作后来变成了标配。对于独立开发者来说现在切入的时机很好。MCP 协议的生态还在早期竞争不激烈而且实现成本很低——一个周末就能跑通基本流程。我的建议是先从你最核心的一个能力开始把它封装成一个 tool用 Inspector 验证通过后在 Claude Desktop 或 Cursor 里实测。跑通之后再逐步扩展报价、限流、多 tool 组合这些进阶能力。最后分享一个我在实际操作中的小技巧在 tool 的返回结果里加上一个next_steps字段用自然语言提示代理接下来可以做什么。比如清洗完成后返回如需将结果导出为特定格式可调用 export tool。这个字段不是协议要求的但代理会读取并参考它来做后续决策。实测下来加了next_steps之后代理的多步任务完成率有明显提升。