想象你住进一家大酒店：想点餐、叫洗衣、约车，但你完全不用知道后厨在哪、洗衣房几点下班、维修工叫什么名字——你只需拿起房间电话，拨一个“总台”分机。总台小姐记下需求、转给对应部门，再把结果反馈给你。对 AI Agent（智能助理）来说，MCP Server 就是那个“总台”：它把文件系统、数据库、各种 API 这些“服务部门”统一到一个标准入口。Agent 只需要按照固定话术（协议）提出请求，就能拿到结果，完全不用关心每个工具的内部差异。 这篇文章用“酒店总台”作为贯穿全篇的比喻，带你零基础入门 MCP Server。我们会先看看总台的核心职责，再了解它从开门到打烊的生命周期，认识各服务部门如何向总台“报备”能力，接着动手搭建一个最小可用的 Server，搞清楚它和传统 REST API 服务的区别，最后看看它在真实世界如何落地。读完你会明白：MCP Server 不是一个黑盒子，而是一个守着标准流程、让 AI Agent 用起来得心应手的“服务总台”。

岗位关联

对 AI 从业者而言，MCP Server 是让 Agent 获得真实工具能力的“最后一公里”基础设施。掌握它的核心职责与生命周期管理，你就能为 Agent 定制可复用的工具服务端，让 AI 从“会聊天”进化到“会办事”。

目录
  1. 可视化演示
  2. 核心职责
  3. 生命周期
  4. 注册机制
  5. 搭建流程
  6. 协议通信
  7. REST对比
  8. 实际应用
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示MCP Server的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

MCP Server：MCPS MCP Server总览与标准 Server核心职责与协议规范 核心机制可视化 MCP Server整体架构与关键组件

核心职责

总台小姐一天要处理几百通电话。有的住客说“帮我叫一份牛排”，有的说“房间空调坏了”，还有的问“明天几点能退房”。总台不会自己下厨、不会亲自修空调，但她清楚该把每通电话转给谁，并且会在挂断前给住客一个明确答复。这就是总台的四个基本功：接得住、转得对、答得回、守得住。

在 MCP 的世界里，这个“总台”就是 MCP Server，住客就是 AI Agent，各服务部门就是一个个工具（文件系统、数据库、第三方 API）。Server 首先要维护一张工具注册表，知道“有哪些服务可用”；收到 Agent 的调用请求后，它要把请求路由给正确的工具处理器；工具执行完，Server 再把结果封装成标准消息回传给 Agent；整个过程还要守住安全边界，比如校验参数、控制权限，避免 Agent 误删文件或越权访问。

用集合的眼光看，一张工具注册表长这样：

你看，总台的核心职责就是“替住客找到对的部门，再把结果送回来”。MCP Server 做的事情从本质上看一模一样——它不替工具做业务逻辑，只做标准化的登记、转发、回传、把关。理解了这一层，后续的生命周期和注册机制就不难懂了。

R={(ni,si,hi)∣i=1,2,…,k}\mathcal{R} = \left\{ (n_i, s_i, h_i) \mid i = 1, 2, \ldots, k \right\}
  1. $\mathcal{R}$（注册表整体）整个工具注册表被定义为一个集合，等价于总台墙上挂着的“服务部门一览表”，里面有 \( k \) 个条目。
    R={…}\mathcal{R} = \{\ldots\}
  2. $n_i$（工具名称）第 \( i \) 个工具的名字，相当于部门名称“餐厅”“洗衣房”，Agent 通过这个名字找到对应服务。
    nin_i
  3. $s_i$（参数 Schema）第 \( i \) 个工具的参数规格描述，相当于点餐单上要填的“菜品、几分熟、忌口”，Agent 按这个格式填写请求。
    si=inputSchema(i)s_i = \text{inputSchema}(i)
  4. $h_i$（执行函数）第 \( i \) 个工具真正干活的函数，相当于后厨的灶台师傅，收到指令后真正执行逻辑。
    hi=handler(i)h_i = \text{handler}(i)
  5. $k$（工具总数）上界 \( k \) 表示注册表中一共登记了多少个工具，Server 每次上报能力清单都要数一遍这张表。
    k=∣R∣k = |\mathcal{R}|

生命周期

