Skip to main content

How It Works

Zilla's MCP Gateway is built from a small set of composable bindings. Each layer does exactly one thing — and they chain together to form a complete gateway pipeline.

Binding Pipeline

BindingRole
mcp · serverTerminates the inbound Streamable HTTP connection from the AI agent
mcp · proxyRoutes tool calls to upstream providers by toolkit name
mcp · clientConnects to an upstream MCP server over HTTP, WebSocket, or SSE
mcp-http · proxyExposes any HTTP API as MCP tools with no MCP server needed upstream
mcp-openapi, mcp-kafka, mcp-kafka-connect, mcp-schema-registryClient-kind bindings that connect straight to a backend, with a compiled or built-in tool set and no upstream MCP server (see Backend Bindings)

Request Flow

  1. The AI agent opens a Streamable HTTP connection to mcp · server.
  2. mcp · server forwards the session to mcp · proxy.
  3. mcp · proxy inspects the toolkit prefix on each tool call and routes to the matching exit binding.
  4. mcp · client exits connect upstream MCP servers over HTTP. mcp-http · proxy exits call REST APIs directly. mcp-openapi, mcp-kafka, mcp-kafka-connect, and mcp-schema-registry exits connect straight to their backend, no upstream MCP server or hand-authored tool list required.
  5. Responses are aggregated and returned to the agent as a unified MCP response.

Tool listing calls (tools/list, prompts/list, resources/list) are handled by the cache layer in mcp · proxy before reaching any upstream — see Listing Cache.