很多人搜「MCP和OpenAPI多少钱」，其实想问的是两件不同的事：接一个 MCP 服务器要不要额外付费，暴露一个 OpenAPI 接口又该怎么算成本。这两条路一条走协议、一条走 HTTP，收费口径完全不一样。这篇先把钱分清楚，再给一套从列清单到算账的步骤，最后说明什么情况下这套估算不成立。
很多人搜「MCP和OpenAPI多少钱」，其实混着两件事：接一个 MCP 服务器要不要额外掏钱，暴露一个 OpenAPI 接口又该怎么算成本。前者是协议层的事，后者是 HTTP 接口的事，收费口径完全不同。同一句「多少钱」问下去，答案能差出好几个量级。
所以别急着找报价单，先把钱分清楚。这篇给一套能直接套用的拆账方式和估算流程，最后说明哪几种情况下这套估算其实不成立。数字口径一律去站内页面核当时的数，别记在脑子里。
先把「多少钱」拆成三笔账
真实成本从来不是一张价格表。把 MCP 和 OpenAPI 放一起看，钱至少分成三笔：模型侧的 token、通道侧的调用通道、以及自己维护的人力。三笔账缺一笔，结论就会偏。
| 账目 | 钱花在哪 | 去哪核对 |
|---|---|---|
| 模型侧 | 工具调用结果最终喂回模型，按 token 计费；多轮工具往返会放大上下文 | 去 /tools/model-cost-calculator 代进去算 |
| 通道侧 | 官方直连、中转站、自建代理的计价口径不同 | 去 /official-api 看官方价目，去 /rankings 看中转站整体情况 |
| 人力侧 | 安装升级、权限管理、文档鉴权、版本兼容 | 按人天粗估，不进账单但真实存在 |
只盯第一笔最容易做错判断。很多团队算完“单次请求很便宜”就拍板，上线后才发现工具往返把上下文撑大、或者为了维护接口专门养了半个人。这两块不上账单，但一样要付。
- 先把三笔账各自列成一行，缺哪行补哪行；
- 模型侧按最坏情况多估一点，工具多的场景尤其别乐观；
- 通道侧别只比单价，还要看稳定性和可用性判断；
- 人力侧问一句：这件事半年后谁负责维护。
MCP 这一侧：协议免费，跑起来的地方不一定
MCP 是协议规范，本身不收费。花钱的是它背后连的服务：本地进程型的服务器基本只有机器成本，远程服务则看提供方怎么计价——自带额度、单独订阅、还是让你挂自己的模型 key，三种都不一样。
- 分清连接形态先确认要接的是本地 stdio 型还是远程 HTTP/SSE 型。本地型几乎只增加机器与配置成本，远程型要按提供方的计费方式单独看。
- 确认额度归属问清这个服务器的调用是消耗它自己的额度，还是走你自己的模型 key。走自己的 key 就意味着成本完全落回模型侧那笔账。
- 数工具数量和返回大小工具描述和工具返回都会进上下文。工具多的服务器会明显推高每次对话的 token 消耗，去 /ai-dict/category/basics 看计费口径，再对照自己的用法估。
- 先翻目录再动手选之前先去 /mcp 翻目录，能提前排除一批「接了才知道要额外付费」的试错。
判断一个 MCP 服务器贵不贵，看三件事：它连到哪、它的额度算谁的、它每次往上下文里塞多少字。
OpenAPI 这一侧：接口本身不贵，维护和调用量才贵
OpenAPI 描述文件只是契约，不产生费用。成本来自实现这个接口之后被调用多少次、每次背后调了几个模型、以及为了维持它要养多少人力。所以估算必须两头算：调用量和人头。
| 估算口径 | 怎么算 | 容易踩的坑 |
|---|---|---|
| 按调用量 | 日均请求数 × 平均每次请求的 token 数，再乘当前单价；数字去 /tools/model-cost-calculator 代入 | 用记忆里的老价格，忽略工具往返放大的上下文 |
| 按人力 | 鉴权、限流、错误码、版本演进，小团队维护一套对外接口通常占固定人力 | 只算首版开发，不算长期维护 |
| 按失败成本 | 重试、超时、降级带来重复调用 | 把理论请求量当成实际计费量 |
两种口径都要算。只算调用费的做法在小流量场景下会严重低估负担——接口再便宜，没人维护就是隐患；而只按人头算又容易忽略流量涨起来之后的账单。
- 先写清接口会被谁调用，是自家 AI 客户端还是外部系统；
- 把平均每次请求的工具往返次数估出来，别按单次算；
- 按当前单价代进计算器，不凭印象报价；
- 给维护人力一个固定的月度投入预期。
落到动作：一次可复用的四步估算法
上面拆完账，接下来是把账合成一个决定。按下面四步走，一轮下来就能得出「这版先选哪条路」，以及后面盯什么。
- 列清单把要用的能力写成「功能—数据源—调用频率」三列，再标出 MCP 和 OpenAPI 各自能覆盖哪些，重叠的部分先留空。
- 定性内部工具、数据在自己手里的，优先本地 MCP；要对外提供稳定契约、被非 AI 客户端调用的，优先 OpenAPI。定不出来说明清单还没列清。
- 定量模型侧用成本计算器，通道侧对照官方价目与中转站检测结论，人力侧按人天粗估，三者相加得出一个区间而不是一个数。
- 设观察点上线后定期回看用量与单价变动，到 /price-watch 看价格追踪、到 /usage 类页面看自己的消耗情况。价格和用量都不是常量，估算要能滚动更新。
四步里最容易跳过的是第四步。价格会变、用量会长，一次算准没有意义，能定期回看才有意义。所以第三步的产出最好是区间加一条触发线：涨到什么程度就重新评估。
什么情况下这套估算不适用
上面这套流程有前提：需求相对明确、用量大致可预测、团队自己能拍板。满足不了前提时，强行算出来的数字参考价值很低，甚至误导决策。
- 流量极不确定的探索期：任何按量估算误差都很大，这时该做的是设上限和熔断，而不是算准数；
- 合规或数据驻留要求高的场景：能不能用排在便宜前面，先过合规再谈钱；
- 已经深度绑定某个平台生态的团队：迁移成本远大于两条路线之间的差价，估出来的数只当参考；
- 需要跨团队长期协作的项目：人力成本会被组织协调放大，单纯的人天估算会偏小。
遇到这些情况，正确做法是把估算降级成「量级判断」：只要能判断出哪条路贵一个档位就够了，具体的账等条件明确再算。别为了填满一张表而硬凑数字。
下一步想马上动手，先去翻 MCP 目录确认要接的服务属于哪一类，再去成本计算器把调用量代进去；想知道价格随时间怎么动，就去价格追踪页回看。→常见问题
用 MCP 还要额外付钱吗？
协议本身不收费。花钱的是 MCP 服务背后的东西：本地运行的服务器基本只消耗你自己的机器和模型额度；远程托管的服务要看提供方是自带额度、单独订阅，还是让你填自己的 key。接之前先确认它属于哪一类。
OpenAPI 接口是按调用次数收费的吗？
OpenAPI 只是接口描述规范，本身没有价格。真正的费用来自接口背后的实现：每次调用触发了多少次模型请求、消耗多少 token。所以估成本要按「调用量 × 单次 token」来算，而不是按接口个数算。
两套都想要，成本会翻倍吗？
不一定。常见做法是用 MCP 做内部工具和数据接入，用 OpenAPI 对外暴露稳定接口，两者共用同一套模型调用，模型侧成本是叠加而非翻倍。真正翻倍的是维护面：两套都要有人管权限、管版本、管报错。
