MCP behaviour in API Platform

[RakhithaRR]

Right now, we let the users define the MCP capabilities in the mcp-proxy yaml definition. However, they have not been used anywhere yet. Initially, this was meant to be used for serving various list calls such as tools/list, resources/get, etc. among other things. Eventually, the users should be able to define policies at each capability level as well. However, the policy engine is not aware of different kinds of proxies at moment. Due to that, the policies attached at the capability level has to be moved to an API level policy before deploying in the gateway. This means, we need to write specific logics in all MCP related policies to handle different kinds of capabilities. Due to this, a decision was made allow adding policies at the top level (proxy level) only until the policy engine can be made aware of the proxy kind and in turn support proxy specific requirements.

Despite this, we still have a requirement to "serve" the MCP requests from the gateway level. This is important specifically in hybrid scenario because we allow users to modify the tool names and descriptions through the UIs for better governance of MCP proxies. The expectation here is if they have modifies the definition, those should be returned in the tools/list instead of what is actually there in the backend. And also, if the tool name has been changed, we need to intercept the request and add the correct target tool as well.

We have two options to handle the list scenarios.

• Serve the request from the gateway
• Intercept and filter the response in the response path

We will need a policy in both those scenarios. From a session management perspective, the second option will be the better choice as we will be filtering/modifying the response instead of creating on of our own from the gateway. This way the streamable http connection will also be kept alive.