MCP协议和API的区别

你在给一个Agent接外部能力时，大概率会卡在同一个岔路口：是直接调一个HTTP API，还是把能力做成MCP服务器挂上去？两者都能让模型用上外部功能，但请求在哪一层发起、鉴权归谁管、超时和并发谁来兜，完全是两回事。这篇不给结论式的「谁更好」，只讲清定位差异，再给一份判断流程和落地时要补的工程清单，让你少走一遍返工。

你在给Agent接外部能力时，大概率会卡在同一个岔路口：是直接调一个HTTP API，还是把能力做成MCP服务器挂上去？两者都能让模型用上外部功能，但请求在哪一层发起、鉴权归谁管、超时和并发谁来兜，完全是两回事。

这篇不给结论式的“谁更好”，只讲清定位差异，再给一份判断流程和落地时要补的工程清单。你可以拿它当一张对照表，动手前先过一遍，少走一次返工。

先分清「谁在调用」这件事

普通API是写在你代码里的：你的服务发请求、你的服务处理响应，模型只是被调用的一环。MCP是把一个能力暴露成工具，由模型侧的客户端去发现和调用，调用发起方变成了宿主程序。这个差别决定了后续所有的工程重心。

• 一个判断口径：这段逻辑的业务状态由谁维护？由你自己的后端维护，通常直接API更顺；由模型在对话里临时决定要不要用，MCP更自然。
• 不适用的情况：如果你的Agent只是一次性脚本、调用次数极少，专门起一个MCP服务器属于给自己加运维负担，直接包一层函数调用更省事。
• 再补一条：如果这个能力需要被多个不同客户端复用，MCP的“发现”机制比API的文档更直接。

能力的「描述方式」不一样

API需要你写文档、写SDK、写参数校验，使用方是人或者其他代码。MCP把工具名、参数结构、返回形态以约定格式暴露出来，客户端可以自动列出来给模型看。这带来一个实际差别：API的入参设计可以随意，MCP的工具参数要尽量扁平、字段名要能被模型读懂，否则模型很容易在参数上犯错。

需要补的活：参数类型不符、多包一层、必填缺失这几类报错在MCP里更常见。接之前先把参数结构收敛一遍，别把API那套嵌套对象直接搬过去。

传输与鉴权落在哪一层

API的鉴权在你手里：Key怎么存、走网关还是直连、要不要按调用方分配额度，都是你自己定。MCP的鉴权往往要跟着宿主客户端的配置走，凭证放哪、能不能被别的会话读到，是安全侧要先想清楚的。接之前先确认传输方式：本地进程方式和远程方式在部署、权限、排错步骤上完全不同，别到上线才发现环境跑不起来。

• 本地进程方式：适合单机调试，权限边界清晰，但多客户端共享时难管理。
• 远程方式：适合团队或产品化，但要额外处理网络、TLS、凭证分发。
• 在站内可以对照 /mcp 里的服务器条目，看看同类能力别人是怎么暴露接口的，再决定自己要不要照抄结构。

落地前必须补的工程动作

1. 超时与重试无论是API还是MCP，都要分开设连接、读取和整体超时，并约定重试次数；工具调用重试要确认动作是否幂等，否则一次超时会变成两次扣费。
2. 并发与排队按你的实际额度分档设置并发上限，超出就排队或降级，不要在模型侧并发调用多个工具时把额度打爆。
3. 降级路径工具不可用时要有一条“返回一句人话”的兜底，而不是把异常直接抛给模型让它瞎猜。
4. 日志与复盘至少记下工具名、入参摘要、耗时、结果状态和 token 用量，否则一次慢调用和一次贵调用事后完全没法复盘。
5. 验证顺序先用一个最小用例跑通“模型决定调用→参数正确→结果回填→回答成形”，再去做多工具编排。

这几条跟选API还是MCP无关，是两条路都得补的工程动作。区别在于：MCP多了一层客户端与服务器之间的约定，排查时你要先确定是模型没选对工具，还是参数传错了，还是服务器本身没起来。

什么时候选哪条路：一份判断清单

先把“优先直接API”和“优先MCP”的场景分开看，再决定你要不要为了可插拔多付一层复杂度。

• 优先直接API：能力是固定流程、调用时机由你的代码决定、需要复用已有的鉴权和监控体系。
• 优先MCP：多个客户端要复用同一批能力、需要让模型自己发现可用工具、团队里希望把能力做成可插拔的模块。
• 两边都可以：先按直接API实现核心逻辑，等确认这套能力会被多个Agent反复用到，再包一层MCP，避免一上来就过度设计。
• 判断会变：同一套能力在不同阶段答案可能不同，先跑通再重构，比一开始就选“终极方案”划算。

如果你还在犹豫，可以先到 /tools 看看同类工具在站内是怎么被归类的，再回到自己的场景里判断。