本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

MCP 托管策略

将可用工具抽象到 MCP 服务器中可使代理开发与可用工具脱钩。这引入了托管 MCP 服务器的位置以及这些服务器内部工具的组织方式等挑战。

托管方法

托管 MCP 服务器有三种选择：在终端用户计算机上本地运行、远程托管或通过 MCP 网关托管。每种选择都有优点和缺点。

本地托管

本地托管将 MCP 服务器作为子进程在本地计算机上运行，代理通过标准输入和输出流使用 JSON-RPC 与服务器通信。这种方法不需要在客户端和服务器之间进行身份验证。工具可以与本地应用程序和文件交互，使用本地存储的凭据，并继承用户本地计算机的网络访问权限。这是最简单的托管模式，有几个好处。

许多客户开始使用本地服务器使用 MCP。它们使工程师能够快速迭代并解决本地环境中的各种问题。假设一个 MCP 服务器连接到我们工程师的编码助手使用的 Git 存储库。将 MCP 服务器保存在本地非常有意义，因为它可以使用工程师的唯一凭据来访问存储库，并且不会向远程 MCP 服务器添加额外的网络调用。下图显示了在 IDE 中与编码代理一起使用的本地托管的 MCP 服务器。

对于这些类型的部署，您必须考虑 MCP 服务器是如何开发和分发的。大多数客户都会开发一个 MCP 注册表，最终用户可以在其中注册和下载服务器。它与容器注册表非常相似，用户可以在其中搜索特定功能并找到适合其需求的 MCP 服务器。

有公共 MCP 注册表，例如 MCP 官方注册表，还有私人托管的注册表。组织通常会将其 MCP 注册表策略与有关开源软件分发、容器注册表和内部包管理的现有政策保持一致。您应该考虑安全扫描、批准工作流程和合规性要求等因素。

但是，本地托管带来了组织应考虑的运营挑战。首先，最终用户必须独立发现、下载和配置 MCP 服务器。这可能会增加他们在本地使用的每个 MCP 服务器入门的复杂性。其次，您无法控制 MCP 服务器的生命周期，这意味着用户可能会继续在本地运行存在安全漏洞或缺少功能的过时版本。这可能会使满足合规性要求变得复杂。有些 IDEs 和 CLI 工具（例如 Kiro）允许组织管理和控制哪些 MCP 工具可用，从而确保团队之间的一致性和安全性。

远程托管

第二种选择是托管通过 HTTP 或 HTTPS 访问的远程 MCP 服务器。这允许访问任何联网的客户端。使用远程托管可以集中控制对 MCP 资源和功能的访问，实现身份验证和授权，以及控制 MCP 服务器逻辑的版本控制和更新。远程托管仍然需要使用 MCP 注册表，以便最终用户可以发现他们想要与代理一起使用的 MCP 服务器。下图显示了远程托管方法。

从代理开发的角度来看，无论是 MCP 服务器是本地服务器还是远程服务器，体验都是相似的。最重要的变化是实现身份验证和授权，包括代理对 MCP 服务器的访问和服务器对外部资源的访问。必须仔细规划远程 MCP 服务器的实现，以考虑多租户访问和权限管理。MCP 治理策略章节包含有关身份验证和授权注意事项的更多信息。

MCP 网关

最后一个选择是使用 MCP 网关。MCP 网关充当 MCP 客户端和服务器之间的集中代理，它们协调对已注册的 MCP 服务器的访问。如果没有网关，每个代理都需要注册它可能要使用的每台远程 MCP 服务器。网关允许代理连接到管理身份验证、授权、路由和协议转换的单个端点。可以动态添加新的 MCP 服务器和工具，并立即提供给代理。下图显示了 MCP 网关方法。

一些网关解决方案，例如 Docker MCP Gateway，还可以管理 MCP 服务器的生命周期，根据需要按需启动服务器。诸如 Amazon Bedrock AgentCore Gateway 之类的 MCP 网关还可以通过提供原生语义搜索功能来帮助管理工具发现。这为代理提供了与 MCP 客户端连接的单个端点，并有助于优化其上下文窗口的使用。结果是简单的代理，可以有效地选择和使用 MCP 工具。但是，它与远程 MCP 服务器方法具有类似的身份相关挑战。

托管 MCP 服务器的最佳实践