MCP 和普通 API 有什么区别？

写在前面MCP 不是来取代 API 的很多人第一次听 MCP会问这不就是 API 吗这个问题很正常。因为 MCP Server 最后也会暴露能力AI 应用也会发请求工具也会返回结果。看起来和普通 API 没区别。但如果只把 MCP 理解成“另一种 API”就会漏掉重点。普通 API 主要是给确定性的程序调用。MCP 更像是给 AI 应用和 Agent 使用的工具协议。差别不在“能不能传 JSON”而在这些问题工具怎么被发现 参数怎么描述给模型 上下文怎么提供 权限怎么暴露 错误怎么反馈 一个 AI 客户端怎么接很多工具 一个工具怎么被很多 AI 客户端复用。普通 API 的典型思路传统 API 通常是人和程序一起设计好的。比如一个订单查询接口GET /api/orders/{orderId}开发者知道这个接口干什么 需要传什么参数 返回什么字段 错误码什么意思 什么时候调用它。业务代码也是确定的用户点按钮 前端发请求 后端查数据库 返回订单数据 页面展示。这套模式非常成熟也非常必要。普通 API 的核心假设是调用方是确定程序 调用路径由开发者写死 什么时候调、怎么调提前设计好。MCP 的典型思路MCP 面向的是另一种场景。用户给 AI 一个目标帮我看一下这个订单为什么没有发货。AI 需要自己判断要不要查订单 要不要查物流 要不要查库存 要不要查客服工单 查完怎么汇总给用户。这时候AI 客户端需要知道它有哪些工具可用每个工具能做什么参数是什么返回结果怎么理解。MCP 就是在这层提供标准化方式。它不是简单替代GET /api/orders/{id}而是把“订单查询”包装成一个 AI 可发现、可描述、可调用的工具。核心区别一API 面向程序MCP 面向模型上下文普通 API 文档主要给开发者看。MCP 的工具描述还要给模型看。这就要求工具描述不能只写queryOrder(orderId: string)它还要清楚表达这个工具用于查询订单基本信息 适合在用户询问订单状态、发货情况、支付状态时调用 orderId 必须是系统订单号 不要用手机号或用户名作为 orderId 如果订单不存在会返回 not_found。为什么要写这么细因为模型会根据这些描述选择工具。描述写得含糊模型就容易选错。普通 API 的坏文档最多让开发者骂两句。MCP 工具的坏描述可能直接导致 Agent 调错工具。核心区别二MCP 有工具发现机制普通 API 通常需要开发者提前知道接口地址和文档。MCP 更强调“客户端可以发现服务端提供了什么能力”。一个 MCP Server 可以告诉 AI 客户端我有这些 tools 我有这些 resources 我有这些 prompt 模板 每个工具需要这些参数 每个资源可以这样读取。这对 AI 应用很重要。因为 AI 客户端不是只接一个固定后端它可能同时接文件系统 GitHub 数据库 浏览器 内部工单 监控系统。如果每个都用不同方式描述AI 客户端会非常难做。MCP 提供的是统一发现和调用的外壳。核心区别三MCP 更重视上下文普通 API 主要处理业务数据读写。MCP 除了 tools还有 resources。Resources 可以理解成“模型可以读取的上下文材料”。比如当前项目 README 数据库 schema 某个文件内容 当前浏览器页面 服务配置 日志片段。这些东西不一定是“执行动作”但它们能帮助模型理解任务。这也是 MCP 名字里 Context 的意义它不只是调用工具还要给模型提供上下文。核心区别四MCP 更适合多客户端复用假设你公司做了一个内部知识库 API。如果要接入三个 AI 客户端内部网页助手 IDE 编程助手 桌面 Agent。传统方式可能每个客户端都要适配一遍。如果把内部知识库封装成 MCP Server理论上这些客户端只要支持 MCP就能以相对统一的方式接入。这就是 MCP 的复用价值。它不是让底层业务 API 消失而是在业务 API 上面加了一层 AI 工具适配层。可以这样理解数据库 / 内部系统 / 第三方服务 ↓ 普通业务 API ↓ MCP Server ↓ AI 客户端 / Agent核心区别五MCP 更关注工具边界和安全提示普通 API 安全靠鉴权、权限、校验、审计。MCP 也需要这些而且还多了模型使用层面的风险。比如一个工具叫deleteProject(projectId)对普通程序来说只要权限校验严格调用路径可控风险还能管理。但对 Agent 来说模型可能误判用户意图或者把错误 ID 传进去。所以 MCP 工具设计时要额外考虑危险工具是否默认隐藏 是否需要人工确认 工具描述是否提醒副作用 参数是否强校验 是否支持 dry-run 是否有回滚 是否记录完整日志。MCP 不是安全本身但它让这些边界有机会以统一方式暴露给 AI 客户端。一个具体对比查询数据库普通 API 方式开发者写一个 /users/{id}/orders 接口 前端在用户点击时调用 后端返回订单列表。MCP 方式MCP Server 提供 query_user_orders 工具 工具描述说明什么时候用、参数是什么、限制是什么 AI 客户端发现这个工具 用户自然语言提问 模型判断需要调用工具 工具返回结果 模型总结给用户。差别在于普通 API 的调用路径由开发者写死。MCP 工具的调用时机可能由模型根据用户目标动态决定。这就是为什么 MCP 工具描述、权限和校验很重要。MCP 什么时候比普通 API 更合适这些场景适合 MCP要把工具接给 AI 助手 要让 Agent 自己选择工具 多个 AI 客户端复用同一批工具 需要暴露文件、数据库、网页、GitHub 等上下文 希望工具能力能被模型理解和发现。这些场景普通 API 就够了固定业务流程 前端按钮触发后端逻辑 服务之间稳定调用 高并发核心交易链路 不需要模型动态选择工具。不要为了追新把所有 API 都改成 MCP。大多数业务系统仍然应该用普通 API。MCP 更像是 AI 应用接入这些系统的一层适配。一个常见架构比较合理的做法是底层系统继续提供稳定 API MCP Server 调用这些 API MCP Server 把能力包装成适合 AI 的 tools 和 resources AI 客户端通过 MCP 使用这些能力。这样既不破坏原有系统也能让 AI 应用复用已有能力。MCP、API、插件、函数调用怎么区分这些概念经常混在一起最好放在一张表里看。概念主要面向谁解决什么普通 API程序和开发者业务系统之间稳定调用函数调用单个模型应用让模型按 schema 调用函数插件某个平台用户给特定产品扩展能力MCP多个 AI 客户端和工具标准化工具和上下文接入RPAUI 自动化流程模拟人操作软件界面MCP 和函数调用最容易混淆。函数调用更像模型厂商或应用内部的一种能力开发者告诉模型有哪些函数模型选择调用。MCP 更像外部工具服务的协议工具可以独立运行被不同 AI 客户端发现和使用。可以这样理解函数调用是模型应用内部怎么调工具 MCP 是工具怎么以标准方式暴露给 AI 应用。两者可以同时存在。一个 AI 客户端可以通过 MCP 发现工具再把这些工具包装成模型可调用函数。普通 API 仍然是底座不要因为 MCP 火了就觉得普通 API 过时了。大多数业务系统仍然应该优先设计稳定 API权限 数据模型 事务 幂等 错误码 审计 性能 版本兼容。MCP 通常是在这些能力上再包一层。比如订单系统已经有GET /orders/{id} POST /orders/{id}/cancel GET /shipments/{id}MCP Server 可以把它们包装成query_order_status explain_shipping_delay draft_cancel_order_action。注意这里第三个最好叫 draft而不是直接 cancel。因为对 Agent 来说取消订单是高风险动作应该让用户确认。MCP 工具设计的分类设计 MCP 工具时不要机械地把每个 API endpoint 映射成一个工具。更好的做法是按 AI 使用场景设计。1. 查询型工具只读返回事实。查询订单状态 读取文件 获取 issue 列表 查询数据库 schema。这类工具适合先开放。2. 分析型工具对数据做加工但不产生外部副作用。统计日志错误 汇总 PR 变更 比较两份配置 生成报表摘要。这类工具适合把复杂逻辑放在服务端减少模型瞎算。3. 草稿型工具生成待确认内容。生成邮件草稿 生成 SQL 草稿 生成工单内容 生成部署计划。草稿型工具很适合 AI因为它把风险留给人工确认。4. 执行型工具会改变外部状态。创建 issue 发送消息 更新记录 触发部署。必须做权限、确认、日志和回滚。5. 危险型工具不可逆或影响生产。删除数据 关闭服务 修改权限 执行生产 SQL。这类工具默认不该直接暴露给模型除非有非常强的审批系统。MCP 工具描述应该怎么写普通 API 文档可以写得偏技术参数 orderId: string 返回 Order 错误码 404。MCP 工具描述还要告诉模型什么时候应该用 什么时候不应该用 参数从哪里来 返回结果怎么解释 失败时下一步该怎么办 有没有副作用。一个坏描述update_user: update user.一个更好的描述用于更新用户的非敏感资料例如昵称和头像。 不要用于修改角色、权限、邮箱或密码。 调用前必须确认 userId 来自系统用户 ID而不是用户名。 该工具会改变数据库记录。模型不是人类后端工程师。你不把边界写清楚它就可能按字面猜。什么时候不该用 MCP这些场景不用急着 MCP 化固定前后端业务流程 高并发核心交易 对延迟极敏感的链路 不需要模型动态选择工具 安全边界还没设计清楚 只是为了追热点。MCP 增加了一层抽象。抽象有价值但也有成本。如果一个按钮点击后固定调用一个 API就让它继续调用 API。没必要绕一圈 MCP。MCP 更适合“用户用自然语言提出目标模型需要自己选择工具”的场景。团队落地建议一个团队如果已经有很多内部 API可以这样做第一步选 3 个只读 API 包成 MCP 工具 第二步接入一个内部 AI 客户端试用 第三步观察模型是否选对工具 第四步补工具描述和参数校验 第五步再考虑草稿型写操作 第六步高风险写操作保持人工审批。不要一开始就把所有 API 批量转成 MCP。工具太多模型反而更容易选错。最终结论MCP 和普通 API 的关系不是替代而是分工。普通 API 解决的是程序和程序之间如何稳定调用。MCP 解决的是AI 应用如何发现、理解、调用外部工具和上下文。如果你是后端开发者可以这样记API 是能力本身 MCP 是把能力交给 AI 使用的协议层。不要把 MCP 神化。它不会让模型自动可靠也不会替你做权限和业务校验。但如果你的目标是让 AI 助手安全、标准、可复用地连接文件、数据库、内部系统和第三方工具MCP 就值得认真看。