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 协议进行通信。