从“打电话”到“请秘书”：MCP 把 API 设计带进了下一个时代

MCP出来后，经常有人在说，MCP不就是个API吗？
是的，没错，MCP是个API，正如西安的拉条子、蘸水面、biangbiang面、油泼面都是面。
很明显，不能简单这么归类。

01 一个生活化的比喻

想象你要订一张机票：

传统 API：你拿起电话，按照一长串语音提示按 1-3-2-4，报出身份证号、航班号、信用卡号……

MCP：你有一位 7×24 的专属秘书。你只要说：“帮我订明天下午去上海的最便宜的航班，用公司协议价。”秘书自己查库存、比价、填表、扣款，最后把登机牌递到你手上。

前者是“人机接口”——你得按机器的规则来；
后者是“机人接口”——机器按你的意图来；

02 一张表格看懂差异

03 从“写代码”到“写提示词”

传统 API 时代，开发者在 Postman / Postwomen 里调通接口，测试API接口是否生效。
MCP 时代，开发者在提示词（Prompt）里“调通”接口：

你是一个差旅助手，工具箱里有：
- search_flights
- company_discount_policy
- submit_order
用户说：“下周二我要去深圳出差，尽量便宜。”
请自主决定调用顺序，并在必要时反问用户补充信息。

模型自己会：
search_flights(date=“next_tuesday”, destination=“深圳”, sort=“price”)
company_discount_policy() → 发现公司有XX航空 9 折协议
submit_order(…) → 返回确认号

04 为什么 MCP 不是“又一个 API 网关”？

语义层：MCP 把“函数签名”升级为“语义描述”，让模型理解“这个工具能干什么”，而不是“这个接口有哪些字段”。

动态组合：一次用户请求可能串起 5~10 个工具，传统 API 需要 5~10 次网络往返；MCP 让模型在本地规划、批量调用，减少 70%+ 延迟。

自我修复：模型收到 400 / 500 错误时，可以自动换参数、换工具，甚至向用户澄清需求——传统 API 直接抛异常，只能程序员救火。

05 MCP落地的3个建议

1. 可以把现有 REST 服务包装成 MCP Tool，但是不仅仅是包装
   用 JSON Schema 描述函数语义，让模型更好的理解你的MCP Tool。

2. 优先暴露“高阶意图”工具
   不是 /getUser + /getOrder，而是 /whatIsTheUsersLatestOrder, 让模型少推理、少调用。

3. 建立“能力目录”而非“接口目录”
   用标签体系（tag=财务、tag=合规、tag=销售）管理数百个工具，方便模型检索。

06 结语：API 的下一站是“消失”

如果说 REST 让“数据”成为网络上的公民，那么 MCP 正在让“能力”成为智能体的母语。

未来我们不再调用 API，而是告诉智能体“帮我搞定”；
而 API，会像汇编语言一样——存在，但不必天天看见。