如果你最近总听到 MCP（Model Context Protocol，模型上下文协议）却不确定它对 C# 和 .NET 开发者意味着什么，一句话概括：MCP 是一套让 AI 应用连接外部工具、数据和可复用工作流的标准做法。它给主机、客户端、服务器一个共享契约，让 AI 系统去发现能力，而不是每个应用各自造一次性集成。
听起来抽象，但如果你做过 API、后台服务、依赖注入、认证或集成密集的系统，MCP 的形状会很眼熟。它的价值不在于让 AI 变得神奇地安全、聪明或可上生产，而在于给我们一条统一边界，把能力以可发现、可一致调用的方式暴露给 AI 应用。对 .NET 开发者来说，MCP 与其说是全新编程模型，不如说是又一个我们能推理的集成协议。
MCP 到底是什么
MCP 是一个开放协议，用来把 AI 应用连接到模型本身之外的系统。这些系统可能是本地文件、数据库、API、源码管理、文档库、日历、开发工具，或者内部业务流程。
单独一个大模型不会自动知道你当前仓库里有什么、你内部工单系统怎么运作、某个客户是否在你数据库里、当前哪个部署槽是激活的。你可以把信息粘进 prompt，但这不可扩展；你可以给某一个助手写定制集成代码，但那往往把集成锁死在一个主机上。
MCP 通过定义一条协议边界来解决这个问题。AI 应用连上一个 MCP 服务器，发现它提供什么，再通过标准协议消息使用这些能力。服务器可以暴露动作、可读数据，或可复用的提示模板。主机仍然决定这些能力怎么呈现给用户。
对 C# 开发者，一个有用的理解方式是：MCP 不是你的领域模型，也不是你的 REST API，而是一层面向 AI 的契约，可以摆在你已经熟悉的系统前面。这层契约是为发现、上下文交换和 AI 应用的工具调用而设计的。
MCP 想解决的集成问题
核心问题是 M×N 集成爆炸。假设你有多个 AI 主机，以及它们需要触达的许多系统：
- AI 主机：IDE 助手、桌面助手、内部客服机器人、文档 agent、工作流自动化工具。
- 外部系统：GitHub、你的数据库、事故系统、文档、CRM、构建流水线，还有一堆内部 API。
- 集成路径：每一对”主机到系统”都需要各自的认证、schema、日志、权限和维护。
没有共享协议时，每个主机都要给每个系统写定制集成。5 个主机和 10 个工具能变成 50 条集成路径。再叠上授权规则、schema 变更、日志、工具描述、生命周期管理，维护成本涨得飞快。
MCP 通过标准化客户端和服务器之间的对话来减轻这个压力。服务器把一个能力暴露一次，兼容的主机就能通过它们的 MCP 客户端连上来、发现服务器提供什么。
这不意味着每个集成都变免费。你仍要设计服务器、定义安全操作、处理认证、可观测性、数据整形和错误处理。但协议给了所有人一个共同起点。这在精神上跟 .NET 开发者在别处在意契约的原因很像：我们用接口把消费者和实现分开，用 OpenAPI 描述 HTTP API，用依赖注入组合服务。MCP 不等于 DI 或 OpenAPI，但设计压力是同一种：更少的定制连接、更清晰的契约、更可复用的集成边界。
三个角色：主机、客户端、服务器
MCP 架构有三个角色。分清这些名字能避免很多混淆。
| 角色 | 概念含义 | .NET 开发者的心智模型 |
|---|---|---|
| 主机 Host | 用户交互的 AI 应用 | 协调模型、上下文、审批和 UI 的产品体验 |
| 客户端 Client | 主机内部维护到某一个 MCP 服务器连接的组件 | 专属于一个服务器连接的协议客户端 |
| 服务器 Server | 通过 MCP 暴露能力的程序 | 包裹领域逻辑、数据访问和策略的服务边界 |
主机可能是编辑器、聊天体验、agent 运行时或其他 AI 应用。官方架构文档描述主机为每个 MCP 服务器连接创建一个 MCP 客户端。所以如果一个主机同时连文件系统服务器和 GitHub 服务器，它可以为这两个连接各持有一个独立客户端。服务器可以作为进程本地跑在主机旁边，也可以远程跑在 HTTP 基础设施后面。
这套划分很重要，因为 MCP 没说”模型能做你服务器能做的任何事”，它说的是服务器可以描述能力，主机可以决定这些能力如何参与 AI 体验。这就给用户审批、作用域、允许清单和环境特定配置留了空间。
服务器在概念上暴露什么
MCP 服务器暴露三类主要能力：工具、资源、提示。它们容易被混在一起，我倾向按各自代表的职责来定义。
| 能力 | 概念目的 | 例子形状 |
|---|---|---|
| 工具 Tools | 通过 schema 定义的操作执行动作 | 搜索笔记、创建工单、查询数据库、调内部 API |
| 资源 Resources | 给 AI 应用提供可读上下文 | 文档文本、文件内容、数据库 schema、API 描述 |
| 提示 Prompts | 提供可复用的指令模板 | 审查代码、总结事故、引导排障流程 |
工具是 MCP 里最贴近函数调用的部分，因为模型或 agent 能用结构化参数请求一次工具调用。资源主要是读上下文而不是执行动作。提示是可发现的模板，可以带参数、引导主机走向一个已知的交互模式。
我用的小心智模型是这样：
// 仅概念：形状就是"做"、"读"或"引导"
enum McpCapabilityKind
{
Tool, // 做点什么
Resource, // 读上下文
Prompt // 引导交互
}这不是教 SDK，只是一个记忆钩子：工具去做，资源提供信息，提示引导。官方文档进一步把工具描述为模型控制、资源为应用驱动、提示为用户控制。这个框架很有用，因为交互模型本身就是设计的一部分——一个危险的写操作不该被当成被动的文档读取来对待。
MCP 和函数调用的关系
MCP 和函数调用相关，但不是一回事。
函数调用通常是模型或提供方的特性。你用名字、描述和 schema 描述函数，模型可以决定返回结构化参数来调一个函数，你的应用再执行它并把结果返回给模型。
MCP 能以类似的 schema 驱动方式暴露工具给 AI 应用。在当前的 C# SDK 里，McpClientTool 派生自 Microsoft.Extensions.AI 的 AIFunction，这让 MCP 工具很自然地融入 .NET 的 AI 工作流。
区别在于边界。直接函数调用时，函数往往定义在那个跟模型对话的应用内部。而 MCP 里，服务器可以通过标准协议暴露能力，让兼容主机去发现和使用。这让 MCP 更关乎可复用的集成面，而不是某一个应用的私有函数列表。
换个说法：函数调用是调用结构化函数的机制；MCP 是在 AI 应用和外部系统之间发现并交换能力的协议。工具是二者的重叠，但 MCP 还包括可读的资源、可复用的提示模板、用于初始化和能力协商的生命周期消息，以及客户端服务器如何通信的传输层。所以”MCP 和函数调用比怎样”更准确的说法不是替代，而是：MCP 能提供参与函数调用式工作流的工具，同时还标准化了客户端如何发现工具、读资源、取提示。
什么时候用 MCP，什么时候普通 REST 就够
对很多系统，普通 REST API 依然很合理。如果你在做普通 Web 应用、移动应用、服务间集成、公开 API，或给确定性软件客户端用的 CRUD 面，REST 可能就是对的形状。它被广泛理解、易于观测、和 HTTP 工具链契合。
MCP 更合适的场景是：消费者是一个 AI 主机，需要发现能力，并在对话或 agent 工作流里决定怎么用。协议是围绕工具、资源、提示这类面向 AI 的原语设计的，能以帮助主机和模型理解”有什么可用”的方式描述操作。
这个区别很重要。GET /customers/123 这样的 REST 端点可能很完美；而一个 MCP 工具更好的形状可能是”为这个问题找到客户支持上下文”，因为面向 AI 的操作需要更窄、更安全、更具描述性的契约。服务器背后仍然可以调你的 REST API——MCP 不要求你扔掉现有 API。
MCP 往往适合当消费者需要面向 AI 的发现：
- 主机需要在运行时列出可用能力
- 操作需要为模型辅助的工具使用而描述
- 服务器应该暴露资源或提示，而不只是端点
- 多个 AI 主机可能需要同一个能力边界
REST 往往在消费者是确定性软件时更简单：
- Web 应用需要可预测的 CRUD 端点
- 后端服务调另一个后端服务
- 现有 HTTP 契约已经满足集成
- 客户端不需要面向 AI 的能力发现
对 .NET 开发者，这是个重要的设计点。你可能已经有 ASP.NET Core 控制器、minimal API、类型化客户端和后台服务。MCP 可以摆在这些模式旁边，而不是取代它们。当然也有取舍：MCP 引入了另一层需要保护、版本化、文档化和观测的协议面。当多个 AI 主机需要用一致方式访问同样的工具和上下文时，MCP 才更有说服力。
.NET 开发者为什么该在意
该在意的原因是，MCP 和我们许多人已有的技能相交。协议是新的，工程关切却不是。
熟悉的 .NET 技能地图是这样：
- ASP.NET Core 在你想要一个带中间件、路由、配置、健康检查和部署的远程 MCP 服务器时很重要。
- 依赖注入 很重要，因为工具可以包裹应用服务、仓储、类型化客户端和策略组件。
- 认证与授权 很重要，因为一个只读资源和一个会写数据库或发消息的工具风险画像完全不同。
- 可观测性 很重要，因为你需要知道哪个能力被调用、带什么参数、被哪个主机或用户调用、之后发生了什么。
官方 C# SDK 通过 ASP.NET Core 提供 HTTP 服务器支持，托管风格和 .NET 开发者在别处用的一样。版本方面也要留意：撰写时 NuGet 上官方的 ModelContextProtocol、ModelContextProtocol.Core、ModelContextProtocol.AspNetCore 最新稳定版是 1.4.0，另有 2.0 预览可用。这不是盲目追预览的理由，而是提醒你发布实现指南前先核对包版本和文档。
更大的理由是复用。一个设计良好的 MCP 服务器能把一个能力暴露给不止一个兼容的 AI 主机，这能减少重复集成工作，也在你的业务系统和使用它的 AI 应用之间划出更清晰的边界。
几个常见误解
常见误解通常来自把 MCP 想得比它本身更大或更小：
- MCP 不是 AI 框架。 它不决定用哪个模型、你的 agent 循环怎么跑、你的应用怎么推理。
- MCP 不替代 API。 服务器可以包裹现有的 REST API、数据库、文件、队列或服务。
- MCP 不会自动让工具使用变安全。 安全来自谨慎的服务器设计、主机行为、权限、校验和人工监督。
- MCP 不只是”换了名字的函数调用”。 函数调用是故事的一部分，但 MCP 还定义了资源、提示、客户端、服务器、生命周期和传输。
协议层的边界才是重点。它给 AI 应用一个一致的方式去理解服务器提供什么，同时把设计合理契约的责任留给工程团队。
小结
MCP 值得学，因为它给 AI 应用一个共享方式，去连接开发者本来就在建和维护的系统。对 C# 和 .NET 开发者来说，有意思的不是热度，而是那条架构边界。
MCP 帮着缓解众多 AI 主机和众多外部系统之间的 M×N 集成问题；它把主机、客户端、服务器分开；把工具、资源、提示定义为不同的能力类型；和函数调用自然相关但范围更广；能和 REST API 共存而非替代。如果从这篇只带走一个想法：MCP 是一个让外部能力对 AI 应用可发现、可使用的协议，而围绕它的 .NET 工作，依然靠你已经会的那些工程基本功。