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 应用的推荐方案。
官方地址：
GitHub：modelcontextprotocol/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 ModelContextProtocol
dotnet add package Microsoft.Extensions.Hosting
安装完成之后，就可以开始开发自己的 MCP Server。
第一步：注册 MCP Server
Program.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 负责理解用户意图，并决定何时调用 Tool；MCP 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 协议进行通信。