一家总台不是凭空就能营业的。清晨开门，服务员要先检查电话线路、打开系统、确认各房态信息；然后把今日可提供的服务清单摆上柜台；白天正常接待；深夜打烊，要关设备、备份记录、锁好门。这套“开门—就绪—营业—打烊”的流程，对应到 MCP Server 上就是它的生命周期。

MCP 协议规定，Server 与 Client（比如集成 MCP 的 AI 应用）建立会话必须经历四个阶段：先是初始化握手，双方交换协议版本、确认身份，就像登记入住；接着是能力声明，Server 告诉 Client 自己支持哪些工具，如同递上服务菜单；然后进入运行服务阶段，处理一个接一个的工具调用请求；最后是优雅关闭，释放资源、通知对方“我要下线了”。

把生命周期抽象成一台状态机，可以这样表示：

生命周期管理是 MCP Server 最容易被新手忽略的环节。很多人以为“能跑起来就行”，但协议要求 Server 必须先走完握手和声明，再处理业务请求，否则客户端会直接拒绝通信。就像总台没登记入住信息就把房卡给陌生人，酒店一定会出事。

M=(S,E,δ,s0),S={init,ready,running,closed}\mathcal{M} = (S, E, \delta, s_0), \quad S = \{ init, ready, running, closed \}
  1. $\mathcal{M}$（状态机模型）整个生命周期被建模为一个四元组状态机，相当于用一张流程图描述总台的运营规则。
    M=(S,E,δ,s0)\mathcal{M} = (S, E, \delta, s_0)
  2. $S$（状态集合）四个状态依次是 \( init \)（初始化准备）、\( ready \)（能力声明完成、就绪）、\( running \)（营业中，处理请求）、\( closed \)（已关闭）。
    S={init,ready,running,closed}S = \{ init, ready, running, closed \}
  3. $E$（事件集合）触发状态变化的事件，如“握手完成”“收到关闭信号”，对应电话响起、客人入住、打烊铃响。
    E={einit,eready,eshutdown}E = \{ e_{init}, e_{ready}, e_{shutdown} \}
  4. $\delta$（转换函数）定义了“当前状态 + 事件 → 下一个状态”的规则，例如 \( \delta(init, 握手完成) = ready \)。
    δ:S×E→S\delta: S \times E \rightarrow S
  5. $s_0$（初始状态）Server 进程刚启动时默认处于 \( init \) 状态，相当于总台刚开门、还没接待第一位客人。
    s0=inits_0 = init

注册机制

假设后厨新推出了一道“黑松露炒饭”，怎么让住客知道？后厨需要把这道菜报到总台，注明菜名、口味、需要哪些食材（是否有忌口、是否辣）。总台更新菜单，住客打电话就能点到。这个“向总台报备”的动作，就是 MCP Server 里的工具注册。

在 MCP 协议中，每个工具在注册时都要附带一份“描述器”，让 Agent 在调用前就能看懂这个工具是干什么的、需要什么参数。Server 会把这些描述器组织进工具注册表，对外提供能力发现接口（tools/list）让客户端查询；Agent 要调用时，则按描述器里的参数 Schema 填好参数。动态增删则允许在运行期热更新工具，如同菜单可以随时加菜、下架。

一个工具描述器可以形式化为三元组：

一个好的注册机制是 MCP Server 好用与否的分水岭。描述器写得越清楚，Agent 就越不会“点错菜”——它知道该填“文件路径”而不是“文件内容”，知道该在什么场景调用这个工具。反过来，描述含混不清，Agent 就会像对着菜单上只写“神秘料理”四个字的顾客一样，完全不知所措。

descriptor(t)=(name(t),  description(t),  inputSchema(t))\text{descriptor}(t) = \left( \text{name}(t),\; \text{description}(t),\; \text{inputSchema}(t) \right)
  1. $\text{descriptor}(t)$（工具描述器）工具 \( t \) 的完整描述，相当于菜单上关于一道菜的全部信息。
    descriptor(t)=(…)\text{descriptor}(t) = (\ldots)
  2. $\text{name}(t)$（工具名）工具的名字，如“读取文件”“查询天气”，是 Agent 调用时的唯一标识，相当于菜名。
    name(t)\text{name}(t)
  3. $\text{description}(t)$（功能描述）用自然语言说明工具的用途和适用场景，相当于“这道菜是川味还是粤式、适合几个人吃”，Agent 根据它决定何时调用。
    description(t)="读取指定路径的文本文件"\text{description}(t) = \text{"读取指定路径的文本文件"}
  4. $\text{inputSchema}(t)$（入参 Schema）用 JSON Schema 描述每个参数的名字、类型、是否必填，相当于菜谱上的“食材清单和做法要求”，Agent 按此格式化参数。
    inputSchema(t)={path: string, encoding?: string}\text{inputSchema}(t) = \{ \text{path: string, encoding?: string} \}

