servers

千里之行，始于足下。——老子

Model Context Protocol Servers：让语言模型拥有工具与数据的参考样本库

项目地址：https://github.com/modelcontextprotocol/servers

当大语言模型需要真正参与工作时，仅靠一段对话往往远远不够。

它可能需要读取项目文件，搜索代码仓库，抓取网页内容，查看时间与时区，保存长期记忆，或者沿着一连串思考步骤处理复杂问题。模型本身擅长理解和生成语言，但它并不会天然拥有这些受控的外部能力。

Model Context Protocol 为这类连接提供了一种协议方式。

而 Model Context Protocol Servers 仓库，则收集了一批 MCP 参考实现。它们并不是面向所有生产场景的完整解决方案，而是用于展示 MCP 功能、官方 SDK 用法与服务设计模式的示例集合。

它像一座小型的工具实验室。

这里有读取网页内容的 Fetch，有进行安全文件操作的 Filesystem，有面向 Git 仓库的 Git，有持续保存知识图谱记忆的 Memory，有用于时间和时区转换的 Time，也有用于展示协议能力的 Everything 与 Sequential Thinking。

这些服务器共同展示了一件事：语言模型不必只能停留在聊天框中。通过 MCP，它可以在明确、可控的边界内接触工具与数据源。

MCP Server 到底是什么

MCP Server 可以被理解为模型与外部能力之间的一层服务接口。

语言模型通过 MCP 客户端连接服务器，再由服务器暴露工具、资源、提示词和其他协议能力。模型不需要直接理解每一种外部系统的内部细节，而是通过协议提供的方式发起受控调用。

这使得不同类型的能力可以被组织为统一接口。

一个服务器可以提供网页抓取。

另一个服务器可以提供文件系统操作。

还有一个服务器可以提供 Git 仓库读取、搜索与操作。

模型面对的不是杂乱的脚本集合，而是一组可以被发现、调用和组合的协议能力。

Model Context Protocol Servers 仓库中的内容特别强调参考实现定位。它们用于帮助开发者理解 MCP 功能和 SDK 的使用方式，也适合作为构建自定义 MCP Server 时的学习材料。

一组围绕真实任务的参考服务器

仓库目前列出的参考服务器覆盖多个典型方向。

Everything：把 MCP 的各种能力集中展示出来

Everything 是一个参考和测试服务器。

它的目标不是成为某个特定领域中最实用的工具，而是尽可能覆盖 MCP 协议中的功能。它实现提示词、工具、资源以及其他协议特性，因此很适合用于测试 MCP 客户端的能力。

对于正在构建 MCP 客户端的人来说，Everything 像一份可运行的协议检查表。

客户端是否能够读取资源。

是否能调用工具。

是否能识别提示词。

是否能正确处理不同的传输方式。

这些问题都可以在这个服务器中获得验证入口。

通过 npx 可以启动它：

npx -y @modelcontextprotocol/server-everything

如果希望从源码启动基于流式 HTTP 的服务，可以执行：

cd src/everything
npm install
npm run start:streamableHttp

作为已安装的软件包运行时，也可以明确指定不同运行模式：

npx @modelcontextprotocol/server-everything stdio

npx @modelcontextprotocol/server-everything sse

npx @modelcontextprotocol/server-everything streamableHttp

Everything 的价值不在于解决某一个具体业务难题，而在于把协议能力本身变得可观察、可测试、可学习。

Fetch：把网页内容转换为更适合模型处理的 Markdown

网页是模型工作时常见的信息来源。

但原始 HTML 往往冗长、杂乱，包含大量样式、脚本、导航和页面结构。对于模型来说，直接面对未经处理的网页内容，未必是高效的方式。

Fetch MCP Server 提供网页内容抓取能力，并将 HTML 转换为更适合语言模型处理的 Markdown。

它提供的核心工具是 fetch。

这个工具接收 URL，并能够设置最大返回长度、起始位置与是否返回原始内容。

• url 用于指定需要抓取的网址
• max_length 用于限制返回字符数量
• start_index 用于指定从哪个位置开始提取内容
• raw 用于请求未经 Markdown 转换的原始内容

其中，start_index 很有意思。

网页内容可能很长，而模型不一定需要一次读取全部内容。通过指定起始位置，模型可以按段读取网页，逐步获取后续内容，而不必让一次调用塞满上下文。

使用 uvx 启动 Fetch Server：

