企业官网建设流程全解析

搞 AI 应用开发的人，最近应该都被“MCP”这个词刷屏了。社区里到处都在聊 MCP Server，IDE 接 MCP，数据库接 MCP，连设计工具、支付平台都开始把自己的能力封装成 MCP 服务。但你有没有想过一个问题：当你想真正接入一个 MCP Server 的时候，第一个麻烦往往不是不会配置，而是不知道去哪找、怎么选、哪个才是靠谱的。

Github 上搜出来的结果又多又杂，官方文档推荐的列表又不够全，Reddit 和 Hacker News 上的讨论倒是信息量大，可要把散落的链接梳理成可以直接用的配置文件，仍然要花上不少时间。最近 Hacker News 上出现了一个叫 AllMCPs 的项目，标题很直接——Directory of MCP Servers。从名字就能看出来，它想做的是 MCP 生态的“黄页”或“大全”。这类目录项目为什么会在现在集中出现？它到底解决了什么问题？又该怎么把它用好？

这篇博客会从 MCP 生态的真实痛点讲起，先解释 MCP 协议的核心机制，再分析 AllMCPs 这类目录项目的价值边界，最后用实际配置示例和排错清单，帮你把“找到合适的 MCP Server”这件事真正落地。

1. 这篇文章真正要解决的问题

MCP 现在的热度，很像 Kubernetes 刚兴起时的早期阶段。协议本身是好的，生态也在快速膨胀，但开发者使用起来的第一道门槛，不再是“协议能不能通”，而变成了“我能用什么、我用哪个”。

这里有一个很反直觉的事实：MCP 已经诞生两年多，但它的“可发现性”仍然处于非常原始的状态。你可以在 Github 上用mcp server这个词搜出成千上万个仓库，也可以翻遍各大官方文档找到十几条经过审核的服务器列表，但当你面对的实际问题是“我想让 Agent 直接查 PostgreSQL，还想让它能调用 Figma 的设计稿信息”，你需要的不只是搜索结果，而是一个分类清晰、信息完整、能直接让我判断“这个能不能用、怎么装”的索引。

AllMCPs 正是在这个节点出现的。它的定位很简单：收集、分类并展示 MCP Server 的信息，让开发者从“大海捞针”变成“按图索骥”。但这类目录项目也有几个必须回答的问题：

• 收录标准是什么？是自动抓取还是人工审核？
• 分类维度怎么做？按领域、按客户端还是按协议传输方式？
• 会不会收录大量低质量、过期甚至不再维护的仓库？
• 是否给出实用的配置示例和版本兼容信息？

所以这篇文章不仅是介绍 AllMCPs 这个项目本身，更是要讲清楚 MCP Server 目录这个品类，以及作为开发者，你该如何利用目录去提高自己的选型效率。

1.1 最应该读这篇文章的人

如果你属于以下三种情况，这篇文章很适合你：

• 刚开始接触 MCP，想知道 MCP Server 到底有哪些类型，从哪里获取；
• 已经在用 Claude、Dify、Codex 等工具，想接入更多第三方能力，但不知道如何高效检索和判断；
• 准备自己开发 MCP Server，想了解当前生态里哪些赛道已经拥挤、哪些方向还有空间。

2. MCP 协议的核心概念与原理

在讲目录项目之前，先把 MCP 的最基本概念捋清楚。因为如果你不了解 MCP 的工作原理，面对再好的目录也无从下手。

2.1 MCP 是什么

MCP（Model Context Protocol，模型上下文协议）是一个开放协议，用于标准化 AI 应用与外部数据源、工具之间的交互方式。它最早由 Anthropic 提出，后来逐渐被 OpenAI、Google、Microsoft 等生态接纳，形成了行业内比较少见的“跨厂商共识”。

