自定义 MCP 目录和配置文件：推动企业 MCP 采用

标题：创建自定义 MCP 目录和配置文件 | Docker

URL 来源：https://www.docker.com/blog/create-custom-mcp-catalogs-and-profiles/

发布时间：2026-05-15T06:00:00-07:00

Markdown 内容：

我们很高兴地宣布，用于管理模型上下文协议（MCP）服务器的自定义目录和配置文件现已全面可用。这两项互补功能从根本上改变了团队打包、分发和管理 AI 工具的方式。

自定义 MCP 目录让组织能够策展和分发经批准的 MCP 服务器集合。MCP 配置文件则让开发者个人能够轻松跨项目和团队构建、运行和共享他们的 MCP 工具及配置。

在本文中，我们将引导您创建自己的自定义目录——基于并改进我们先前的方法。我们还将介绍配置文件，这是一种新的基础构件，可让您定义可移植的、命名的 MCP 服务器分组。配置文件旨在解决当今的几个实际用例，同时为我们未来的扩展奠定基础。

使用 Docker 创建自定义目录

随着组织采用 MCP，我们反复听到同样的需求：团队需要一种方法来策展可信的 MCP 服务器列表，包括内部构建的服务器。

为了满足这些需求，我们构建了自定义目录。组织可以发布和分发定义已批准服务器的目录，而不是让每个团队成员在开放的互联网上搜索 MCP 服务器。这使得开发者能够在组织边界内集中发现和使用可信的 MCP 服务器。

自定义目录可以引用来自 Docker MCP 目录、社区来源以及内部开发的自定义 MCP 服务器的服务器，将灵活性、控制力和信任度融合在单一体验中。我们将通过一个自定义目录向您展示如何实现这一点。

逐步指南：构建和共享自定义 MCP 目录

在本示例中，我们将创建一个自定义目录，其中包含来自 Docker MCP 目录的服务器以及我们自己从 CLI 创建的 MCP 服务器。然后，我们将向您展示如何使用 Docker Desktop 导入该目录。

我们将展示的所有功能都可以通过 CLI 执行，而主要面向用户的功能子集则可以通过 Docker Desktop 执行。

在这里，我们将在命令中使用我个人的 Docker Hub ID roberthouse224，但您应根据需要替换为您的信息（例如，推送镜像时）。

步骤 1：创建我的自定义 MCP 服务器并将其推送到 Docker Hub

我们构建了一个名为 roll-dice 的参考服务器（GitHub 仓库）。它是一个通过 stdio 通信的常规 MCP 服务器，可以构建为 Docker 镜像。该镜像已经构建并推送到了 Docker Hub。

我们可以创建描述该服务器的元数据，包括镜像的位置，并将其保存到名为 mcp-dice.yaml 的文件中，以便在创建目录时使用。

name: roll-dice

type: server
image: roberthouse224/mcp-dice@latest
description: An mcp server that can roll dice

步骤 2：创建一个包含 Docker MCP 目录服务器及自建服务器的目录

现在我们可以创建一个自定义目录，其中包含来自 Docker MCP 目录的服务器以及我们自己创建的 MCP 服务器。

docker mcp catalog create roberthouse224/our-catalog \
  --title "Our Catalog" \
  --server catalog://mcp/docker-mcp-catalog/playwright \
  --server catalog://mcp/docker-mcp-catalog/github-official \
  --server catalog://mcp/docker-mcp-catalog/context7 \
  --server catalog://mcp/docker-mcp-catalog/atlassian \
  --server catalog://mcp/docker-mcp-catalog/notion \
  --server catalog://mcp/docker-mcp-catalog/markitdown \
  --server file://./mcp-dice.yaml

步骤 3：验证自定义目录中的 MCP 服务器

我们现在可以列出我们的目录并查看我们创建的目录

docker mcp catalog list

我们还可以检查目录的内容

docker mcp catalog show roberthouse224/our-catalog --format yaml

#### 步骤 4：共享目录

目前我们的自定义目录仅存在于我们的机器上。但我们拥有的是一个包含我们可信 MCP 服务器的不可变 OCI 工件，可以轻松共享——这一点非常强大。

