MCP & Kuadrant POC's

Signed-off-by: R-Lawton <[email protected]>

Author: R-Lawton

src/blog/mcp-kuadrant.md

@@ -32,18 +32,6 @@ How it worked is that on startup, the first server or MCP gateway makes an insta
 The nature of Streamable HTTP makes it challenging to rely on a single Gateway, HTTPRoute, and backend when all functionality is exposed through a single endpoint `/mcp`. To address this limitation, we designed a component called the MCP Gateway, a dedicated MCP server that acts as a proxy in front of two other MCP servers.
 
 On startup, the first MCP Server or MCP Gateway performs an instantiation call to each  MCP server, followed by a tool list call. The Gateway saves the tool list responses in memory, allowing it to dynamically route future requests from MCP hosts through a single Gateway API Gateway and HTTPRoute.
-```mermaid
-flowchart LR
-    C[MCP Client] --> Gateway
-    E[Envoy/WASM] --> G
-    G[MCP Gateway] --> A[MCP Server 1]
-    G --> B[MCP Server 2]
-    subgraph Gateway
-        direction TB
-        AP@{ shape: notch-rect, label: "AuthPolicy" } -.-> E
-        RLP@{ shape: notch-rect, label: "RateLimitPolicy" } -.-> E
-    end
-```
 
 This approach integrates perfectly with the previously mentioned tool-based authorization and Rate Limiting policies. When a tools/call is received, the MCP Gateway inspects the JSON-RPC message to determine the correct backend MCP server for the requested tool, forwards the request, and proxies the response back to the client via the Gateway API Gateway.