通俗理解，MCP 之于 AI Agent，就像 HTTP 之于 Web 应用。在 HTTP 出现之前，每个客户端要连接每个服务器，都需要一套自己的协议；HTTP 出现之后，浏览器和服务器只需要遵守同一种语言就能通信。MCP 想做的是同一件事：让 AI 应用和外部工具，用同一种标准化的语言交换信息和命令。

2.2 MCP 的组成角色

一个完整的 MCP 架构包含四个角色：

这四个角色的关系可以类比成：Host 是你的电脑，Client 是浏览器，Server 是网站服务器，Transport 是网络协议。用户通过 Host 发起请求，Client 把请求翻译成 MCP 协议规定的格式，通过 Transport 传给 Server，Server 执行实际逻辑后返回结果。

2.3 三个核心抽象：Tool、Resource、Prompt

MCP 定义了三个基础原语，几乎所有 MCP Server 都在围绕它们做文章：

• Tool（工具）：可被模型调用并执行操作的函数。比如query_sales_data、create_jira_ticket。Tools 是 MCP 里最常用的能力，相当于给了 AI 一双可以操作真实系统的“手”。
• Resource（资源）：可供模型读取的结构化数据。比如数据库 schema、配置文件内容、日志文件。Resource 解决的是“模型如何获得上下文”的问题。
• Prompt（提示词模板）：可复用的提示词模板，让用户通过一个简短命令就能触发复杂的工作流。

从目录的角度看，一个 MCP Server 背后往往兼有多种能力。比如一个数据库 MCP Server，它既可以提供 SQL 执行 Tool，也可以把表结构暴露为 Resource，还可以预置几个分析数据的 Prompt 模板。因此目录的分类不应该是“一个服务器只有一个标签”，而应该是一个服务器对应多个能力维度。

2.4 容易混淆的概念：MCP 与 Agent Skill

最近还有一个概念经常被放在一起比较：Agent Skill（智能体技能）。有些读者会遇到“agent skill 和 mcp 有什么区别”这样的搜索问题。

从设计目标上看：

• MCP 强调的是“能力接入”。它解决的是 Agent 怎么调用外部系统、怎么获取外部数据，是一种标准化的集成方式。
• Agent Skill 强调的是“任务封装”。它更偏向于把一个完整的任务流程、提示词、工具调用链封装成一个可复用的“技能包”。

你可以这样理解：MCP 是接口标准，Skill 是组织方式。实际项目中两者经常搭配使用，一套 MCP Server 提供了基础能力，Agent Skill 再在其上编排业务逻辑。

3. AllMCPs 的定位与目录项目的价值

接下来的问题很自然：既然 MCP 协议本身很清晰，为什么还需要一个目录项目？

3.1 没有目录时，开发者都经历过什么

在没有 AllMCPs 这样的索引之前，一个普通开发者想给自己的 Claude Desktop 加一个“能读取本地文件”的能力，标准流程是这样的：

1. 打开搜索引擎，输入“MCP server file system”；
2. 在搜索结果里翻到 Github 仓库，查看 star 数量、最近更新时间、README 质量；
3. 确认这个仓库还活着，看它是使用 TypeScript SDK 还是 Python SDK；
4. 阅读安装说明，确认运行方式是npx、uvx还是 Docker；
5. 打开 Claude 配置文件，手工填写command、args、env；
6. 重启客户端，测试是否生效。

每一步都不难，但每一步都有信息损耗。特别是当你要接入五六个 MCP Server 时，光是搜集和比对信息就能消耗一个下午。目录项目正是来压缩这段耗时的。

3.2 AllMCPs 这类目录应该提供什么

从社区需求来看，一个合格的 MCP Server 目录至少应该提供这些维度：

AllMCPs 从这个角度切入，本质是在做“基础设施之上的基础设施”。它不是 MCP 协议本身，也不是 MCP Server 的实现，而是让整个生态从“能跑”变成“好用”的信息枢纽。

3.3 目录项目自身的局限

也需要冷静看待。任何目录项目都会面临三类问题，AllMCPs 也无法绕开：

