MCP Everything Server 实战：一个覆盖全部协议能力的 MCP 测试服务器

MCP Everything Server（包名 @modelcontextprotocol/server-everything）是一个刻意"什么都会做"的 Model Context Protocol 参考服务器：它同时实现了 tools、prompts、resources、sampling、elicitation、logging、订阅通知乃至 MCP Tasks 等协议特性，目标是让 MCP 客户端开发者在一个服务器里就能验证全部交互路径。读完本文，你将掌握它在 Claude Desktop、VS Code 中的完整配置方式、三种传输（stdio / SSE / Streamable HTTP）的启动命令，以及其工具注册、按会话隔离与条件注册等源码级实现细节。

定位：不是实用工具，而是协议"全功能靶场"

项目 README 的开宗明义是：

This MCP server attempts to exercise all the features of the MCP protocol. It is not intended to be a useful server, but rather a test server for builders of MCP clients.

也就是说，它的核心价值在于协议覆盖度而非业务功能。根据 package.json，当前仓库中该包版本为 2.0.0，mcpName 为 io.github.modelcontextprotocol/server-everything，核心依赖为 @modelcontextprotocol/sdk ^1.30.0、express（用于 HTTP 类传输）、zod（输入校验）、jszip 与 cors。所有注册的 MCP 原语与协议特性清单见官方特性文档 Server Features。

三种传输与启动入口

Everything Server 支持三种 MCP 传输，均通过同一个 CLI 入口 index.js（package.json 中 bin 字段映射为 mcp-server-everything → dist/index.js）启动。查看 入口文件 可以看到其调度逻辑：

const args = process.argv.slice(2);
const scriptName = args[0] || "stdio";   // 默认 stdio

switch (scriptName) {
  case "stdio":
    await import("./transports/stdio.js");
    break;
  case "sse":
    await import("./transports/sse.js");
    break;
  case "streamableHttp":
    await import("./transports/streamableHttp.js");
    break;
  // 未知参数时打印帮助并 exit(1)
}

设计要点是动态 import 按需加载——只初始化请求的那个传输模块，避免无关模块在启动时执行副作用。各传输的差异（来自 启动流程文档）：

传输	连接模型	端点	会话管理
stdio	单进程绑定连接	进程 stdin/stdout	连接时调用 clientConnect()，SIGINT 时清理
SSE（自 2025-03-26 规范起已废弃）	多客户端	GET /sse（SSE 流）+ POST /message（JSON-RPC）	按 sessionId 映射，onclose 钩子清理会话
Streamable HTTP	多客户端	/mcp 的 POST/GET/DELETE	使用事件存储（event store）支持断点续传，DELETE 时调用 cleanup(sessionId)

需要说明的适用前提：README 中明确标注 SSE 传输自 2025-03-26 版规范起已标记为 deprecated，新客户端应优先使用 Streamable HTTP 或 stdio。

以安装包方式运行（推荐日常使用）

最省事的运行方式是直接使用 npm 包：

# 1. 全局安装
npm install -g @modelcontextprotocol/server-everything@latest

# 2. 运行默认的 stdio 服务器
npx @modelcontextprotocol/server-everything

# 3. 或显式指定 stdio
npx @modelcontextprotocol/server-everything stdio

# 4. 运行 SSE 服务器
npx @modelcontextprotocol/server-everything sse

# 5. 运行 Streamable HTTP 服务器
npx @modelcontextprotocol/server-everything streamableHttp

npx 方式可以不预安装，临时拉取包并运行，这也是 Claude Desktop 与 VS Code 配置里直接写 npx -y ... 的原因。

从源码运行 HTTP 类传输

如果你需要调试 HTTP 传输或修改源码，README 给出的流程如下：

SSE 传输（已废弃，仅作兼容）：

cd src/everything
npm install
npm run start:sse

Streamable HTTP 传输：

cd src/everything
npm install
npm run start:streamableHttp

对照 package.json 的 scripts 字段，这三个命令的本质都是运行编译产物：

"start:stdio": "node dist/index.js stdio",
"start:sse": "node dist/index.js sse",
"start:streamableHttp": "node dist/index.js streamableHttp"