搭建流程

想开一家总台，你得先租个办公室（环境准备）、装好电话交换机（SDK 选择）、把各部服务登记在册（服务配置），最后试打几个电话验证线路畅通（测试验证）。搭建一个最小可用的 MCP Server，也遵循同样的四步。

环境准备上，官方推荐的 Python 版本是 3.10 以上，安装 mcp 或 fastmcp 库；SDK 选择上，追求快速上手可以用 FastMCP——它把协议细节全部封装好，你只需写普通函数；服务配置的核心是注册工具：用装饰器把一个普通函数标记为工具，并写上名字和参数说明；最后用官方提供的调试工具 MCP Inspector 或一个简单的 Client 脚本连上来，验证 tools/list 能列清单、tools/call 能拿到结果。

一个最小工具的本质就是一个纯函数，比如加法函数：

整个搭建流程的核心心法是：先跑通最小闭环，再逐步加工具。你不需要一开始就设计出十个工具的宏伟架构，先用一个加法函数验证“客户端能发现、能调用、能拿到结果”，这条链路通了，后面加文件系统、数据库工具就是复制粘贴级别的工作量。总台的电话交换机先能打通一个分机，再谈接全酒店。

add:Z×Z→Z,add(a,b)=a+badd: \mathbb{Z} \times \mathbb{Z} \rightarrow \mathbb{Z}, \quad add(a, b) = a + b
  1. $add$（函数名）工具的内部实现就是一个普通函数，对应后厨里一位师傅的拿手菜。
    add(a,b)add(a, b)
  2. $\mathbb{Z} \times \mathbb{Z}$（输入域）两个整数参数 \( a \) 和 \( b \)，相当于点餐单上的“两份食材”。
    Z×Z\mathbb{Z} \times \mathbb{Z}
  3. $\rightarrow \mathbb{Z}$（输出域）函数返回一个整数，即出餐口端出来的成品。
    →Z\rightarrow \mathbb{Z}
  4. $a + b$（函数体）具体逻辑就是做一次加法，简单到不需要任何外部依赖。
    a+ba + b

协议通信

总台和各部门之间必须用统一的“对讲机话术”：呼叫方先报“我是总台，请执行 X”，应答方回“收到，结果是 Y”，如果线路忙就回“抱歉，暂不可用”。没有这套固定话术，餐厅用上海话、洗衣房用粤语，总台就得崩溃。MCP Server 和 Client 之间的话术，就是 JSON-RPC 2.0。

JSON-RPC 的消息只有两种核心形态：请求（request） 和 响应（response）。请求必须带上版本号 jsonrpc: "2.0"、唯一的 id、要调用的方法名 method（如 tools/call）和参数 params；响应则回显 id 并携带 result。还有一种特殊的“只说不听”的消息叫通知（notification），不需要 id，也不期待回复，比如日志上报、进度提示。

一套最典型的请求-响应消息结构可以这样表示：

理解了 JSON-RPC，你就掌握了 MCP 的全部“语法”。它不发明新协议，而是站在 JSON-RPC 这个成熟标准之上，用 tools/list、tools/call 等约定方法表达工具服务的语义。就像总台并不需要发明一门新语言，只要规定“第一句报身份、第二句说事”就够了。

