MCP基础设施正在重塑服务器接口

# MCP基础设施综述：MCP服务器不再是最终决策者

如果你正在为自己的产品构建MCP接口，用户实际使用它的方式很可能与你测试时的方式不同。你也许会暴露一个包含二十个工具的MCP端点，并假设代理会连接它、接收这二十个模式定义，然后直接调用它们。

但一个日益成熟的MCP基础设施层——专为规模化和生产环境而构建——可以改变这一交互的几乎每一个环节。你的服务器可能隐藏在另一个端点后面；它的工具可能与其他服务器的工具混合在一起；最终到达模型的工具定义可能只有寥寥几条。在某些架构中，模型得到的是搜索接口或编程接口，而非你发布的工具。

执行侧也在发生同样的事情。认证可能在请求到达你的服务器之前就已完成。另一个层次可能决定某个用户被允许看到哪些工具，而一次工具调用在真正执行之前可能会被拦截，以进行策略检查或人工审批。

其结果是，MCP服务器本身正在逐渐沦为一个实现细节。MCP服务器所发布的接口，正在与代理实际消费的接口相分离。中间的基础设施可以在你的服务器介入之前，就对发现、工具选择、认证和执行进行重塑。

这使得MCP接口更难测试，也更难控制。你不再能够假设代理在调用你的工具时会拥有什么上下文，甚至无法确定它是否会以你发布时的形态看到你的工具。以下是推动这一转变的各类架构。

## 多个服务器合并为单一端点

MCP服务器正在沦为实现细节，最明显的迹象之一是：代理不再需要为每个可用的服务器分别建立独立的MCP连接。Cloudflare的MCP服务器门户可以将多个远程MCP服务器置于单一门户端点之后，由门户维护与上游服务器的连接，并通过统一的MCP界面呈现各服务器的允许工具。（https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/）

当代理调用某个工具时，门户会判断哪个上游服务器负责该工具，并将请求代理过去。它还可以对工具进行命名空间隔离，以防止不同服务器暴露同名功能时发生冲突。即便是你的工具名称，也可能在到达代理之前被修改——而当你的MCP资源通过名称引用这些工具时，这一点尤为令人困惑。

Docker的MCP Gateway遵循同样的总体模式，TrueFoundry的MCP Gateway等虚拟MCP服务器实现也是如此。客户端连接到单一逻辑端点，由基础设施在底层跟踪管理各个物理服务器。（https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/）（https://www.truefoundry.com/docs/ai-gateway/mcp-gateway）

对于MCP提供商而言，你的端点可能被另一个基础设施组件消费和修改，而非由代理直接消费。

## 工具与实现它们的服务器相分离

将多个服务器置于单一端点之后，工具仍然是按照实现它们的服务器来分组的。另一类架构则进一步打破了这种关联。

微软的开源MCP Gateway是最典型的例子。其控制平面负责管理MCP服务器和工具，而其工具网关路由器（Tool Gateway Router）可以对外暴露单一的客户端侧MCP端点，并将每次调用路由到实现该工具的后端。（https://github.com/microsoft/mcp-gateway）

代理需要理解能力，但无需了解其背后的服务器拓扑结构。一台服务器可以向更大的目录贡献多个工具，而来自不同服务器的工具也可以同时出现。你现在应该假设，你的部分工具可能会与来自其他供应商的工具一起出现在代理的上下文中。

AWS AgentCore Gateway 还有另一种形式的这种分离。远程 MCP 服务器可以注册为网关目标，其能力既可以同步到网关中，也可以动态发现。（https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html）

不难看出这将如何影响代理行为。代理根据可用的操作集做出决策，而越来越多地，正是网关在塑造该操作集。最终，这将取决于可配置的规则和策略——它们决定了在何时公开哪些工具。

## 全新的发现管道

随着越来越多的面向代理的接口在服务器之外被组装，发现也开始得更早。MCP 为客户端提供了一种在连接服务器后发现工具的直接方式。在更大规模下，多个发现决策现在在此之前就已经发生。

官方 MCP Registry 致力于回答一个问题：哪些 MCP 服务器首先存在？发布者注册关于公共服务器的元数据，而客户端和聚合器可以在不必事先知道每台服务器位置的情况下搜索目录。（https://modelcontextprotocol.io/registry/about）

找到一台服务器并不意味着代理应该立即连接到它。组织可能会首先决定该服务器是否受信任，然后特定环境再决定它是否应该对代理可用。

Docker 的实验性 Dynamic MCP 更进一步。代理不需要一开始就配置好每台服务器。它可以在会话期间搜索可用的 MCP 目录，并在任务需要时附加服务器。（如果这听起来很像 A2A 发现，我同意。）（https://docs.docker.com/ai/mcp-catalog-and-toolkit/dynamic-mcp/）

工具发现可以在此之后发生，即便如此，模型也可能不需要来自每台已附加服务器的每一个工具。服务器发现、服务器附加和工具发现正在成为独立的阶段。

因此，一个 MCP 服务器可以存在于组织的目录中而不必附加到代理，也可以在附加之后而不将其所有工具纳入模型上下文。

## 工具定义作为检索到的上下文

将数百个工具聚合在一个 MCP 端点后面解决了连接问题，但如果每个工具定义都被加载到模型上下文中，则会产生另一个问题。

PayPal 描述了一个内部系统，该系统在大型 MCP 服务器集群中索引了超过 2,000 个工具。它不是向模型提供每个工具定义，而是公开 `tool_search` 和 `execute_tool`。模型搜索所需的能力，然后从更大的目录中接收相关定义。PayPal 报告称将工具模式上下文从 140,200 个 token 减少到 1,300 个 token。（https://arxiv.org/abs/2608.23992）

