当用户让 AI "查询订单并退款"、"读取仓库后修复测试"时，模型需要的不只是生成一段文字，还需要请求外部系统执行动作。这里会同时出现 Tool Calling 和 MCP，但它们解决的不是同一个问题。

Tool Calling 是模型与宿主应用之间的调用约定：模型选择工具，并生成结构化参数。MCP 是宿主应用与工具服务之间的开放协议：客户端发现、调用并管理这些工具。

先区分两个层次

概念 解决的问题 主要参与者
Tool Calling / Function Calling 模型该选哪个工具，传什么参数 LLM 与宿主应用
MCP 工具如何被发现、描述和远程调用 MCP Client 与 MCP Server

Tool Calling 并不要求 MCP。最简单的做法是：应用把一个本地函数的 JSON Schema 直接传给模型，模型返回函数名和参数，应用在进程内执行这个函数。

MCP 也不等于 Tool Calling。MCP Server 除了 tools，还可以暴露 resources 和 prompts。是否把一个 MCP 工具交给模型选择，仍然由宿主应用决定；宿主也可以根据固定业务流程直接调用它。

四个角色与完整链路

一次通过 MCP 使用工具的典型链路如下：

用户
  -> 宿主应用（Agent / IDE / 聊天应用）
       -> MCP Client --MCP--> MCP Server
            发现 tools、resources、prompts
       -> LLM
            获得宿主筛选后的工具定义

LLM --结构化 tool call--> 宿主应用
宿主应用 -> MCP Client --MCP tools/call--> MCP Server
MCP Server --结构化结果--> 宿主应用 -> LLM -> 最终回答

关键点是：模型通常不直接连接 MCP Server。 宿主应用同时承担 MCP Client 和执行编排者的职责：它连接服务端、获取能力、控制权限，并把适合当前任务的工具描述提供给模型。

Tool Calling：模型提出调用请求

Tool Calling 中，工具需要先以可机器读取的 Schema 告诉模型。例如，宿主应用可以向模型提供一个搜索订单的工具：

{
  "name": "find_orders",
  "description": "按用户 ID 和时间范围查询订单，仅返回订单摘要。",
  "parameters": {
    "type": "object",
    "properties": {
      "user_id": { "type": "string" },
      "from": { "type": "string", "description": "ISO 8601 日期" },
      "to": { "type": "string", "description": "ISO 8601 日期" }
    },
    "required": ["user_id"]
  }
}

模型决定需要查询时，返回的是一个待执行请求，而不是执行结果：

{
  "name": "find_orders",
  "arguments": {
    "user_id": "u_123",
    "from": "2026-08-01",
    "to": "2026-08-05"
  }
}

宿主应用必须验证工具名和参数、执行调用，并把结果以 tool result 的形式放回对话。模型再基于真实结果组织答案。模型生成的参数始终是不可信输入，不能直接拿去执行 SQL、Shell 或写操作。

MCP：把工具服务变成可连接的能力

如果 find_orders 来自一个 MCP Server，宿主不需要为每个工具手写私有 SDK 或协议适配。MCP Client 在初始化连接后可以列出该服务公开的工具，得到名称、说明和输入 Schema；随后以协议中的 tools/call 调用选中的工具。

1. MCP Client 连接订单 MCP Server
2. Client 获取工具列表和每个工具的 inputSchema
3. 宿主按用户权限、当前任务和风险策略筛选工具
4. 宿主将筛选后的 Schema 交给支持 Tool Calling 的模型
5. 模型请求 find_orders
6. 宿主经 MCP Client 调用 tools/call(name, arguments)
7. Server 返回结构化内容或错误，宿主再交回模型

因此，MCP 的价值不是让模型“突然会调用工具”，而是让工具提供方和 AI 应用之间有一套可复用的连接方式。一个 Server 可被多个支持 MCP 的宿主连接；一个宿主也可以统一接入文件、数据库、CMS、代码仓库等不同服务。

两者怎样配合

阶段 Tool Calling 的职责 MCP 的职责
工具定义 为模型提供名称、用途与参数约束 Server 对外发布工具及其 Schema
工具选择 模型根据用户意图产生调用请求 不参与模型推理与选择
参数校验 宿主校验模型产生的参数 Server 继续校验请求和业务权限
工具执行 宿主决定是否执行、何时执行 Client 与 Server 完成协议调用
结果处理 宿主将结果回传模型继续生成 Server 返回内容、错误或资源引用

MCP 工具的 Schema 往往可以映射为模型 Tool Calling 的 Schema，但这不是机械地全量透传。一个连接到生产环境的 MCP Server 可能暴露几十个工具，宿主应该只向模型暴露当前任务需要、当前用户有权限使用的那一小部分。

工程上最容易遗漏的边界

不要把工具返回内容当作指令

网页、文档、数据库字段和工具错误信息都属于外部不可信数据。它们可以作为模型分析的材料，但不能改变系统提示、权限策略或确认规则。宿主应明确区分“数据”和“控制指令”。

把读取与副作用操作分级

查询订单和执行退款的风险完全不同。对写数据库、删除文件、发送消息、发布内容等操作，应至少做到：

  • 使用最小权限的服务凭据；
  • 校验参数的类型、范围和目标归属；
  • 在执行前展示清晰的操作摘要并要求用户确认；
  • 保存可追踪的审计记录，并为失败提供安全的重试或补偿策略。

控制结果大小与调用次数

工具结果过大时会挤占模型上下文，也会增加泄露敏感信息的风险。工具接口应支持分页、字段白名单和摘要返回；宿主还应限制单轮及整个任务的调用次数、超时时间和预算。

处理失败，而不是伪造成功

调用超时、参数不合法、权限不足时，返回可供模型理解的结构化错误，并由宿主决定是否重试、改用只读降级路径或请求用户补充信息。不要让模型猜测工具执行结果。

何时需要 MCP，何时只用本地函数

本地函数适合工具数量很少、与单一应用强绑定、无需跨进程或跨产品复用的场景，例如在一个后端服务里调用内部的汇率计算函数。

当工具由独立团队维护，或者希望被 IDE、桌面客户端、Agent 平台等多个宿主复用时，MCP 更合适。它减少的是集成层的重复工作，但不替代模型选择、权限控制、确认交互和业务审计。

总结

Tool Calling 让模型能够提出“请调用这个工具，并传入这些参数”；MCP 让宿主能够以统一方式找到并调用工具服务。安全和最终执行权始终属于宿主应用，而不属于模型。