req=(j,id,m,p),resp=(j,id,r)\text{req} = (j, id, m, p), \quad \text{resp} = (j, id, r)
  1. $\text{req}$（请求消息）一个四元组，对应一句完整的对讲机呼叫“总台呼叫餐厅，请做一份牛排”。
    req=(j,id,m,p)\text{req} = (j, id, m, p)
  2. $j$（协议版本）固定为 "2.0"，等价于双方约定的统一频率，版本不一致就无法通信。
    j="2.0"j = \text{"2.0"}
  3. $\text{id}$（请求标识）一个唯一的数字或字符串，相当于通话编号；响应必须带上同一个 id，请求和响应才能配对。
    id=1\text{id} = 1
  4. $m$（方法名）要调用的协议方法，如 initialize、tools/list、tools/call，相当于说“我要点餐”还是“我要查菜单”。
    m="tools/call"m = \text{"tools/call"}
  5. $p$（参数）方法携带的具体参数，如工具名和参数字典，相当于具体的菜品和口味要求。
    p={name: "add", arguments: a: 1, b: 2}p = \{ \text{name: "add", arguments: {a: 1, b: 2}} \}
  6. $\text{resp}$（响应消息）一个三元组，id 是回声，r 是执行结果或错误信息。
    resp=(j,id,r)\text{resp} = (j, \text{id}, r)

REST对比

在 MCP 出现之前，让 Agent 调用工具是什么体验？那就像酒店没有总台：住客要在床头柜放一本厚电话簿，记着餐厅分机、洗衣房分机、维修分机，而且每家的话术还不一样——有的要按 1 转接，有的要先报房号再报需求。传统 REST API 就是这样的电话簿：每个服务一套接口规范，Agent 要对接 \( m \) 个服务，就得维护 \( m \) 套客户端代码。

MCP Server 把问题彻底简化。它的核心优势体现在四个方面：接口规范统一，所有工具都走同一个协议，Agent 只需实现一个客户端；长连接通信，Server 和 Client 保持持久会话，支持双向消息推送，而 REST 是一次性的短请求；能力动态发现，Client 随时可以查询当前有哪些工具，REST 则依赖静态文档手动更新；上下文感知，MCP 会话天然携带上下文，Agent 不用每次重新交代背景。

用“接入复杂度”这个指标来量化：

这不是说 REST 会被 MCP 完全取代——REST 在面向浏览器的公开 API 领域依然无可替代。MCP 解决的是“Agent 如何高效地发现和调用一堆工具”这个新问题。总台的意义不在于取代各部门，而在于让住客只需要记住一个号码。MCP Server 亦然：它不取代工具本身，只取代“逐个对接工具”的痛苦。

NMCP=O(1),NREST=O(m×n)N_{\text{MCP}} = O(1), \quad N_{\text{REST}} = O(m \times n)
  1. $N_{\text{MCP}}$（MCP 接入成本）Agent 接入工具体系需要维护的“入口数”，这里是一个常数。
    NMCP=O(1)N_{\text{MCP}} = O(1)
  2. $O(1)$（常数阶）无论背后有多少工具，Agent 永远只连一个 MCP Server，就像住客只需要记住总台一个分机号。
    O(1)O(1)
  3. $N_{\text{REST}}$（REST 接入成本）Agent 直接对接 REST 服务时需要维护的接口数。
    NREST=O(m×n)N_{\text{REST}} = O(m \times n)
  4. $O(m \times n)$（乘积阶）\( m \) 个服务、每个服务平均 \( n \) 个端点，接口数量随服务规模线性膨胀，电话簿越来越厚。
    O(m×n)O(m \times n)

实际应用

总台建好了，电话线路通了，菜单也挂出去了，那真实酒店的各部门都怎么接入总台的？在 MCP 生态里，最常见的三类“部门”是文件系统、数据库和第三方 API。

文件系统工具是最常见的入门实践：给 Server 暴露一个受控目录，Agent 就能执行读取文件、列出目录、写入笔记等操作，相当于把“客房送东西”变成标准服务。数据库工具把 SQL 查询能力封装成工具函数，Agent 可以问“上个月销售额前五的产品是什么”，Server 负责执行查询并返回结构化结果，相当于总台帮住客查航班信息。API 集成则是把 GitHub、飞书文档、天气服务等第三方 REST API 包一层 MCP 皮，变成 Agent 能调用的工具。单个工具看似简单，但组合起来的威力是巨大的。

假设 Server 暴露了 \( k \) 个工具，Agent 可以两两组合执行多步任务：

