MCP flow and UX in AI Workspace

[RakhithaRR]

Overview

Right now our platform gateway is capable of handling MCP traffic. It covers areas like authentication, authorization, analytics, access control, etc. People can use these capabilities for their internal MCP servers or even to govern MCP servers from external providers they use. The next step for MCP in the platform will be providing the MCP proxy creation capability through our portals for the hybrid gateway scenario.

Right now the users can create MCP servers through Bijira console. Those will be deployed in the cloud gateway. We are planning to keep this as it is and bring the MCP proxy creation in the hybrid gateway to the AI Workspace similar to what we have done with LLM related proxies.

There are several things to be discussed when bringing the MCP support for the AI Workspace.

---

MCP Proxy Creation

Flow

We allow only proxying existing MCP servers through the platform gateway. The creation flow will be as follows.

• Provide the MCP server url. Optionally, provide backend security if available (eg: apikey)
• The workspace will initialize and connect with the MCP Server and fetch the available tools, resources, and prompts. This can be done from either the Workspace UI or the Platform API backend.
• We will allow the user to initially select the tools, resources, and prompts they want to expose through the gateway. These will be added as parameters of the mcp-acl-list policy with 'deny all and allow the selected ones' mode.
• We need to decide whether we are going to display the tools/resources/prompts in the UI similar to how we do this in Bijira and API Manager. Displaying those in the UI requires us to either store those in the database or call the server every time we load the page and fetch it. Storing those in the database might not make sense for MCP as these are too dynamic and fetching on each reload will also be too much of an overhead. Storing them might make sense in the long run when we eventually bring in MCP governance to the AI Workspace.
• If the users want to modify the names, descriptions, or schemas of the capabilities, they will have to add the mcp-rewrite policy with the necessary parameters.

Egress vs Ingress

Egress MCP proxies are usually needed when an organization starts using an MCP server provided by some external party (github, slack, etc.). This feels like an admin task where they create a single proxy at the organization level allow the users in the organization to use this.

MCP server developers in the organization should be allowed to onboard their servers as MCP proxies at the project level. However, one major issue we will face at this point is the reachability of the MCP server from the AI Workspace. If this internal server is not exposed through the internet, we would not be able to reach this and proceed with the flow.

This aligns with what we have done with LLM Providers and LLM Proxies. But here we only have one entity; MCP Proxies. On the other hand, if we treat egress and ingress the same way, there will be no visible difference from the UI.

MCP Hub and Registry

The latest MCP spec has documented the concept of a registry where users can push their MCP servers and allow others to discover them. This spec allows others to create sub registries following the same REST API specification. However, this is still pretty new and not mature enough to be adopted into our products.

In both Bijira and APIM, we provide the MCP Hub capability. The hub displays the information about the available tools in a specific MCP server, allows users to subscribe to those servers, and allows them to get the server configuration to be added to their preferred MCP client. The AI Workspace does not have a relationship with the MCP Hub at the moment. To view all the available MCP proxies in an organization, we have to either push it to the MCP Hub or display them in the AI Workspace itself with a registry kind of view.

MCP Policies

Currently, we have 4 policies targetting MCP proxies

• mcp-auth - Handling MCP authentication as defined in the spec
• mcp-authz - Fine-grained RBAC for MCP proxies
• mcp-acl-list - Allow or deny MCP capabilities through the proxy
• mcp-rewrite - Modify capability names and schemas. These modified ones will be returned in the list calls and the parameters will be validated in the invocations according to the new schemas.

We need to decide whether we are going ahead with the policy option through the UI or whether we are providing these as first class features and internally handle them as policies.

Furthermore, the current plan is to allow attaching policies at the API level (instead of the capability level). With this, users will have to define the MCP capabilities to which it should be applied as policy parameters if required.

Analytics/Insights

AI Workspace only show LLM based analytics at the moment. Once we introduce MCP proxies, we need a way to show MCP analytics as well. This could be done by adding an LLM Insights and MCP Insights section under a parent Insights section rather than having a single insights section like we do now.

---

Appreciate the feedback here to proceed with the implementation.