Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

Deliver an application gateway which handles the Model Context Protocol (MCP), which we will simply refer to as an MCP Gateway. The MCP Gateway will handle connectivity and management of MCP Servers both on and off cluster for MCP clients both on and off cluster.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

• Users will have a centralized and controlled entry point for Agentic AI traffic within OpenShift.
• Users will be able to compose and unify disparate AI tools from multiple backend MCP Servers into a single, tool list and then be able to crate virtual servers that present a sub-set of the overall tool list.
• Users will have enhanced security and control over Agentic AI interactions, including the ability to enforce limits and restrict access to tools to authorized users/clients.
• Users will benefit from centralized auditing, inspection, logging, and monitoring of Agentic AI traffic.
• Users will be able to manage authentication and authorization (e.g., RBAC) for Agentic AI tools.

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

• The MCP Gateway successfully establishes and maintains streaming connections to MCP Servers.
• The MCP Gateway enables the listing and execution of "tools" available on backend MCP Servers via agent requests.
• The MCP Gateway effectively provides API management facilities for Agentic AI traffic, including security controls, inspection, auditing, logging, and monitoring.
• The MCP Gateway supports authentication and authorization mechanisms (e.g., RBAC) for controlling access to tools.
• The MCP Gateway composes and exposes a selection of discrete tools/resources from multiple backend MCP Servers as a single, unified server to agents.
• The MCP Gateway prevents name collisions when composing tools from various backend servers.
• Configuration of the above features of the MCP Gateway should be compatible with gitops driven management.

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

The following items are currently out of scope for the immediate release:

• Resumable Sessions (for the immediate release)
• Capability support for Prompts, Resources, Roots, Sampling, and Completion (these are future considerations)
• Security plugins / Shield
• Adding context (changing tool and parameter names, descriptions, etc.)
• Rate-limiting
• Full session management (including resumable sessions, detection of resumable sessions, and management of idle sessions)
• Gateway Scaling / HA
• Load balancing (including Red/Green tool deployment, backend health checks, and multiple backends)
• Caching
• Business logic in the gateway
• Integration with MCP Registry
• Agent to Agent (A2A) communication
• Exposing existing tools and services (like REST, OpenAPI, or GRPC) via MCP without writing MCP servers.
• Support for stdio backends
• Assuming the MCP Gateway will start backend MCP servers
• Assuming a single IP/Port per backend MCP server (not multiplied by user)

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

MCP is an emerging Agentic AI protocol built on top of HTTP that enables running tasks and workflows of those tasks across a variety of potentially disparate backend APIs using natural language. It has become incredibly popular recently due to its promise of making integrations and automation easier and more accessible.

As an example of what MCP can provide: a client may make a request to an MCP system such as “transfer $100 from my bank account to my Venmo, then pay my friend Anna $50 on Venmo for the flower arrangement she gave me yesterday, then order me a Pizza for dinner tonight” and the MCP Agent under the hood will enumerate the capabilities of backend MCP Servers which it is integrated with (such as the bank, Venmo, and a Pizza place) and provide them to an LLM which then constructs the API calls (including important details, e.g. adding the appropriate note to the Venmo that describes the payment was for the flowers) needed to resolve the request, and the agent then makes the requests on the client’s behalf.

An MCP Gateway is a natural component in such a system which enables connectivity and management of the traffic from the agent in order to provide control over this traffic to enforce limits, provide security, and generally provide API management facilities for this traffic at scale.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>