• 时效性：MCP 生态更新太快，一个 Server 可能这周很火，下周就被更好的替代。目录要跟上节奏，需要投入持续的人力或爬虫工程。
• 质量审核：自动收录会混入大量实验性项目，人工审核又很难覆盖全量。目录的价值取决于它的筛选标准，而不是收录数量。
• 商业化压力：目录项目做到后期，很可能走上推荐排序的商业模式。届时如何保证排序公正，会是一个考验。

因此，目录只能作为你选型的第一站。真正装到本地之前，你还是要自己看一眼源码、跑一次测试。

4. MCP Server 生态的常见分类

为了让目录检索更高效，也为了帮助读者建立全局观，这里梳理一下 MCP Server 生态的主要赛道。你在 AllMCPs 这类目录里看到的大部分服务器，基本都能归入下面几类。

4.1 数据库与数据管道类

MCP Server 最成熟、应用最广的领域。典型能力包括：

• 连接 PostgreSQL、MySQL、SQLite，执行 SQL 查询；
• 获取数据库健康指标、分析慢查询；
• 读取数据仓库表结构，生成数据字典。

在dify mcp 怎么使用、workbuddy 通过 mcp 直接访问数据库这些搜索词背后，用户真正需要的就是让 Agent 能安全地查询和解析数据库内容。

4.2 浏览器自动化与网页抓取类

Playwright MCP Server 是这个赛道里的明星项目。它让 LLM 能自动操作真实浏览器，完成网页导航、表单填写、数据提取、页面截图等任务。对测试工程师和需要做网页数据采集的开发者来说，这类 MCP Server 直接改变了原来的自动化脚本编写方式。

这类 MCP 的坑在于：它不是纯读操作，而是会真实打开浏览器并操作系统资源，因此沙箱和权限设计非常关键。

4.3 设计工具与内容生成类

Figma MCP Server 是另一个高频词。它的价值在于：设计师在 Figma 里完成设计稿后，开发者可以直接让 Agent 读取设计稿的结构、颜色、组件信息，生成对应的前端代码或样式文件。这打通了设计到开发的最后一公里。

同样类型的还包括各类文档、知识库同步工具。它们解决的核心问题是：把 AI 无法感知的二进制或富文本内容，转换成模型可以理解的文本上下文。

4.4 开发工具链与 IDE 集成类

这个类别覆盖 Java、C#、MATLAB、IDAPython 等专业工具链。比如java mcp server 搭建、c# mcp这类搜索词，说明很多后端开发者已经在尝试把自己的业务服务包装成 MCP 格式。

这类 MCP Server 往往不只是“给 AI 用”，也是在建立一套新的服务集成方式。开发者通过标准协议暴露出内部 API，让多个 AI 客户端都能调用。

4.5 支付、搜索与第三方服务类

支付平台（如支付宝）提供服务端 MCP，搜索厂商提供搜索 MCP，云厂商提供资源管理 MCP。这些大型平台开始以 MCP 作为面向 AI 应用的开放接口，意味着 MCP 生态正从开发者社区自发生长，走向商业平台主动适配的阶段。

对个人开发者来说，这类服务器通常文档更齐全、安全边界更清晰，反而值得优先尝试。

5. 环境准备与前置条件

无论你是从 AllMCPs 目录里找到一个 MCP Server，还是准备自己开发一个，都需要先确认本地环境满足基本要求。

5.1 运行环境

MCP 是传输层与语言无关的协议，因此理论上任何语言都能实现 MCP Server。但当前生态里最主流的 SDK 是 TypeScript（@modelcontextprotocol/sdk）和 Python（mcp库），其他语言 SDK 也在快速成熟。

如果你是普通使用者，只需要满足：

• 目标客户端能正常使用（Claude Desktop、Dify、Cursor、Codex 等）；
• 本地装有对应的运行时（Node.js 或 Python 环境）；
• 没有本地环境的，优先选择 Docker 方式的 MCP Server。