文件系统负责“读”，数据库负责“查”，API 负责“取外部信息”——三者组合起来，Agent 就能完成“读取本地订单文件 → 查询数据库核对库存 → 调用物流 API 创建发货单”这样的完整业务流程。这也是 MCP Server 作为“总台”最大的价值：它让工具不再是孤岛，而是随时可被 Agent 编排的乐高积木。

---

C(k,2)=(k2)=k(k−1)2C(k, 2) = \binom{k}{2} = \frac{k(k-1)}{2}
  1. $k$（工具总数）Server 暴露给 Agent 的工具数量，对应总台挂出的服务条目数。
    k=5k = 5
  2. $\binom{k}{2}$（组合数）从 \( k \) 个工具中任选 2 个执行“先 A 后 B”的组合方式数，是 Agent 能做多步编排的理论上限。
    (k2)\binom{k}{2}
  3. $\frac{k(k-1)}{2}$（展开公式）组合数的代数展开，比如 5 个工具就有 10 种两两搭配，工具越多，Agent 能编排的花样越多。
    k(k−1)2\frac{k(k-1)}{2}

AI 应用场景

企业数据问答助手

阶段：工具服务端搭建

解决的问题：传统方式下，业务人员想查数据库必须提工单、等数仓团队跑 SQL，反复沟通成本极高。用 MCP Server 把只读 SQL 查询封装成工具后，Agent 能直接理解“上季度华东区退货率”，并自动生成、执行查询。

具体案例：某电商公司搭建了一个 MCP Server，暴露 query_sales、query_inventory、query_customer 三个只读工具，Claude 或自研 Agent 通过 MCP 客户端连上后，运营同学用自然语言提问就能拿到数据报表。

个人文件管理助手

阶段：Agent 工具集成

解决的问题：让 Agent 直接访问文件系统有越权和误删风险，传统做法是把文件操作写死在 Agent 代码里，改一处就要重发版本。MCP Server 把文件操作变为受控工具，目录白名单、参数校验都在 Server 层完成。

具体案例：开发者搭建一个 desktop-files 的 MCP Server，工具包括 read_file、list_dir、write_note，并限定只能访问 ~/workspace 目录。Agent 收到“把今天的会议纪要整理到 workspace/meeting-notes”的指令后，自动调用工具完成。

第三方服务聚合网关

阶段：API 集成与标准化

解决的问题：Agent 要同时用 GitHub 和飞书文档，得分别对接两套 REST API 鉴权和调用逻辑，代码既啰嗦又难维护。将两者封装为统一 MCP 工具后，Agent 一次接入、到处调用。

具体案例：一个“研发助手” MCP Server 聚合了 github_create_issue、feishu_send_message、github_list_pulls 等工具。开发者在 IM 里说“给仓库提一个 bug issue 并通知测试群”，Agent 依次调用两个工具完成任务。

Python 演示

python39 行
from datetime import datetimeimport os from mcp.server.fastmcp import FastMCP mcp = FastMCP("filesystem-helper")  @mcp.tool()def read_file(path: str) -> str:    """读取指定路径的文本文件内容"""    if not os.path.abspath(path).startswith(os.path.abspath(WORKSPACE)):        return "错误: 路径不在允许的工作目录内"    try:        with open(path, "r", encoding="utf-8") as f:            return f.read()    except FileNotFoundError:        return "错误: 文件不存在"  @mcp.tool()def list_dir(path: str = ".") -> list:    """列出指定目录下的所有条目"""    full = os.path.join(WORKSPACE, path)    if not os.path.isdir(full):        return ["错误: 目标不是有效目录"]    return os.listdir(full)  @mcp.tool()def current_time() -> str:    """返回当前系统时间"""    return datetime.now().strftime("%Y-%m-%d %H:%M:%S")  WORKSPACE = os.path.join(os.path.expanduser("~"), "mcp-workspace") if __name__ == "__main__":    mcp.run()
目的：演示一个最小的 MCP Server——用 FastMCP 把文件系统能力封装成三个工具并启动服务。
  1. from mcp.server.fastmcp import FastMCP引入官方 SDK，FastMCP 已经封装好了初始化握手、能力声明、JSON-RPC 编解码等协议细节。
  2. mcp = FastMCP("filesystem-helper")创建 Server 实例，服务名是 filesystem-helper，相当于总台的招牌。
  3. @mcp.tool()这是最核心的注册机制：装饰器把下面的普通函数登记为 Agent 可调用的工具。
  4. def read_file(path: str) -> str:函数签名 + 类型注解自动生成 JSON Schema，Agent 因此知道要传 path 字符串。
  5. """读取指定路径的文本文件内容"""文档字符串会被当作工具描述，Agent 根据这段文字判断何时调用，所以要写得清晰。
  6. if not os.path.abspath(path).startswith(...)安全边界校验：强制路径限制在 WORKSPACE 内，防止 Agent 越权读取任意文件。
  7. return os.listdir(full)返回类型是 list，FastMCP 会自动把 Python 列表序列化为 JSON 响应。
  8. WORKSPACE = os.path.join(...)定义工作根目录，所有文件操作都以它为基准，相当于在总台挂出“只服务本酒店住客”的规矩。
  9. mcp.run()启动服务进入 running 状态，默认使用标准输入输出（stdio）传输，等待客户端连入。