我们可以将我们的目录推送到容器注册表，在这个例子中我们使用 Docker Hub。现在，任何能够访问您组织命名空间的人都可以访问该目录。

docker mcp catalog push roberthouse224/our-catalog

使用自定义 MCP 目录

现在我们的自定义目录已经共享，同事可以从 Docker Desktop 内部（或使用 docker mcp catalog pull 从 CLI）导入它。

通过选择“导入目录”，然后在对话框中指定 OCI 引用，从 Docker Desktop 导入目录。

图 1：从 OCI 引用导入自定义目录

现在可以浏览该目录了。您可以双击进入目录并查看其中包含的所有服务器。注意我们添加的名为“Roll Dice”的自定义 MCP 服务器。

图 2：Docker Desktop 应用程序中的自定义 MCP 目录，包括新添加的“Roll Dice”服务器。

要使其成为*私有*目录，您只需像往常管理容器镜像仓库的访问权限一样管理对该仓库的访问——无需管理新的基础设施或学习新的系统。

这正是 Jim Clark 在他的文章私有 MCP 目录与通往可组合企业 AI 之路中所描述的内容。

这种简单模式可以扩展以支持更复杂的用例。例如，您可以使用私有容器注册表替代 Docker Hub，或者连接到您自行托管的、通过可流式 HTTP 传输的远程 MCP 服务器，而不是像示例中那样运行容器化服务器。

既然我们已经拥有了可共享的、受信任的 MCP 服务器自定义目录，现在可以将重点转向个人如何在其工作流中有效利用我们构建的目录中的 MCP 服务器。

借助 MCP 配置文件，开发者可以高效地组织工作流，并为不同的用例维护独立的服务器集合和配置。配置文件可以在团队间共享，从而促进服务器设置的协作，并确保在同一项目或上下文中工作的团队配置一致。

切换配置文件

从根本上说，配置文件是一个命名的 MCP 服务器分组，可以连接到代理会话。这使得为不同的工作方式定义不同的配置文件变得简单明了。

现在让我们看一个实际示例。

我们创建一个名为 _coding_ 的配置文件，以及另一个名为 _planning_ 的配置文件。我们浏览自定义目录，选择所需的 MCP 服务器（例如 Playwright、GitHub 和 Context7），然后选择“添加到”下拉菜单，并选择“新建配置文件”。

图 3：选择要添加到新配置文件的 MCP 服务器

为配置文件命名，选择要连接的客户端，然后选择“创建”。

图 4：在 Docker Desktop 中创建名为 coding 的新 MCP 配置文件。

在配置文件选项卡中，我们可以看到刚刚创建的配置文件。我们的客户端已连接，工具已准备就绪。

图 5：连接到客户端的配置文件示例。

接下来，我们创建一个名为 _planning_ 的配置文件，其中包含与规划相关的服务器（例如 Atlassian、Markitdown、Notion）。

导航回“our-catalog”（如果尚未在此处），选择与规划相关的服务器，然后选择“添加到”->“新建配置文件”。为配置文件命名（例如 planning）。然后选择“创建”以创建不带客户端的规划配置文件。指定客户端是可选的。

图 6：创建多个配置文件的示例，包括独立的 coding 和 planning 配置文件

现在我们有了两个反映两种工作模式的配置文件。当我们切换到规划模式时，只希望规划配置文件中的工具处于上下文中。为此，我们可以轻松地将客户端重新分配到规划配置文件。

图 7：将 Claude Code 重新分配到规划配置文件。

如果我们回到编码模式，只需将客户端重新分配回编码配置文件。您可以拥有任意数量的配置文件来反映您的多种工作方式，并轻松在它们之间切换，仅保留您关心的工具在上下文中。

这不仅适用于 Claude Code，也适用于任何代理。配置文件提供了一种真正可移植的方式来管理您的 MCP 服务器设置，并避免供应商锁定。

持久化配置

您可以通过使用配置文件来避免重复配置 MCP 服务器。配置文件为 MCP 服务器配置添加了持久化层。当 MCP 服务器公开可配置选项时，您可以在配置文件中一次性定义它们，并根据需要重新加载，从而避免重复配置。

