上次我们构建了一个MCP服务器，用C#编写，并把它接入Claude Desktop和Claude Code。这两者都是别人的应用——你编写了工具，交付出去，然后某个不是你写的客户端拿走了全部好处。 这是故事的另一半：当你的.NET应用需要这些工具时，会发生什么？不是Claude Desktop——而是你内部的客服控制台、你的worker服务、你的CLI。本文从客户端视角出发，连接上一篇文章中的Aurora Coffee Co.服务器，并在一个令人满意的节点收尾：我们在工具使用一文中手工编写的代理循环——大约60行——被压缩到了3行。 客户端协议只有三个动词： - **连接**——通过某种传输方式。要么将服务器作为子进程启动（stdio），要么指向一个URL（HTTP）。 - **发现**——询问服务器它提供什么。工具及其输入模式以数据形式返回，没有什么是编译进去的。 - **调用**——按名称和参数集调用工具，并接收内容返回。 值得在第三步上多停留片刻，因为这正是工具使用一文中安全边界从相反角度呈现的同一道界线。过去，你的代码掌握执行权，而Claude只能提出请求。现在，提出请求的变成了你，执行权则掌握在服务器手中。你发送一个名称和参数，真正执行的内容由服务器单方面决定。 发现这一步，是它与简单调用API客户端的本质区别。你面对的不是一份带有GetOrderStatus(string)之类的生成代理类，而是一组在运行时到达的工具列表，代码必须适应这种开放性。 连接Aurora服务器时，启动一个控制台应用，添加SDK，指向Aurora Coffee Co.服务器，然后执行客户端协议：连接、发现、调用。工具描述通过传输层抵达，你的代码遍历这些工具，在必要时等待用户审批，再调用所需功能。 最终结果：曾经需要手写的约60行代理循环——解析工具调用、构建参数、调度执行、返回结果——现在由MCP客户端SDK接管，你的逻辑被压缩到三行。这就是当你的应用成为客户端时，MCP能带来的变化。
热门跟贴