5.2 版本问题

MCP 协议仍在快速演进。从早期版本到现在的稳定版本，传输方式从 stdio 扩展到了 HTTP + SSE，最新的 Streamable HTTP 也让远程 MCP 变得更容易配置。

这里要特别提醒：在复制目录或仓库中的配置命令时，先确认协议和 SDK 版本是否与你使用的客户端版本匹配。不同版本的配置语法差异，很容易导致“配置看起来没问题，但连接一直失败”。

5.3 依赖管理方式

大多数 MCP Server 的安装方式属于这两类：

• npx：Node 生态包管理工具，适合 TypeScript 编写的 MCP Server；
• uvx：Python 生态的快速运行工具，适合 Python 编写的 MCP Server；
• Docker：适合需要隔离环境、有系统依赖的 MCP Server。

用npx的好处是无需手动管理目录，坏处是首次启动会让模型自动下载依赖，需要网络可达；用 Docker 的好处是环境干净，坏处是每增加一个 MCP Server，都会额外占用一个容器的资源。

6. 从目录到运行：完整配置示例

这一节进入实操。我们以 AllMCPs 目录中常见的“文件系统 MCP Server”和“数据库 MCP Server”为例，演示从目录检索到本地配置的完整流程。

6.1 步骤一：从目录里找到目标 Server

假设你在 AllMCPs 官网搜索框输入postgresql，结果列表会显示若干个候选项目。选型的快速判断标准有四点：

1. 最近更新时间是否在 3 个月以内；
2. 是否有明确的功能描述和配置文档；
3. star 数量虽然是参考，但几百个 star 的项目并不一定比几十个的更靠谱；
4. 是否给出已知问题或限制说明。

6.2 步骤二：在 Claude Desktop 中配置 MCP Server

Claude Desktop 是目前配置 MCP 最直接的客户端之一。它的配置文件位于：

• Windows：%APPDATA%\Claude\claude_desktop_config.json
• macOS：~/Library/Application Support/Claude/claude_desktop_config.json

如果配置文件中还没有 mcpServers 字段，可以手动创建。以下是一个典型的文件系统 MCP 配置：

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/Documents" ] } } }

关键参数说明：

• mcpServers：固定字段，表示这是一组 MCP Server 配置；
• filesystem：自定义名称，在客户端界面里会显示为可用工具的前缀；
• command：启动命令，可以是npx、uvx或本地二进制路径；
• args：命令参数，第一个参数通常是要安装运行的包名，后面的参数是传给该 Server 的配置。

保存后，重启 Claude Desktop。如果配置正确，你会在聊天界面看到新增的工具图标，并能在对话中让它读取指定目录下的文件。

6.3 步骤三：在 Dify 中配置本地 MCP 服务

Dify 是目前很多团队在使用的 LLM 应用开发平台。它支持在 Agent 应用里添加 MCP 工具。进入 Dify 的工作流或 Agent 编辑页面，在“工具”区域选择“自定义”或“通过 MCP 添加工具”。

Dify 支持两种连接方式：

• stdio：通过命令行启动本地 MCP Server；
• streamableHttp/sse：连接已经部署好的远程 MCP Server。

以本地 Python 编写的 MCP Server 为例，假设你的入口文件是server.py：

uvx --from mcp server.py

在 Dify 中填写命令时，通常需要写：

uvx --from mcp server.py

如果 Dify 的 MCP 表单要求分开填写命令和参数，则命令为uvx，参数为--from mcp server.py。

这里常见的问题是：Dify 容器环境和本机环境隔离，导致本机能跑的命令在 Dify 中找不到。解决方法是设置好环境变量，或直接用远程 HTTP 方式接入一个已经部署好的 MCP Server。

6.4 步骤四：配置远程 MCP Server

远程 MCP Server 是另一个高频场景。很多团队会把 MCP Server 部署到服务器上，然后让多个客户端共享。配置方式不再需要command和args，而改成 URL 方式：