uvx mcp-server-fetch

也可以通过 pip 安装：

pip install mcp-server-fetch
python -m mcp_server_fetch

Fetch Server 还支持 Docker 方式运行。

它默认会根据请求来源处理 robots.txt：模型通过工具发起的请求会遵守网站的 robots.txt，用户通过提示词明确提出的请求则不受这一默认行为影响。该行为可以通过参数进行调整。

它还可以指定 User-Agent，并支持配置代理地址。

同时，README 也对 Fetch Server 给出明确提醒：服务器可能访问本地或内部 IP 地址，因此使用时需要注意不要暴露敏感数据。

这份提醒让 Fetch Server 的定位更清晰。工具扩展了模型能力，但能力边界仍需要被认真对待。

Filesystem：在可配置范围内操作文件

模型需要读取和处理文件时，最重要的问题之一是访问范围。

一个可以访问所有文件的工具也许很强大，但它的边界过于宽泛。一个完全不能访问文件的模型又无法参与实际项目工作。

Filesystem Server 提供的方向是安全文件操作，并允许配置访问控制。

它展示了 MCP 如何让模型接触本地文件，同时将可访问范围纳入配置之中。

在客户端配置中，可以为 Filesystem Server 指定允许访问的路径：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/allowed/files"
      ]
    }
  }
}

这里的路径并不是装饰性参数。

它代表模型能够在什么范围内处理文件。通过将授权目录作为明确配置，文件访问能力不再是模糊的默认权限，而是可以被清楚指定的边界。

Git：让模型理解仓库，而不只是读取零散文件

代码仓库不是普通文件夹。

它有提交历史，有当前状态，有分支，有差异，也有版本控制带来的上下文。单独读取几个文件，并不总能让模型真正理解项目正在发生什么。

Git Server 提供读取、搜索和操作 Git 仓库的工具。

它让模型可以在 Git 仓库这一层工作，而不是只停留在文件内容层。

通过 uvx 可以直接启动：

uvx mcp-server-git

也可以使用 pip：

pip install mcp-server-git
python -m mcp_server_git

在 MCP 客户端配置中，可以通过参数指定仓库路径：

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "path/to/git/repo"
      ]
    }
  }
}

当模型需要理解一个项目的版本状态、搜索仓库内容或围绕仓库开展工作时，Git Server 提供的是更贴近代码协作现场的工具入口。

Memory：让模型拥有基于知识图谱的持久记忆

一次对话结束后，模型通常不会天然保留上一次会话的工作记忆。

而很多任务并不适合每次都从头开始。

项目背景、实体关系、历史决策、关键约束、已确认的事实，如果全部依赖对话历史维持，长期使用时会变得脆弱。

Memory Server 提供基于知识图谱的持久记忆系统。

它让模型可以将信息组织成知识图谱形式，并在后续工作中继续使用这些关系。

启动 Memory Server 的方式十分直接：

npx -y @modelcontextprotocol/server-memory

将它配置进 MCP 客户端后，模型就拥有了一个独立的记忆服务入口：

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

这里的重点不只是保存文本。

知识图谱意味着信息可以通过实体与关系被组织。模型不必仅仅依赖一段段孤立笔记，而可以在持续积累中形成可关联的外部记忆结构。

Sequential Thinking：让复杂问题沿着思考序列展开

复杂问题往往不是一次推理就能稳定完成的。

有些任务需要提出假设，检查假设，修正方向，再继续向前。它们不是简单的一问一答，而更像不断折返、调整和反思的过程。

Sequential Thinking Server 展示的是动态且反思式的问题解决能力。

它围绕思考序列展开，让模型能够在处理复杂问题时，将推理过程组织为一系列可延展、可调整的步骤。

它不等同于给出某个固定答案，也不把问题解决限制为单一路径。它展示的是一种协议能力：模型可以通过连续的思考步骤，动态地推进与修正处理过程。

对于构建需要多阶段分析、规划或迭代推理的 MCP 应用来说，这类参考服务器提供了一个值得研究的方向。

Time：把时间和时区放进模型工具箱

时间看起来简单，但一旦跨越时区、地区和日期边界，就很容易出现误解。

Time Server 提供时间与时区转换能力。

对于需要处理不同地区时间、协调跨时区任务、转换时间表示的模型应用来说，这是一项直接而实用的基础能力。