构建脚本 build 执行 tsc 编译，并通过 shx cp -r docs dist/ 把 docs/ 目录一并拷贝进发布产物——这正是服务器 instructions 的加载机制，下面会展开。

在 Claude Desktop 中接入（stdio 传输）

将以下配置写入 claude_desktop_config.json：

{
  "mcpServers": {
    "everything": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-everything"
      ]
    }
  }
}

Windows 下由于 npx 是批处理脚本，需要经 cmd /c 转发启动：

{
  "mcpServers": {
    "everything": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@modelcontextprotocol/server-everything"
      ]
    }
  }
}

两种配置的差异仅在进程启动方式，服务器本身始终以 stdio 传输运行。

在 VS Code 中接入

VS Code 提供一键安装按钮（NPX 或 Docker 两种方式，Docker 镜像为 mcp/everything，对应 Dockerfile 构建）。手动配置则有两种位置：

• 用户级配置（推荐）：命令面板（Ctrl + Shift + P）执行 MCP: Open User Configuration，打开用户级 mcp.json 添加服务器配置；
• 工作区级配置：写入工作区的 .vscode/mcp.json，便于随仓库共享。

NPX 方式的配置内容（注意 VS Code 使用 servers 键而非 Claude Desktop 的 mcpServers 键）：

{
  "servers": {
    "everything": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-everything"]
    }
  }
}

Windows 下的等价写法：

{
  "servers": {
    "everything": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-everything"]
    }
  }
}

能力总览：Tools、Prompts、Resources 与协议特性

完整清单在 features.md，这里按类别归纳，方便按需验证特定协议能力。

Tools（工具），覆盖输入校验、内容类型、反向请求、长任务等场景：

• echo / get-sum：最简工具，用 Zod 校验输入（实现见 tools/echo.ts）；
• get-annotated-message：返回带 priority/audience 注解的文本，可选附带注解图片；
• get-env：以格式化 JSON 返回进程环境变量；
• get-resource-links / get-resource-reference：分别演示 resource_link 列表与内联 resource 内容块；
• get-roots-list：返回客户端最近一次发送的 roots 列表（依赖客户端 roots 能力）；
• gzip-file-as-resource：抓取 URL/数据 URI、压缩后注册为会话资源 demo://resource/session/<name>（mimeType: application/gzip），按 outputType 返回 resource_link 或内联 resource；
• get-structured-content：同时返回兼容旧版的 content（JSON 文本）和经 outputSchema 校验的 structuredContent（temperature / conditions / humidity）；
• get-tiny-image：返回一张小型 PNG 图片内容项；
• trigger-long-running-operation：按 duration/steps 模拟多步操作，客户端提供 progressToken 时通过 notifications/progress 汇报进度；
• toggle-simulated-logging / toggle-subscriber-updates：分别开关模拟日志与订阅资源更新通知；
• trigger-elicitation-request：发起表单模式的 elicitation/create 请求（字符串、数字、布尔、枚举与格式校验字段）；
• trigger-url-elicitation：URL 模式的 elicitation，含 errorPath 错误路径演示（抛出 -32042 错误码），需要客户端 elicitation.url 能力；
• trigger-sampling-request：向客户端/LLM 发起 sampling/createMessage 请求并回传 LLM 响应；
• simulate-research-query：演示 MCP Tasks（SEP-1686）的多阶段研究任务，ambiguous: true 时先发起 elicitation 澄清；
• trigger-sampling-request-async / trigger-elicitation-request-async：演示双向任务——服务器把请求作为后台任务发给客户端执行，服务器轮询状态直至完成。

Prompts（提示模板）：simple-prompt（无参数静态消息）、args-prompt（city 必填 + state 可选）、completable-prompt（用 SDK 的 completable 助手演示参数自动补全，department 补全驱动 name 的上下文建议）、resource-prompt（返回内嵌动态资源的消息）。

Resources（资源 URI 空间）：

