Protocol Era 设置
每个服务器都携带一个 protocolEra，取值 legacy、auto 或 modern。在 Web 客户端中它位于 Server Settings；在目录或配置文件中它是 protocolEra 字段；在 CLI 和 TUI 中它来自那同一个文件。
为何默认是
legacy 而不是 auto。 调试工具不能自动探测。server/discover 探测在面对沉默的旧式 stdio 服务器时会停滞，并且它会污染你来此想读取的记录。选择加入 auto 或 modern 是一个刻意的行为，因此你在 Protocol 标签页看到的，正是一个按你所配置方式行事的客户端会让你的服务器看到的内容。server/discover 还提供 capabilities（包括 extensions）、instructions 和 supportedVersions 列表。服务器的名称和版本在结果 _meta 中的 io.modelcontextprotocol/serverInfo 下抵达。
Server Settings：Protocol Era 选择器，带全部三个选项。
在本地复现每个时代
下面的每一节都以一个 Reproduce with … 指针结尾，指向 Inspector 仓库中随附的可组合测试服务器之一的 JSON 配置。克隆该仓库，构建测试服务器，然后将 Inspector 指向该节所指定的配置。日志
- Legacy
- Modern
日志是会话范围的。客户端发送一次
logging/setLevel，服务器在会话余下时间里以该级别或更高级别发出 notifications/message。Logs 标签页显示一个 Set Active Level 选择器外加一个 Set 按钮。选择一个级别，点击 Set，随后的服务器日志便流入面板。用 test-servers/configs/logging-legacy-http.json 复现。
Legacy：Logs 标签页提供一个会话范围的 Set Active Level 控件，调用 send_notification 之后到达一条日志。
Modern：同一个标签页改为提供 Log Level per Request。级别被加盖在每个发出的请求上，日志搭乘该请求的流。
资源订阅
- Legacy
- Modern
在资源上点击 Subscribe 会发送
resources/subscribe。Subscriptions 部分列出该 URI，没有任何流的装饰。当资源变化时，服务器发出 notifications/resources/updated，被订阅的图块的最后更新时间被加盖。用 test-servers/configs/subscriptions-legacy-http.json 复现，它还提供一个 update_resource 工具，让你自己驱动通知往返。
一个现代订阅：Subscriptions 部分携带一个 LISTENING 流状态徽章，而旧式订阅无需它。
Tasks
Tasks 在协议时代之间变化最大，包括_Inspector UI 标签页如何被门控_。- Legacy
- Modern
当服务器公布
capabilities.tasks 时，Tasks 标签页出现。在启用 Run as task 的情况下运行一个工具，该标签页便列出它，由 tasks/list 填充并用 tasks/get 轮询。完成的负载用一个阻塞式 tasks/result 获取，而 Cancel 发送 tasks/cancel。用 test-servers/configs/tasks-legacy-http.json 复现。
Legacy：Tasks 标签页由 tasks/list 填充，负载用一个阻塞式 tasks/result 获取。
Modern：客户端在它已持有的句柄上轮询 tasks/get，完成的 task 内联其结果；注意完整 task 对象中的 resultType: complete。
多轮工具结果（MRTR）
在现代时代，工具可以返回input_required 而不是最终结果，其中嵌入一个征询、一个采样请求，或一个 roots/list 请求。客户端回答那个嵌入的请求，并在一个新的 JSON-RPC id 下重试 tools/call，直到该调用达到 complete。
Inspector 手动驱动 MRTR，因此每一轮都在待处理请求模态框处暂停，标记为 input_required，供你回答。Protocol 视图将整个交换分组为一次 MRTR 对话，而不是无关的调用。
test-servers/configs/mrtr-showcase-http.json 将每一种形态打包在一个现代服务器中：
旧式的
collect_elicitation 模式（服务器调用 server.elicitInput）在 2026-07-28 连接上会报错，因为那里不允许服务器到客户端的请求。MRTR 是它的现代替代。
一个在待处理请求模态框处暂停的 MRTR 轮次，标记为 input_required。回答它会重试原始请求。
Tools：镜像的 header 和被排除的工具
SEP-2243 让工具用x-mcp-header 注解一个参数，请求 Streamable HTTP 客户端将该参数的值镜像到一个 Mcp-Param-* 请求 header 中。
Inspector 在 Tools 标签页中呈现该契约的两个方面：
- 带有有效注解的工具在其详情面板中显示一个 “Mirrored request headers (SEP-2243)” 部分，例如
city -> Mcp-Param-City。 - 带有无效注解的工具（比如一个 header 名
"Bad Header"，其中的空格使它成为一个无效的 RFC 9110 token）会在侧边栏中一个 “Excluded (SEP-2243)” 分隔符下以删除线显示，悬停时给出原因。合规的客户端必须将这样的工具从tools/list中丢弃；Inspector 向你展示它_为何_被丢弃，而不是静默地隐藏它。
test-servers/configs/xmcpheader-modern-http.json 复现。
get_weather 显示其镜像的 city -> Mcp-Param-City header，而 invalid_header_tool 在 Excluded (SEP-2243) 分隔符下以删除线显示。
-32602 错误面板
在现代时代下，一个以 -32602 拒绝的 tools/call 会渲染为一个各不相同的错误面板：
- Unknown Tool：当消息指名一个服务器未列出的工具时。通过调用任何不在服务器
tools/list中的名称来复现。 - Invalid Parameters：任何其他
-32602。用上面配置中的trigger_invalid_params工具复现。
-32602 拒绝；只有 Inspector 的呈现方式改变。在旧式连接上，你得到一个通用的 JSON-RPC 失败，必须读取消息才能分辨你遇到的是哪种情况。
Network 和 Protocol：header 和错误分类法
现代时代标准化了一组Mcp-* HTTP header，并引入了一个更丰富的 JSON-RPC 错误分类法（SEP-2243 / SEP-2575）。两个监控标签页分工：
- Network 标签页是 HTTP 视图：镜像的
Mcp-*header 被高亮，哨兵值被解码。 - Protocol 标签页是 JSON-RPC 视图：每个规范错误各不相同地渲染，而不是作为一个通用失败。
test-servers/configs/modern-network-http.json 提供四个工具，它们产生一个真实的 HTTP 状态外加一个 JSON-RPC 错误正文，每类一个：
Network 标签页显示 HTTP 层；此处是严格服务器所返回的 400 Bad Request。
Protocol 标签页将同一个失败渲染为一个类型化的规范错误：-32022 UnsupportedProtocolVersion，带服务器确实支持的版本。
会话
一个旧式 Streamable HTTP 连接可能携带一个服务器分配的会话 id（Mcp-Session-Id），客户端用一个 HTTP DELETE 将其拆除。一个现代连接是无会话且按请求的：由于没有会话 id，客户端 SDK 不向服务器发送 DELETE，因此断开连接纯属本地行为。
这对你自己的测试服务器有一个实际后果。一个按请求构造的无状态现代处理器无法在调用之间保持状态，这正是为什么 test-servers/configs/subscriptions-modern-http.json 与其旧式对应物不同，省略了一个 update_resource 工具：该变更会针对一个用完即弃的服务器实例运行，且对下一次读取不可见。