北京
上一次，我们用 C# 构建了一个 MCP 服务器，并将其接入 Claude Desktop 和 Claude Code。但这两者都是别人的应用——你编写了工具，交付出去，然后一个并非你编写的客户端享受了全部好处。
本文讲述故事的另一半：当你的 .NET 应用成为需要这些工具的一方时，会发生什么？不是 Claude Desktop，而是你的内部支持控制台、你的工作进程服务、你的命令行工具。本文将编写客户端一侧，把它连接到上次同一个 Aurora Coffee Co. 服务器，并在一个令人满意的节点收尾：此前工具调用文章中手工编写的代理循环——约六十行代码——压缩到了三行。
协议的客户端一侧
服务器端文章讨论的是暴露能力。客户端文章则是镜像视角，核心只有三个动词：
Connect（连接）——通过一种传输方式。要么将服务器作为子进程启动（stdio），要么指向一个 URL（HTTP）。
Discover（发现）——向服务器询问它有什么。工具及其输入模式以数据形式返回，没有任何内容是编译进去的。
Call（调用）——通过名称和一组参数调用工具，并取回内容。
第三步值得停下来细想，因为它与工具调用文章中的安全边界是同一件事，只是从相反方向观察。当时，你的代码拥有执行权，Claude 只能请求。现在，你变成了请求方，服务器拥有执行权。你发送名称和参数，实际运行的内容完全由服务器决定。
发现这一步是它与普通 API 客户端的本质区别。你没有一个带有 GetOrderStatus(string) 方法的生成代理类，你得到的是一份在运行时到达的工具列表，以及必须接受这一点的代码。
连接 Aurora 服务器
创建一个控制台应用并添加 SDK。如果希望依赖最少，客户端位于 ModelContextProtocol.Core 中；如果同一应用还需要托管服务器，则使用完整的 ModelContextProtocol 包：
dotnet new 命令创建项目后，下一步便是通过 StdioClientTransport 或 HttpClientTransport 建立传输通道，随后调用 ListTools 获取工具清单，再通过 CallTool 按名称执行调用——整个客户端的核心逻辑就此完成。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