{ "mcpServers": { "remote-db": { "url": "https://your-server.example.com/mcp", "headers": { "Authorization": "Bearer your-token" } } } }

这种方式的优势是：客户端可以很轻量，不需要安装 Node.js 或 Python 环境。需要注意的安全问题是，远程 MCP 暴露了 API 能力，必须使用 HTTPS 和 token 鉴权，不能裸奔在公网上。

6.5 步骤五：验证配置是否成功

配置完成后，建议按这个顺序验证：

1. 在客户端里重启应用，并打开 MCP 工具列表，确认看到新增 Server 名称；
2. 用一个最简单的提示词测试，比如“列出当前连接的文件系统中项目文件夹有哪些文件”；
3. 如果测试失败，查看客户端的运行日志，确认 Server 是否成功启动；
4. 如果是远程 MCP，用curl直接请求对应 URL，先排除网络和鉴权问题。

7. 运行结果与效果验证

为了让“配置成功”不再停留在口头判断，这里展示一个可复现的验证流程。

7.1 用命令行直接验证 MCP Server

无论客户端界面如何封装，MCP Server 本身的启动过程都会在命令行中留下痕迹。假设你使用的是@modelcontextprotocol/server-filesystem，首次启动时终端会输出类似这样的日志：

Starting MCP server... Server initialized with root directory: /Users/yourname/Documents MCP server listening on stdio

这表示 Server 已经通过 stdio 正常监听。如果在这一步就报错，大概率是 Node 版本不足、包名写错或目录权限不足。

在 Claude Desktop 的日志文件里，你通常能看到更明确的错误：

Failed to connect to MCP server "filesystem" Error: ENOENT: no such file or directory

如果看到ENOENT，优先检查args里的路径是否存在。如果看到Command failed: npx: not found，则说明客户端的PATH环境变量里没有 Node.js。

7.2 判断是否成功：以实际问答为准

配置完成后的最终判断标准不是“能看到 MCP 图标”，而是“Agent 真的能调用工具完成一次操作”。以文件系统 MCP 为例，你在对话里输入：

请查看 /Users/yourname/Documents 目录下有哪些文件，并按名称排序。

一个正常的响应应该包含文件列表和排序后的结果。如果 Agent 回答“我无法访问文件系统”或“当前没有可用工具”，说明 MCP 连接并没有真正生效。

7.3 失败后的诊断路径

按下面顺序排查，可以覆盖绝大多数问题：

1. 检查客户端日志，看 MCP 连接是否报错；
2. 在终端手动执行配置里的command + args，看能否正常启动；
3. 确认运行时环境，npx/uvx是否在全局 PATH 中；
4. 确认网络，使用npx时是否需要代理才能下载包；
5. 确认权限，本地目录是否允许读写；
6. 确认协议版本，远程 MCP 使用 HTTP 还是 SSE，客户端是否支持。

8. 常见问题与排查思路

这里整理了一张高频问题表，供实际开发时快速对照。

8.1 一个容易混淆的场景：上下文过大

在 MCP 使用过程中，“上下文过大”是高频报错，尤其当 Agent 同时连接多个 MCP Server、且每个工具都返回大量数据时。很多人会误以为是 MCP Server 坏了，其实这是因为把过多内容灌进了模型上下文窗口。

排查方向是：确认每个 MCP 工具返回的数据量是否过大，是否应该在客户端侧做截断或分页处理。这不是协议的 bug，而是使用姿势的问题。

8.2 注意“看起来正常但实际没生效”的情况

还有一种隐蔽的问题：MCP Server 配置正确、客户端日志无报错、工具列表也显示了，但模型就是不调用。这时候要检查两件事：

• 是不是当前对话模型本身不具备工具调用能力；
• 是不是提示词里把工具“禁言”了。

某些模型在长对话中会逐渐遗忘工具信息，这时可以通过显式提醒让模型重新调用。