在此示例中，我们指定 Markitdown 可以访问的路径。

图 8：使用 MCP 配置文件保存服务器配置以供重用

当您使用的 MCP 服务器导出大量工具时，上下文窗口很容易被填满。通过配置文件，您可以指定启用哪些工具，确保仅使用特定任务所需的工具。

这里我们启用了 GitHub MCP 服务器的 get_me 工具，并禁用了所有其他工具。所有其他工具将不会出现在我们的代理会话中，也不会占用上下文窗口。

图 9：通过在 MCP 配置文件中仅启用所需工具来优化上下文窗口

这种保存配置的模式对于您内部构建的 MCP 服务器更为强大。通过公开更丰富的配置选项，您可以在项目间重复使用同一服务器，根据上下文重新配置其行为，并获得更可预测的结果。

共享配置文件

识别对项目有效的 MCP 服务器和配置不需要每个团队成员重复进行。一旦您找到了有效的设置，就可以与团队其他成员共享。

要共享配置文件，您可以将其作为 OCI 工件推送到容器注册表，就像我们处理自定义目录一样。只需为其提供名称以及 OCI 引用。

1➜~docker mcp profile push coding[your-namespace]/coding

对于其他人来说，要拉取它，只需执行相应的拉取命令。

1➜~docker mcp profile pull[your-namspace]/coding

尽管上面的示例演示了在团队间共享配置文件，但这一概念也自然地扩展到代理。例如，一个代理技能可以引用一个配置文件，并拉取所需的 MCP 服务器及其配置作为依赖项。

结论与下一步

随着 MCP 的普及，挑战不在于工具的访问，而在于协调。团队需要一种方法来标准化受信任和支持的内容，同时又不限制个人的实际工作方式。自定义目录和配置文件正是为解决这一问题而设计。

自定义目录：共享基础

自定义目录允许平台和管理团队定义经过批准的 MCP 服务器，将内部和公共工具捆绑在一起，并将这些选择作为单个可移植工件进行分发。这既创造了清晰度和一致性，又显著降低了发现和评估的成本。

配置文件：为工作流程注入强大动力

配置文件为个体开发者提供了一种轻量级的方式，可以为编码、规划或研究等特定场景组装、配置和重用 MCP 服务器。配置文件持久保存配置，将上下文限制在重要事项上，并使有效的设置易于在团队之间共享。

这些基础构件共同区分了：

• 组织的推荐内容（通过自定义目录）
• 人们的日常工作方式（通过配置文件）

这种分离实现了健康的平衡。平台团队可以发布建立标准和防护栏的“黄金路径”，而开发者保留适应、实验和组合适合其需求的配置文件的自由。

其结果是一个可移植、可组合且可扩展的系统——使 MCP 更易于采用、更安全地管理，并在整个组织中扩展时更加有效。

下一步是什么？

自定义目录和配置文件是规模化管理 MCP 的基础，而我们才刚刚开始。接下来，我们专注于扩展这些基础构件，以支持更强的治理、更好的重用和更高级的智能体工作流程：

• 治理和策略控制，将 MCP 使用限制在已批准的自定义目录和可信服务器源
• 改进目录和配置文件的可发现性和共享性，使经过验证的设置更易于在团队间查找和重用
• 扩展配置文件作用域的密钥和配置，为项目级 mcp.json 文件提供更安全灵活的替代方案
• 明确的配置文件最佳实践，包括保存动态 MCP 服务器配置以供重用，以及将配置文件与新兴的工作流程优化（如智能体技能）配对使用

开始使用自定义目录和配置文件

如果您拥有 Docker Desktop 4.56，您已经在使用目录——我们的 Docker MCP 目录现在作为 OCI 工件分发，并且从 Docker Desktop 4.63 开始支持配置文件。通过探索 Docker Desktop 中的 MCP 工具包 尝试创建您的第一个配置文件。

**了解更多**

• 深入阅读我们关于自定义目录和配置文件的文档，快速入门。
• 在我们的网站上探索 Docker 的 MCP 目录和工具包。
• 准备好动手实践了吗？打开 Docker Desktop 或 CLI，开始使用 MCP 来简化和自动化您的开发工作流程。