常见误区

误区很多初学者觉得 MCP Server 只是换了个名字的 HTTP 后端，照样用 Flask 写一堆路由，把数据库查询做成 JSON 接口，再声称“这就是 MCP Server”。

正解MCP Server 的核心不是“提供接口”，而是“遵循 MCP 协议”。协议规定的 JSON-RPC 通信、生命周期握手、能力发现机制，都是 REST API 没有的。就像总台的灵魂不是有部电话，而是统一的话术和转接流程；你可以在 Flask 上实现 MCP 协议，但“用 Flask 写几个路由”不等于 MCP Server。

为何常见：REST 的思想太深入人心了，大家习惯性地把“暴露能力”等同于“写 HTTP 接口”，没意识到 MCP 的增量价值在于协议层的标准化和会话管理。

误区认为 MCP Server 一定要起一个端口、跑一个 `localhost:8080` 的进程，Agent 通过 HTTP 请求来访问。

正解MCP 最常见、最简单的部署模式是 stdio——Server 作为子进程被 MCP 客户端拉起，通过标准输入输出通信，不需要绑定任何端口。等到需要远程访问、多客户端共享时，才考虑 Streamable HTTP 或 SSE 传输。就像酒店总台的电话线，既可以是房间里的内线（stdio），也可以是外部可拨的外线（HTTP）。

为何常见：Web 开发的经验让大家默认“服务 = 端口 + HTTP”，忽略了 CLI 工具、桌面应用里本地起子进程才是更轻量的选择。

误区注册工具时函数签名和文档能省则省，参数叫 `a`、`b`，描述写“处理数据”，觉得 Agent 反正能猜出来。

正解工具描述器和参数 Schema 是 Agent 决定“何时调用、怎么填参”的唯一依据。描述模糊、参数命名随意，Agent 就会像看到菜单上只有“神秘料理”的住客一样不敢点菜，或者点错菜。写清楚 path: str 和“读取指定路径的文本文件”，Agent 才能正确使用工具。

为何常见：开发者习惯面向“人”写接口文档，认为参数名短即优雅；但 MCP 的调用方是语言模型，它只能看到字符串描述，描述的质量直接决定调用成功率。

误区搭建本地工具 Server 时，直接把整个用户目录暴露出去，觉得反正是自己电脑、自己的 Agent，不会有问题。

正解Agent 可能被提示词注入攻击——恶意网页内容可能诱导它执行“删除所有文件”“读取 SSH 密钥”等危险操作。Server 必须做最小权限设计：限制目录白名单、禁止危险操作、敏感动作要求二次确认。就像总台不会把万能钥匙交给住客，只会按需送指定物品到指定房间。

为何常见：“本地工具 = 安全”的直觉骗了很多人。安全问题不取决于使用者是谁，而取决于 Agent 的输入是否可能被第三方污染。

面试题

Q1. MCP Server 的核心职责中，不包括哪一项？

单选题 · easy

  • A.维护工具注册表
  • B.路由请求到正确工具
  • C.代替 Agent 做最终决策← 正确答案
  • D.校验参数并回传结果

答案：C。MCP Server 是“总台”，负责登记工具（A）、转接请求（B）、把关和回传结果（D），但绝不替 Agent 做业务决策。决策是 Agent 的职责，就像总台不会替住客决定晚饭吃什么。