9. 最佳实践与工程建议

9.1 选型时的“最小权限”原则

在目录里选 MCP Server 时，要遵循最小权限原则：只给 Agent 它必需的能力，不要为了“看起来更强”而一次性接入大量工具。

一个常见的反面案例是：给一个只需要查询数据库的 Agent 同时接入了文件系统、浏览器、支付等 MCP Server。这样做不仅增加了模型出错、调用错误工具的概率，也扩大了安全暴露面。如果你的 Agent 只需要读数据库，那就只配置数据库 MCP。

9.2 本地使用时的环境隔离

在本地使用 MCP 时，建议通过 Docker 或虚拟环境隔离依赖。尤其是那些由社区贡献、star 数量有限的项目，在跑起来之前，最好先读一遍源码或至少观察它的安装脚本。用npx -y拉取的包本质上都会在本地执行代码，这一点和npm install的安全风险没有本质区别。

如果公司对代码安全有严格要求，更稳妥的做法是：把 MCP Server 放到独立的容器或沙箱里运行，只暴露必要的端口，而不是直接以本机权限执行。

9.3 远程 MCP 的认证与审计

远程 MCP 是团队协作场景下的趋势。生产环境使用远程 MCP 时，必须做到：

• 使用 HTTPS，不暴露明文 HTTP；
• 使用 Token 或 OAuth 鉴权，不为方便而跳过认证；
• 为每个调用方分配独立 Token，便于操作审计；
• 在网关层记录调用日志，至少包含调用方、调用时间、工具名称和入参摘要。

9.4 监测与更新

MCP 生态更新速度极快，别把一个 MCP Server 当作永久不变的组件。为长期使用的 Server 建立版本维护机制，比如使用固定版本号而不是latest，定期查看维护者的 release 说明和 issue 列表。

在目录类项目中筛选时，同样要看更新时间。如果一个 Server 已经半年没有提交，它给出的配置示例很可能不再适用于新版 MCP 协议。

9.5 配置的统一管理

当团队里多个人都在使用 MCP 时，建议把配置文件纳入版本管理。可以单独建立一个小仓库，保存各客户端的claude_desktop_config.json、Dify 工具配置等，通过 CI 或脚本统一分发。这样做的好处是配置变更可追踪，新员工入职时直接 clone 即可获得一致的开发环境。

也可以使用环境变量区分不同环境的差异，避免把本机路径泄露到仓库中。

10. 总结与后续学习方向

从 MCP 协议的爆发到 AllMCPs 这类目录项目的出现，能清晰地看到一个技术生态走向成熟的轨迹：先是协议标准的确立，再是核心工具的涌现，然后是信息组织和筛选机制的出现。目录的价值不在于它显示了成千上万个一行链接，而在于它把开发者的“搜索成本”压缩成了“选择成本”。

回到实践层面，读完这篇文章你可以做到三件事：理解 MCP 协议的基本角色和原语，知道如何通过 AllMCPs 这类目录去检索和筛选 MCP Server，并且能够在 Claude Desktop、Dify 等客户端里完成本地或远程 MCP Server 的配置和排错。

下一步值得深入的方向有三个：一是把 MCP Server 的选型标准沉淀成团队规范，避免每个成员各自摸索；二是研究 MCP 服务端的鉴权与审计，尤其是远程部署时如何设计安全边界；三是结合 Agent Skill，把多个 MCP 工具编排成完整的业务能力，而不仅仅是“能调用单个工具”。

技术生态的演进从来不是单点突破，而是协议、工具、目录、治理共同成熟的过程。MCP 现在还处在“能用”到“好用”的过渡期，AllMCPs 这类目录的价值会随着生态膨胀而不断放大。建议你先从自己最常用的客户端入手，选一个数据库类或文件系统类的 MCP Server，把这个最小链路跑通。跑通之后，再慢慢扩展其他能力。