这种搜索和执行模式现在开始无处不在。

Solo.io 的 agentgateway 通过搜索模式实现了类似的架构。网关向模型提供 `get_tool` 和 `invoke_tool`，而不是呈现每个上游工具。（https://docs.solo.io/agentgateway/standalone/latest/documentation/mcp/tool-mode/）

Cloudflare MCP 门户可以通过在更大的目录上公开搜索和执行工具来实现类似的功能。（https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/）

重要的是，一个工具描述可能首先需要帮助搜索系统将该工具与数千个备选工具区分开来，然后在检索之后帮助模型正确使用它。你的工具未必会与来自同一产品的其他二十个工具并排放置。它可能位于一个包含数百个产品能力的索引中，只有当检索系统判定其相关时，才会进入上下文。

## Tools As a Programming Interface

到目前为止，你可能已经听说过 Code Mode 和 MCP，这是你的工具定义在代理看到之前被修改的另一种基本方式。它也改变了工具被使用的交互模式。

Solo.io 的 Code Mode，以及其他 MCP 栈中类似的 Code Mode 实现，可以用单个 run_code 工具替换上游 MCP 工具。Agentgateway 从调用方可用的 MCP 能力生成类型化的 JavaScript API，模型则针对这些 API 编写程序。（https://docs.solo.io/agentgateway/kubernetes/latest/documentation/mcp/tool-mode/code-mode/）

在普通工具调用中，模型可能先调用一个工具，检查结果，然后再调用另一个。而在 Code Mode 中，它可以编写一个程序，执行多次调用并在返回任何结果给模型之前对中间结果进行转换。

Cloudflare 也在 MCP 门户中加入了 Code Mode。模型获得搜索和代码执行工具，而门户则提供对上游 MCP 能力的类型化访问。（https://developers.cloudflare.com/changelog/post/2026-03-26-mcp-portal-code-mode/）

MCP 服务器仍然发布工具，但模型看到的是由这些工具生成的编程库。这无疑改善了 token 使用量和模型往返次数，但代价是对工具使用的语义进行了轻微的改变。

## Identity vs. Credentials

直连 MCP 连接具有相当简单的认证模型。客户端向服务器进行身份验证，服务器收到代表调用方的凭证。

共享 MCP 基础设施可以将其拆分为多个认证关系。Cloudflare 门户将对门户的认证与对上游服务器的认证分离，而门户管理这些下游调用所需的凭证。

AWS AgentCore 支持 OAuth 代理令牌交换（on-behalf-of token exchange），以实现这一架构的更显式版本。客户端提交一个面向 AgentCore Gateway 的令牌，AgentCore Identity 将其交换为另一个面向下游资源的令牌。（https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.html）

因此，网关两侧可以使用不同的凭证，同时保留原始调用方的身份。每个下游服务可以收到其预期的 audience 和 scope，而无需将可复用的凭证交给代理。

对于发布 MCP 的产品而言，这意味着你的 OAuth 边界可能成为更大身份系统中的一个内部跳转节点。这也意味着你不能假设你的 OAuth 交互是直接与发起工作的客户端进行的。如果你试图将 OAuth 流程与特定的产品行为绑定，这条界线现在已经变得模糊。

## Intent Separates From Execution

即使模型决定调用某个工具，中间的基础设施现在也可以阻止该调用立即（或永远）到达 MCP 服务器。中间的基础设施可以先做出额外的决策。

Cloudflare 可以将 MCP 门户流量通过 Cloudflare Gateway 进行路由，HTTP 策略和 DLP 控制机制能够检查流向上游 MCP 服务器的数据。包含敏感信息的请求可以在服务器接收之前被拦截阻断。(https://developers.cloudflare.com/changelog/post/2026-03-20-mcp-portal-gateway-routing/)

人工审批可以嵌入同一路径。TrueFoundry 的 MCP Tool Approvals 能够在网关层面拦截特定的 tools/call 请求，创建一个待审批状态，并仅在审批通过后才转发调用请求。(https://www.truefoundry.com/blog/mcp-tool-approval-human-gate-call-path)

这在多个环节创造了可以阻止尝试性操作的检查点。一个工具可以对用户隐藏，一次调用可以通不过授权验证，或者一个有效请求可以被暂停等待审批。

智能体决定它想做什么，而基础设施决定该操作是否被允许执行。当一个 tools/call 请求到达你的服务器时，它可能已经经历了多层检查与审批。

## 如何在基础设施转型中生存

如果智能体所看到的界面可以由基础设施来组装，那么 MCP 工具的设计就应当能够在这种转型中保持健壮。工具名称和描述需要在脱离你自己服务器语境的情况下依然清晰明了。Schema 应足够明确，以支持检索和代码生成。工具边界应体现独特能力，而非预设某个特定客户端会如何呈现它们。

你很可能还需要改变测试工具的方式。仅测试 Claude 或 Codex 与你的 MCP 服务器之间的直连已经远远不够。还需测试以下场景：你的服务器与其他服务器被聚合时会发生什么，只有部分工具被检索时会发生什么，工具名称被加入命名空间时会发生什么，以及调用请求经过外部授权或审批时会发生什么。

如果你的工具只有在模型看到完整的工具目录、且原始描述原封不动时才能正常工作，那么在当前围绕 MCP 逐渐成形的架构中，它们可能会显得十分脆弱。

这带来的实际启示是：将你的 MCP 接口更多地视为一份能力契约，而非一个已完成的用户界面。让每个工具都具备独立可理解性和自包含性，尽量收窄对认证方式的假设，避免依赖特定客户端的呈现方式或工具排列顺序。

你所发布的接口，将越来越多地成为一个"原材料"——被组装成另一个更贴合特定智能体、特定用户或特定任务需求的新界面。