模式	URI 形态	说明
动态文本	demo://resource/dynamic/text/{index}	内容即时生成
动态二进制	demo://resource/dynamic/blob/{index}	base64 载荷即时生成
静态文档	demo://resource/static/document/<filename>	把 src/everything/docs/ 目录作为静态文件资源对外提供
会话级	demo://resource/session/<name>	工具运行期动态注册，仅存活于当前会话

其他协议特性：

• 资源订阅与通知：模拟更新默认关闭（opt-in），客户端用标准 resources/subscribe / resources/unsubscribe 订阅 URI；toggle-subscriber-updates 工具按会话开启/关闭定时器，只对已订阅 URI 发送 notifications/resources/updated，多客户端并发时各会话独立投递；
• 模拟日志：默认关闭，toggle-simulated-logging 按会话开启 8 个级别（debug ~ emergency）的随机日志，客户端可用标准 logging/setLevel 控制最低接收级别；
• MCP Tasks（SEP-1686）：服务器声明 tasks.list、tasks.cancel、tasks.requests.tools.call 能力；任务生命周期为 tools/call（带 task: true）→ 返回 CreateTaskResult（含 taskId）→ 客户端轮询 tasks/get 获取状态与 statusMessage → completed 后调用 tasks/result 取结果；状态枚举为 working / input_required / completed / failed / cancelled。Tasks 是双向的：tools/call 由服务器执行，而 sampling/createMessage、elicitation/create 可以由客户端作为后台任务执行（对应 trigger-*-async 工具）。

源码级机制：服务器工厂与条件注册

理解 Everything Server 最值得参考的是它的"服务器工厂"模式，核心在 server/index.ts：

1. instructions 从 docs 目录加载：createServer() 通过 readInstructions() 读取 docs/instructions.md 作为服务器指令——这解释了构建脚本为何要把 docs/ 拷进 dist/；
2. 能力声明：实例化 McpServer 时声明 tools、prompts、resources（含 subscribe: true）、logging 以及 tasks 能力，并注入 SDK experimental 提供的 InMemoryTaskStore 与 InMemoryTaskMessageQueue；
3. 注册顺序：registerTools(server) → registerResources(server) → registerPrompts(server) → setSubscriptionHandlers(server)，分别对应 tools/index.ts、resources/ 与 prompts/index.ts。

一个关键的细节是条件工具注册。由于客户端能力要在初始化握手完成后才可知，依赖特定客户端能力的工具不能一开始就注册。tools/index.ts 将注册拆成两半：

// 连接前注册的常规工具
export const registerTools = (server: McpServer) => { /* echo、get-sum 等 14 个 */ };

// 依赖客户端能力、须初始化后注册
export const registerConditionalTools = (server: McpServer) => {
  registerGetRootsListTool(server);
  registerTriggerElicitationRequestTool(server);
  registerTriggerUrlElicitationTool(server);
  registerTriggerSamplingRequestTool(server);
  registerSimulateResearchQueryTool(server);
  registerTriggerSamplingRequestAsyncTool(server);
  registerTriggerElicitationRequestAsyncTool(server);
};

而 server/index.ts 中把 registerConditionalTools 挂到 oninitialized 钩子上——握手完成后才补注册 get-roots-list、sampling、elicitation 与 tasks 系列工具；随后延迟 350ms 调用 syncRoots 同步客户端 roots（延迟是为了避开 notifications/initialized 处理期间请求丢失的时序问题）。这一"工厂返回 { server, cleanup } 二元组"的模式（cleanup(sessionId?) 负责停止模拟日志/资源更新定时器、清理任务存储与超时句柄）是多客户端会话隔离的基础，值得在自己的 MCP 服务器实现中借鉴。

验证与测试

该服务器自带完整测试套件（Vitest），覆盖注册关系、资源、提示词与服务器行为，测试文件位于 src/everything/tests/（如 registrations.test.ts）。在 src/everything 目录执行 npm test 即可运行（等价于 vitest run --coverage），这也是核对"文档所列工具与源码实际注册是否一致"的直接手段。

License

Everything Server 采用 MIT License 发布，可自由使用、修改与分发；具体条款以仓库 LICENSE 文件为准。