Docker MCP Toolkit 怎么切换 Profile：服务器隔离、默认配置与状态核对

如果你在 Docker Desktop 里同时给代码项目、数据分析和文档检索配置 MCP 服务器，最容易遇到的问题不是“服务器能不能启动”，而是不同项目共享了不该共享的工具。Docker MCP Toolkit 的 Profile 就是为这个边界准备的：每个 Profile 保存一组独立的服务器与配置，切换 Profile 后，客户端看到的工具集合也随之改变。

先在 Docker Desktop 的 MCP Toolkit 中创建并选中目标 Profile，再到 Profile 详情核对 Servers 和 Tools；没有显式指定 Profile 时，Gateway 使用名为 default 的配置。

先确定 Profile 要解决的任务边界

本文只处理一个具体任务：在 Docker Desktop 的 MCP Toolkit 中创建或切换 Profile，并确认它隔离了哪些服务器。Profile 不是 MCP Catalog，Catalog 是可选择的服务器目录；Profile 更像项目级工具箱，保存你已经选中的服务器、配置和客户端连接。

官方文档把 Profiles 标为 Early Access，并要求 Docker Desktop 4.63 及更高版本。第一次操作时建议先准备两个清晰的名称，例如 web-dev 和 data-analysis，这样切换后从服务器数量和 Tools 列表就能看出差异。不要把访问令牌、账号切换当成本文的验证项：OAuth credentials 在不同 Profile 之间共享，这是官方特别说明的例外。

步骤一：进入 Docker Desktop 的 Profiles 入口

打开 Docker Desktop，左侧选择 MCP Toolkit，进入后点击顶部的 Profiles 标签。不要先在 Catalog 里勾选服务器；Catalog 负责浏览可用服务器，而本次任务的起点是 Profile 列表。

进入成功的可见信号是页面出现 Profiles 列表或创建入口。如果没有 Profiles 标签，先检查 Docker Desktop 版本以及 MCP Toolkit 是否可用；不要用 Catalog 页面代替 Profile 页面继续操作。

步骤二：创建一个可识别的新 Profile

在 Profiles 标签点击 Create profile，在名称字段输入 web-dev。创建对话框允许你现在搜索并添加服务器，也允许先只创建空 Profile，之后再补服务器和客户端。为了先验证隔离边界，建议第一次只填名称，然后点击 Create。

保存成功的判断不是弹窗消失，而是新 Profile 出现在 Profiles 列表中。点击 web-dev 进入详情，Overview 页面应能看到 Servers、Secrets configuration 和 Connected clients 等区域；空 Profile 没有服务器也不代表创建失败。

步骤三：切换 Profile 并核对服务器集合

在 Profiles 列表点击另一个 Profile，例如 data-analysis，再返回 web-dev。每次切换都要进入对应详情页观察，而不是只看顶部名称。官方界面把详情分为两个标签：Overview 展示服务器、Secrets configuration 和已连接客户端；Tools 列出这些服务器提供的工具，并允许单独启用或停用。

这里有两个容易混淆的结果。第一，Profile 之间的服务器和配置是隔离的，同一个服务器可以加入多个 Profile，但每个 Profile 可以有自己的配置。第二，OAuth credentials 不跟随这个隔离边界；如果不同项目必须使用不同账号，需要单独撤销并重新授权。

如果要增加服务器，路径是 Profiles > 选择 Profile > Servers 区域的 + 按钮，搜索后选择服务器。也可以回到 Catalog 标签，勾选服务器，再从下拉菜单选择要加入的 Profile。添加完成后回到目标 Profile，确认 Servers 列表出现它，再到 Tools 标签检查工具是否被启用。

步骤四：用官方 CLI 复查默认配置与指定配置

界面核对完成后，可以用 Docker 官方文档中的 CLI 命令做一次更明确的验收。命令只读取 Profile 结构，不需要把真实密钥写进文章或命令行。

docker mcp profile list
docker mcp profile show web-dev
docker mcp gateway run --profile web-dev

profile list 应列出刚创建的 Profile；profile show web-dev 用来核对服务器与配置；Gateway 命令显式指定 web-dev 后，只使用该 Profile 的服务器。如果省略 --profile，官方规则是使用 default Profile；升级旧版 MCP Toolkit 时，既有服务器配置会自动迁移到 default。

验收时可以把“当前选中的 Profile”和“Gateway 实际使用的 Profile”分开看：前者由 Desktop 的 Profiles 页面决定，后者由客户端连接配置或 Gateway 的 --profile 参数决定。两者名称不一致时，界面看似切换成功，客户端仍可能访问另一组工具。

常见问题：切换后为什么看不到预期工具

为什么两个 Profile 里出现了同一个服务器？

服务器可以加入多个 Profile，这本身不表示隔离失效。重点是分别检查每个 Profile 中的配置值、Tools 启用状态和客户端连接；Profile 隔离的是各自的服务器集合与设置。

没有指定 Profile 时到底使用哪个？

Docker MCP Gateway 在没有显式参数时使用名为 default 的 Profile；如果不存在，则使用空配置。需要项目级工具集合时，在 Gateway 或客户端配置中明确写出目标 Profile。

重启 Docker Desktop 后配置会消失吗？

官方 Profiles 文档说明配置会持久化在 Docker 安装中，重启 Docker Desktop 或系统后，Profile、服务器和配置仍会保留。重启后回到 Profiles 详情和 Tools 标签检查即可。

最后的验收清单

完成后按下面顺序快速复查：一是确认 Docker Desktop 版本满足 MCP Profiles 的要求；二是确认入口为 MCP Toolkit > Profiles；三是确认新 Profile 出现在列表并能打开 Overview；四是分别查看 Servers 与 Tools，确认服务器集合和工具启用状态；五是核对客户端或 Gateway 是否明确使用了目标 Profile；六是记住 OAuth credentials 共享这一例外，不要把它误判成服务器配置串线。

这样处理后，Profile 的价值就很清楚了：按项目切换工具箱，按详情页确认实际集合，再用显式的 --profile 参数避免客户端连接到错误的默认配置。

官方参考

Docker MCP Profiles、Docker MCP Catalog、Use MCP Toolkit from the CLI。