此内容没有您所选择的语言版本。
Chapter 1. Introduction to the MCP gateway
You can centralize and manage the connectivity for your agentic AI applications that access your Model Context Protocol (MCP) servers by using the MCP gateway.
MCP gateway is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
1.1. About the MCP gateway 复制链接链接已复制到粘贴板!
You can focus on your agentic AI systems without building networking into your application code by using the Model Context Protocol (MCP) gateway. Application teams and platform engineers can operate and collaborate to expose MCP servers with the MCP gateway as secure and protected services just as you do with existing RESTFul based APIs.
For example, you can achieve the following goals by using the MCP gateway to connect your MCP servers:
- Aggregate MCP servers behind a single endpoint.
- Grow your agentic AI applications at scale, keeping connectivity outside of application development.
- Manage access to and the security of AI tools and MCP servers.
The Connectivity Link implementation of the MCP gateway extends the benefits of the Envoy proxy server to your customized AI agent systems.
The Envoy proxy server handles traffic from agentic AI clients to your backend MCP servers at the gateway ingress. Envoy is a conformance-tested implementation of the Kubernetes Gateway API. By using the MCP gateway, you can extend the capabilities of Envoy without the complexity of manual configuration.
1.2. MCP gateway architecture 复制链接链接已复制到粘贴板!
The architecture of the Model Context Protocol (MCP) gateway builds on top of the routing capabilities of the Envoy proxy with capabilities to handle the MCP.
Design considerations include the following high-level goals:
- The MCP gateway must work with the Gateway API as a routing configuration.
- Envoy controls routing and traffic as the implementation of the Gateway API.
- The MCP gateway focuses on the MCP Protocol.
- Use Istio as the gateway control plane in OpenShift Container Platform with the Gateway API.
-
Connectivity Link is used for other key features, such as
AuthPolicyand rate-limiting custom resources.
1.2.1. MCP gateway architectural components 复制链接链接已复制到粘贴板!
The MCP gateway architecture consists of three components that manage connectivity: the router, broker, and controller.
- MCP router
The MCP router is an Envoy-focused
ext_proccomponent that is capable of parsing the MCP protocol. Whenext_procparses the MCP Protocol, the router uses the protocol to set headers to force the correct routing of the request to the correct MCP server.The MCP router component is responsible for the following activities:
-
Parsing and validating the
JSON-RPCrequest object, which is the MCP message body -
Setting the key request headers,
:authority,:path,x-mcp-method,x-mcp-servername,x-mcp-toolname, andmcp-session-id -
Watching for
404responses from MCP servers and invalidating the session store - Handling session initialization and storage on behalf of a requesting MCP client during a tools call request
-
Parsing and validating the
- MCP broker
The MCP broker manages the complexity of connecting to multiple AI services simultaneously for you. The broker component aggregates multiple backend MCP servers and presents them as a unified MCP server to clients. This means that your MCP clients or applications do not have to manage a large set of MCP servers and configurations for each server.
The MCP broker component is a backend service that acts as a default MCP server backend for the
/mcpendpoint. For example, the broker does the following activities:-
Handles the handshake,
init. - Discovers tools from connected MCP servers and aggregates them into a unified list. Validates that discovered MCP servers meet minimum protocol version and capabilities before including their tools in the list.
- Listens for updates and can change its state so that the agentic AI always has the latest information.
-
Handles notifications sent through whichever backend MCP server it is connected to, for example,
notifications/tools/list_changed. - Handles notification requests from clients and MCP servers by proxying from the MCP server notification to registered clients.
-
Handles the handshake,
- MCP discovery controller
The MCP discovery controller is a Kubernetes-based controller that watches for changes to custom resources (CRs). The MCP discovery controller uses CRs to configure the MCP gateway and register MCP servers. The CRs are then turned into a configuration that is consumed by the MCP gateway so that it can route and present the tools from the registered MCP server to the client.
The MCP discovery controller component is responsible for the following activities:
-
Watching
MCPServerRegistrationCRs -
Maintaining a configuration from both
HTTPRouteandMCPServerRegistrationCRs -
Updating the MCP broker and MCP router config secret based on discovered
MCPServerRegistrationCRs and theHTTPRoutesthey target -
Reporting the status of
MCPServerRegistrationsCRs
-
Watching