11.1 Tool Calling 已经很好了为什么还需要 MCP我们还是以一个例子作为开始。假设你开发了一个天气查询工具。(其实也是大多数兄弟tool calling的开始…)它提供一个简单的接口查询天气城市现在你希望它能够被不同的大模型使用。例如ChatGPTClaudeGeminiMinMaxQwen理论上它们都可以调用这个天气接口。但是现实却不是这样。每个平台都有自己的工具调用格式。例如以下仅为示意,不代表最新的交互协议ChatGPT↓Function Calling↓你的天气工具Claude↓Tool Use↓你的天气工具Gemini↓Function Declaration↓你的天气工具虽然最终调用的是同一个天气 API但每个平台都有自己的接口规范、参数格式和通信方式。于是一个非常尴尬的问题出现了。如果你想同时支持五个平台就需要分别适配五套接口。这就像我们前些年的手机充电器一样安卓一种接口苹果一种接口Micro USB 一种接口Type-C 又是一种接口。明明都是充电却没有统一标准。11.2 Tool Calling 的局限在哪里上一章我们提到Tool Calling 的本质是模型告诉程序“我需要调用这个工具。”例如{“tool”: “weather”,“city”: “北京”}程序收到之后会按下面的流程进行操作调用天气 API↓获得天气数据↓再交给 LLM整个流程没有任何问题。但是问题在于 Tool Calling 更像是模型厂商提供的一种能力而不是一种统一标准。例如OpenAI有自己的 Function Calling。Anthropic有自己的 Tool Use。Google有自己的 Function Declaration。不同平台之间Tool 定义不同参数格式不同返回格式不同通信方式不同。这意味着工具开发者需要不断重复开发适配层。11.3 MCP 想解决什么问题MCP 并没有发明一种新的工具,它只是定义了一套协议。它真正解决的是如何让工具只开发一次就能够被所有支持 MCP 的 AI 使用。可以把 MCP 理解成AI 与工具之间的一种通用语言。注意这里的语言并不是自然语言而是一套约定好的通信协议。只要Agent 能按照 MCP调用工具也能按照 MCP实现那么它们就可以互相通信而不需要关心对方是谁。11.4 MCP 是 AI 世界的 USB?还是举个例子.假设你买了一把无线鼠标。以前不同品牌都有自己的接收器。后来USB 成为了统一标准。于是无论罗技、雷蛇、戴尔、都可以直接插在你的电脑上。电脑并不需要知道,这是哪家公司生产的鼠标。因为 USB 已经规定好了通信方式。不过这里有一点需要特别强调。网上很多文章都会说MCP 是 AI 世界的 USB。这个比喻虽然便于理解但并不完全准确。USB 是一种硬件接口标准解决的是设备之间的物理连接问题。而 MCP 是一种应用层通信协议解决的是 AI 与工具之间如何交换能力、请求和结果的问题。因此更准确的类比应该是MCP 其实更像 HTTP协议或者数据库连接协议而不是 USB 接口。11.5 MCP 架构长什么样我们来看一张简化后的架构图。AI Agent │ ▼ MCP Client客户端 │ MCP 通信协议 │ ▼ MCP Server服务端 ┌────────┼────────┐ ▼ ▼ ▼ 浏览器 数据库 Git这里第一次出现了两个新的角色, MCP Client和MCP Server.最早,我们很容易混淆它们。但是,其实它们的职责其实非常明确。11.6 MCP Client 是什么Client其实就是主动发起请求的一方。它通常是LLM或者Agent,比如Claude DesktopOpenClawCursorClaude CodeCodex这些 AI 应用都可以充当 MCP Client。它们负责连接 MCP Server获取工具列表调用工具获取返回结果。可以理解为Client 等于使用工具的人。11.7 MCP Server 是什么Server 则相反。它负责提供能力。比如,一个 Git MCP Server。它可以提供查看 Commit创建 Branch提交代码。一个数据库 MCP Server。它可以提供查询数据修改数据执行 SQL。一个浏览器 MCP Server。它可以提供打开网页点击按钮获取页面内容。所以Server则是提供工具能力的一方。一个 Server 可以提供多个 Tool而一个 Client 也可以同时连接多个 Server。11.8 MCP 的一次完整调用流程简单了解了 MCP 的整体架构之后我们再来看一次真实的调用过程。很多人第一次接触 MCP 时会有一种误解是不是 Claude 或 ChatGPT 直接调用了我的 C# 方法实际上并不是。整个调用过程始终遵循模型负责决策程序负责执行的原则。下面以一个天气查询工具为例看看一次完整的 MCP 调用过程。假设我们开发了一个 MCP Server其中提供了一个查询天气的 ToolQueryWeather(city)用户向 AI 提出问题武汉今天的天气怎么样整个系统会经历下面几个步骤。┌──────────────────────────────────────────┐│ 用户输入 ││ “武汉今天的天气怎么样” │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ LLM 分析用户意图 ││ 判断需要调用 QueryWeather Tool │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ MCP Client ││ 向 MCP Server 发送 tools/call 请求 │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ MCP Server ││ 执行 QueryWeather(“武汉”) │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ 返回结果 ││ 晴天30℃东南风三级 │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ LLM 根据工具结果组织自然语言 │└──────────────────┬───────────────────────┘│▼回复最终答案整个过程中大模型始终没有直接执行任何代码。它只完成了两件事情判断是否需要调用工具根据工具返回的数据生成最终回复。真正执行查询天气的是 MCP Server。因此可以说MCP 负责连接工具LLM 负责理解语言两者各司其职。MCP 初始化过程很多兄弟可能还会有一个疑问LLM 是怎么知道有哪些 Tool 可以调用的答案其实就在 MCP 的初始化过程中。当 Client 第一次连接 MCP Server 时就会自动获取 Server 所提供的能力。整个过程可以简化为下面几个步骤Client││ initialize▼Server││ 返回协议版本、Server 信息▼Client││ tools/list▼Server│├── QueryWeather├── SearchOrder├── GetInventory└── GenerateReport完成这一步之后其实这些能力就已经在LLM的上下文对话中了,这时候LLM 就已经知道当前有哪些 Tool 可以使用。之后当用户提出问题时模型会根据 Tool 的名称、说明以及参数定义自主决定是否调用某个 Tool。整个过程并不需要开发人员编写任何如果用户问天气就调用天气接口这样的业务代码。这也是 MCP 与传统 API 最大的不同之处。11.9 使用 .NET 开发一个简单的 MCP Server理解了 MCP 的工作原理之后我们再来看一个最简单的 .NET 示例。对于 .NET 开发者来说一个好消息是目前已经有官方的 MCP C# SDK开发者无需自己实现 JSON-RPC 协议、Tool 注册或通信逻辑只需要关注业务代码即可。目前推荐使用 ModelContextProtocol 官方 C# SDK它由 Anthropic 与 Microsoft 共同推动维护是 MCP 官方组织提供的 .NET 实现也是目前 .NET 平台开发 MCP 应用的推荐方案。官方地址GitHubmodelcontextprotocol/csharp-sdk官方文档https://modelcontextprotocol.io/API 文档https://csharp.sdk.modelcontextprotocol.io/整个 SDK 已经与 Microsoft.Extensions.DependencyInjection、Microsoft.Extensions.Hosting 等 .NET 基础设施深度集成因此开发体验与 ASP.NET Core 十分相似。对于绝大多数项目只需要安装下面这两个 NuGet 包即可dotnet add package ModelContextProtocoldotnet add package Microsoft.Extensions.Hosting安装完成之后就可以开始开发自己的 MCP Server。第一步注册 MCP ServerProgram.cs复制代码using Microsoft.Extensions.DependencyInjection;using Microsoft.Extensions.Hosting;using ModelContextProtocol.Server;var builder Host.CreateApplicationBuilder(args);builder.Services.AddMcpServer().WithStdioServerTransport().WithToolsFromAssembly();await builder.Build().RunAsync();复制代码这段代码与 ASP.NET Core 十分相似。整个 MCP Server 可以理解成一个普通的 Host 应用。其中几个扩展方法分别承担不同职责方法 作用AddMcpServer() 注册 MCP Server 服务。WithStdioServerTransport() 使用 STDIO标准输入/输出作为通信方式适用于 Claude Desktop、OpenClaw、Claude Code 等本地 Agent。WithToolsFromAssembly() 自动扫描程序集中的 Tool并完成注册无需手工维护 Tool 列表。可以看到开发者几乎不用关心 MCP 协议本身而是通过 SDK 提供的扩展方法快速完成整个 Server 的初始化。第二步编写一个 Tool完成 Server 注册之后只需要编写一个普通的 C# 方法即可将其暴露给 AI Agent 调用。下面我们定义一个最简单的天气查询工具复制代码using ModelContextProtocol.Server;[McpServerToolType]public class WeatherTool{[McpServerTool, Description(“查询各地区天气,可以调用这个接口”)]public string QueryWeather(string city){return $“{city}晴天30℃”;}}复制代码对于开发者来说一个 MCP Tool 本质上就是一个普通的方法。SDK 会自动完成下面一系列操作Tool 注册参数解析JSON 序列化MCP 协议通信返回结果封装。开发者只需要关注业务逻辑而无需处理协议细节。MCP Tool 的调用过程假设用户在 Claude Desktop 中输入武汉今天的天气怎么样整个调用过程如下图所示Claude Desktop│▼LLM 判断需要调用 QueryWeather│▼MCP Client│▼MCP Server│▼WeatherTool.QueryWeather(“武汉”)│▼返回“武汉晴天30℃”│▼LLM 根据结果组织自然语言│▼回复用户整个过程中大模型始终没有直接执行任何 C# 代码。真正执行代码的是 MCP Server。LLM 负责理解用户意图并决定何时调用 ToolMCP Server 负责完成具体业务逻辑两者共同协作完成一次完整的任务。知识拓展MCP SDK 与 Semantic Kernel 是什么关系很多 .NET 开发者第一次接触 MCP 时都会问既然已经有 Semantic Kernel为什么还需要 MCP SDK实际上两者并不是竞争关系而是位于不同层次。技术 主要职责Semantic Kernel AI 应用开发框架负责 Prompt、Chat、Memory、Planner、Workflow 等 AI 能力编排。Microsoft.Extensions.AI 对不同大模型提供统一抽象屏蔽 OpenAI、Azure OpenAI、Ollama 等模型接口差异。ModelContextProtocol C# SDK 实现 MCP 协议负责 AI Agent 与 MCP Server 之间的通信。它们之间的关系可以理解为Semantic Kernel │ ▼ Microsoft.Extensions.AI │ ▼ModelContextProtocol C# SDK│▼MCP Server│▼企业系统 / 数据库 / Web API三者分别解决不同层次的问题Semantic Kernel 负责组织 AI 的工作流程Microsoft.Extensions.AI 负责统一模型调用接口MCP SDK 则负责让 AI 能够安全、标准地访问外部工具和企业系统。因此在企业级 AI 应用中这三者往往是协同工作的而不是相互替代。11.10 为什么越来越多Agent产品开始支持 MCP因为对于产品平台来说它解决了一个长期存在的问题过去每接入一种工具都要做一次适配。现在只要工具实现了 MCP Server平台实现了 MCP Client它们就可以按照统一协议进行通信。这意味着工具开发者只需要维护一套接口AI 平台可以快速接入大量已有工具企业内部也可以把自己的系统封装成 MCP Server对外提供能力。因此MCP 的价值不仅在于方便开发更在于降低生态之间的连接成本。11.11 以 OpenClaw 为例以今年以来比较火的 OpenClaw 为例它本身并不会直接内置所有工具。相反它可以作为一个 MCP Client连接多个 MCP Server。例如OpenClaw│├──────── 文件系统 MCP Server│├──────── Git MCP Server│├──────── PostgreSQL MCP Server│├──────── Browser MCP Server│└──────── 企业内部 ERP MCP Server对于 OpenClaw 来说它并不需要知道这些工具是谁开发的只需要知道它们都遵循 MCP 协议。这样当模型需要某种能力时就可以通过 MCP 调用对应的工具。这也是为什么近一年来越来越多 Agent 框架开始支持 MCP。本章总结这一章我们回答了四个问题为什么 Tool Calling 还不够因为各个平台都有自己的工具调用方式生态彼此割裂。MCP 想解决什么问题为 AI 与工具之间建立一套统一的通信协议。MCP Client 和 MCP Server 分别是什么Client 发起调用Server 提供能力它们通过 MCP 协议进行通信。