AB
AiBoss站
百科

什么是 MCP 服务器(MCP Server)?面向 AI 应用的标准化能力接口

MCP 服务器是依照 Model Context Protocol 规范,把文件系统、数据库、代码托管、团队沟通、日程等能力以标准化接口暴露给 AI 应用的程序。它通过工具、资源、提示模板三类构件,让模型在用户可控的前提下调用外部操作与读取上下文。

MCP 服务器(MCP Server)是依照 Model Context Protocol 规范编写、通过标准化协议接口向 AI 应用暴露特定能力的程序。按照 Model Context Protocol 官方规范的说法,它要解决的问题是:AI 应用需要访问文档、数据库、代码仓库、团队沟通与日程等外部系统,而每个系统的接入方式各不相同;MCP 服务器把这些能力收敛到一套统一的协议接口上,使 AI 应用不必为每个数据源单独定制集成。

为什么重要

在 MCP 服务器这种形态出现之前,AI 应用接入外部能力通常走两条路:一是由应用自己为每个外部系统写专用连接器,二是把外部数据预先搬进模型上下文。前者的问题是集成数量随系统数量线性增长,同一份能力在不同应用之间反复重写;后者的问题是数据只能被读取,模型无法主动执行操作,也难以保证数据的新鲜度。

MCP 服务器把「能力提供方」和「能力使用方」解耦:服务器负责声明自己提供哪些操作、需要哪些输入、返回什么结果,客户端应用负责发现这些声明并按需调用。官方规范给出的典型例子包括用于文档访问的文件系统服务器、用于数据查询的数据库服务器、用于代码管理的 GitHub 服务器、用于团队沟通的 Slack 服务器,以及用于日程安排的日历服务器。这些例子说明,服务器是能力的封装单位,而不是某个具体产品的附属功能。

工作机制

官方规范把服务器提供的能力归纳为三类构件,并明确了每一类由谁控制。

  • 工具(Tools):模型可以主动调用的函数,由模型根据用户请求决定何时使用。工具可以写数据库、调用外部 API、修改文件或触发其他逻辑。规范将这类构件标记为「模型控制」。
  • 资源(Resources):被动数据源,提供只读的信息访问,例如文件内容、数据库模式或 API 文档。规范将这类构件标记为「应用控制」。
  • 提示模板(Prompts):预先构建的指令模板,告诉模型如何配合特定的工具与资源工作。规范将这类构件标记为「用户控制」。

以工具为例,规范说明每个工具都是一个由模式(schema)定义的接口,MCP 使用 JSON Schema 做校验,每个工具执行单一操作,输入输出都有明确定义。协议层面涉及两个操作:tools/list 用于发现可用工具,返回带模式的工具定义数组;tools/call 用于执行某个具体工具,返回执行结果。规范给出的工具定义示例中,一个名为 searchFlights 的工具声明了描述、输入模式以及必填字段列表,输入模式里包含出发城市、到达城市与出行日期三个字符串字段。

在用户控制方面,规范强调工具虽然由模型控制、可以被自动发现和调用,但 MCP 重视人的监督,应用可以通过多种机制实现用户控制,例如在界面中展示可用工具、对单次工具执行弹出审批对话框、为某些安全操作设置预授权,以及记录所有工具执行及其结果的活动日志。规范还提到,工具在执行前可能需要用户同意。

典型例子

官方规范用一个旅行规划的假设场景演示三类构件如何协作。AI 应用可以调用 searchFlights 工具,以出发地、目的地和日期为参数查询多家航空公司并返回结构化的航班选项;调用 createCalendarEvent 工具在用户日历中标记出行日期;调用 sendEmail 工具向同事发送自动回复的外出通知。这个场景中,工具承担的是「执行动作」的角色,而资源承担的是「提供上下文」的角色。

厂商侧的实现可以 Microsoft Learn MCP Server 为例。据 Microsoft Learn 官方文档介绍,这是一个远程 MCP 服务器,使用 streamable http,客户端应用通过端点连接后,可以搜索文档、获取完整文章以及搜索代码示例。文档称其面向 GitHub Copilot 等客户端与 AI 代理,使它们能够直接获取来自微软官方文档的、可信且及时更新的信息。文档列出的使用场景包括增强 Visual Studio Code、Visual Studio 等代理式开发环境,在 Copilot Studio 代理、Foundry 代理和自定义方案中使用 Learn 内容,以及让学习者、工程师和支持人员在工作流中使用 Learn 内容。

该文档还说明,这个服务器提供的是通往 Learn 知识服务的接口,而该知识服务同时为 Ask Learn 和 Copilot for Azure 提供支持;访问它不需要身份验证,公开可用且不收费。文档同时提示,该端点是为 MCP 客户端通过 Streamable HTTP 进行程序化访问而设计的,不支持从网页浏览器直接访问,手动访问可能返回 405 Method Not Allowed 错误。

边界与常见误解

第一,MCP 服务器不是模型本身,也不是某种推理能力。它只负责按协议声明并执行能力,是否调用、何时调用由客户端应用与模型决定,规范中三类构件的控制方分别是模型、应用和用户。

第二,服务器暴露的能力范围由实现方界定,不能默认它覆盖某个系统的全部功能。以 Microsoft Learn MCP Server 为例,其文档明确列出限制:服务器只包含公开可用的文档,不包含培训信息或用户配置文件信息;底层知识服务在内容更新后增量刷新,并每天执行一次完整刷新。这些都是该服务器自身的边界,不应推广为所有 MCP 服务器的通性。

第三,工具调用存在已知代价与风险面。规范之所以强调审批对话框、预授权和活动日志等机制,正是因为工具可以写数据库、调用外部 API、修改文件,一旦被误触发,影响会落到真实系统上。把「模型可以自动调用工具」理解为「无需人工把关」是一种常见误解。

第四,远程服务器有传输与访问方式的约束。Microsoft Learn 文档指出其端点面向 MCP 客户端而非浏览器直接访问,这说明「服务器」在网络形态上可以是远程服务,接入方式取决于具体实现,不能一概而论。

参考资料