Q2. Client 与 MCP Server 建立会话的第一步是什么？

单选题 · easy

  • A.tools/call
  • B.initialize 初始化握手← 正确答案
  • C.直接发送通知
  • D.关闭连接

答案：B。MCP 协议规定必须先走 initialize 握手，交换协议版本和能力，之后才能进入 ready/running 阶段。就像住客入住必须先登记拿房卡，不能直接冲进后厨点菜。

Q3. MCP Server 生命周期包含以下哪些阶段？

多选题 · mid

  • A.初始化握手← 正确答案
  • B.能力声明← 正确答案
  • C.运行服务← 正确答案
  • D.优雅关闭← 正确答案

答案：ABCD。生命周期四阶段依次是 init（握手）、ready（声明）、running（服务）、closed（关闭），对应总台“开门检查—摆菜单—营业—打烊”全流程，四个阶段缺一不可。

Q4. 工具注册表 \(\mathcal{R} = \{(n_i, s_i, h_i)\}\) 中的 \(s_i\) 代表什么？

单选题 · mid

  • A.工具名称
  • B.参数 Schema← 正确答案
  • C.执行函数
  • D.服务地址

答案：B。\(s_i\) 是 inputSchema，描述工具的参数格式，相当于点餐单的填写要求；\(n_i\) 是名称，\(h_i\) 是执行函数。三者一起构成一个完整的注册条目。

Q5. MCP 协议底层基于哪种消息格式？

单选题 · mid

  • A.XML-RPC
  • B.JSON-RPC 2.0← 正确答案
  • C.SOAP
  • D.GraphQL

答案：B。MCP 基于 JSON-RPC 2.0，请求包含 jsonrpc/id/method/params，响应包含 jsonrpc/id/result。这就像总台和各部门约定好的统一对讲机频率。

Q6. 相比传统 REST API，MCP Server 的优势有哪些？

多选题 · mid

  • A.统一协议接入所有工具← 正确答案
  • B.长连接支持双向通信← 正确答案
  • C.支持能力动态发现← 正确答案
  • D.每个工具需单独实现客户端

答案：ABC。MCP 的核心优势是统一协议（A）、长连接会话（B）、动态能力发现（C）。D 恰恰是 REST 的痛点——每个服务一套客户端，相当于住客要记一堆分机号。

Q7. JSON-RPC 请求中，用于将请求与响应配对的是哪个字段？

单选题 · hard

  • A.jsonrpc
  • B.method
  • C.id← 正确答案
  • D.params

答案：C。id 是请求的唯一标识，响应必须回显同一个 id 才能配对，相当于通话编号。jsonrpc 是版本号，method 是方法名，params 是参数，三者都不承担配对功能。

Q8. 客户端通过哪个协议方法获取 Server 支持的工具清单？

单选题 · easy

  • A.tools/call
  • B.tools/list← 正确答案
  • C.initialize
  • D.ping

答案：B。tools/list 是能力发现接口，Client 调用它拿到工具描述器列表；tools/call 是实际调用工具；initialize 是握手；ping 是保活检测。对应总台先查菜单（list）再点菜（call）。

Q9. 关于 MCP Server 的安全边界，以下做法正确的有哪些？

多选题 · extreme

  • A.对工具参数做合法性校验← 正确答案
  • B.限制 Agent 可访问的目录范围← 正确答案
  • C.不做任何调用限制
  • D.敏感操作需显式授权← 正确答案

答案：ABD。参数校验（A）、目录白名单（B）、敏感操作授权（D）都是安全边界的正确实践。C 等于把万能钥匙交给所有住客，一旦 Agent 被提示词注入攻击就可能酿成大祸。

Q10. MCP Server 生命周期中，优雅关闭（shutdown）的主要目的是什么？

单选题 · hard

  • A.立即杀死所有工作线程
  • B.释放资源并通知 Client 断开← 正确答案
  • C.缓存所有工具调用结果
  • D.重启服务进程

答案：B。优雅关闭的核心是“体面退场”：停止接收新请求、释放连接和内存资源、通知对端会话结束。A 是暴力关闭，C 和 D 与关闭语义无关。就像打烊要等最后一位客人离店再锁门。