它也提醒人们，MCP Server 不一定都要承担复杂的大型工作。一个边界清晰、能力明确的小工具，也可以成为模型工具体系中稳定的一环。

不同语言，不同 SDK，同一套协议思路

MCP 并不只面向某一种编程语言。

Model Context Protocol Servers README 列出了多个官方 SDK：

• C#
• Go
• Java
• Kotlin
• PHP
• Python
• Ruby
• Rust
• Swift
• TypeScript

这意味着开发者可以选择自己熟悉的技术栈来构建 MCP Server。

协议负责定义模型与工具之间的交互方式。

SDK 则帮助不同语言生态中的开发者更方便地实现这一协议。

仓库中的服务器通常基于 MCP SDK 实现，并通过这些示例展示具体开发方式。对于希望构建自定义服务器的人来说，语言并不是第一道门槛。关键在于理解服务如何暴露工具、资源和提示词，以及如何把外部能力放进清晰的协议边界中。

服务器单独运行，并不等于模型已经能使用它

MCP Server 启动后，还需要被配置到 MCP 客户端中。

这一步很关键。

单独启动一个服务器，只代表服务进程已经运行。要让语言模型实际发现并使用它，还需要将服务器信息写入客户端配置。

例如，将 Memory Server 配置给 Claude Desktop：

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

在 Windows 上，npx 需要通过 cmd /c 包装启动：

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

对于 VS Code，Everything Server 的配置也展示了类似思路。

可以将服务器配置放入用户级 MCP 配置，也可以放进工作区中的 .vscode/mcp.json，以便与其他协作者共享。

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

在 Windows 环境中，同样使用 cmd /c：

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

这种配置方式体现了 MCP 的一个重要特征：服务器与客户端是明确分离的。

服务器负责提供能力。

客户端负责连接、呈现和调度这些能力。

模型则在客户端允许的范围内使用它们。

从参考实现中看见 MCP 的扩展性

Model Context Protocol Servers 仓库中的服务类型并不相同，但它们指向同一个核心。

模型可以连接外部世界。

不过，这种连接不应是无边界的。

文件访问需要可配置范围。

网页抓取需要注意敏感网络地址。

Git 操作应当指向指定仓库。

记忆需要有持久化机制。

时间处理需要明确时区。

复杂思考可以被组织为连续步骤。

协议的作用，不只是提供调用格式，也是为工具能力建立一种更清晰的组织方式。

当模型通过 MCP 接入工具时，它不再只能回答“我建议你这样做”。在合适的客户端与授权配置下，它可以读取、检索、抓取、分析、记录和操作。

但每一种能力都可以被包装为独立服务，并拥有自己的运行方式、参数、访问范围与安全边界。

已归档服务器，也记录着能力演化的轨迹

仓库 README 还列出了已归档的参考服务器。

其中包括 AWS KB Retrieval、Brave Search、EverArt、GitHub、GitLab、Google Drive、Google Maps、PostgreSQL、Puppeteer、Redis、Sentry、Slack 与 SQLite 等方向。

这些服务器已迁移到单独的归档仓库中。

这份列表像一条能力演化的轨迹。

它说明 MCP Server 的应用范围并不局限于当前仓库中仍在维护的几个参考项目。数据库、搜索、浏览器自动化、协作工具、地图服务、代码托管平台与云端知识库，都曾经以参考服务器的方式展示过模型工具接入的可能性。

而当前仓库更专注于保留核心参考实现，让开发者能够更清晰地理解 MCP 的基础能力与官方 SDK 使用方式。

给构建者的一座起跑台

如果说模型是能够理解语言与任务意图的大脑，那么 MCP Server 更像是让它接触工具和数据的手脚。

它可以去读取网页。

可以在指定目录内处理文件。

可以理解 Git 仓库。

可以保存长期记忆。

可以进行时间换算。

可以沿着一串思考步骤推进复杂问题。

Model Context Protocol Servers 并不把这些能力包装成遥不可及的黑盒，而是以参考实现的方式摆在开发者面前。

你可以启动它们。

可以查看它们的配置。

可以观察它们如何通过不同 SDK 实现。

也可以以它们为出发点，构建自己的 MCP Server。

从工具调用到资源访问，从持久记忆到网页内容处理，这个仓库展示的并不是一组彼此孤立的服务，而是一种更具扩展性的模型应用图景。

语言模型可以继续擅长理解与表达。

而 MCP Server，则让它在受控边界中拥有行动的入口。