Skip to main content

MCP Gateway

AI GatewayMCP

Zilla's MCP Gateway presents a single Streamable HTTP endpoint to every AI agent and fans out tool calls to any number of upstream MCP servers and HTTP APIs. Routing, caching, auth, and observability are handled at the gateway — no custom middleware, no SDK wrapper.

Architecture

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 · clientCompiles an OpenAPI document from a catalog into MCP tools and resources, no hand-authored tool list
mcp-kafka · clientExposes a Kafka broker's produce, consume, topic, and admin operations as fixed MCP tools, no REST hop
mcp-kafka-connect · clientExposes the Kafka Connect REST API as fixed MCP tools
mcp-schema-registry · clientExposes a schema registry's subject and schema operations as fixed MCP tools

The last four bindings need no upstream MCP server at all, either compiling one from an existing spec (mcp-openapi) or exposing a fixed, built-in tool set directly against the backend (mcp-kafka, mcp-kafka-connect, mcp-schema-registry). See Backend Bindings for when to reach for each one.

Capabilities

How It Works

The binding pipeline and how MCP requests flow from agent to upstream.

→

Toolkit Routing

Route tool calls to the correct upstream using declarative YAML route conditions.

→

Listing Cache

Cache and aggregate tool, prompt, and resource listings at the gateway with a configurable TTL.

→

Virtual Server

Aggregate tool lists from multiple upstream servers into a single unified response.

→

Tool Discovery

Keep tools/list short with eager/cold tools, searchable and callable on demand.

→

Elicitation

Relay an upstream's mid-call request for user input back to the client, form or URL mode.

→

Backend Bindings

Expose Kafka, Kafka Connect, and a schema registry as MCP tools directly, no upstream server, no hand-authored tools.

→

Get Started

zilla.yaml
stores:
  cache:
    type: memory

bindings:
  north_tcp_server:
    type: tcp
    kind: server
    options:
      host: 0.0.0.0
      port: 7114
    routes:
      - when:
          - port: 7114
        exit: north_http_server

  north_http_server:
    type: http
    kind: server
    options:
      access-control:
        policy: cross-origin
    routes:
      - when:
          - headers:
              ":path": /mcp
        exit: north_mcp_server

  north_mcp_server:
    type: mcp
    kind: server
    exit: north_mcp_proxy
    telemetry:
      metrics:
        - mcp.*
      attributes:
        method: ${mcp.method}
        tool: ${mcp.tool}
        outcome: ${mcp.outcome}

  north_mcp_proxy:
    type: mcp
    kind: proxy
    options:
      cache:
        store: cache
        ttl: PT5M
    routes:
      - exit: bluesky_mcp_client
        when:
          - toolkit: bluesky
      - exit: payments_mcp_client
        when:
          - toolkit: payments

  bluesky_mcp_client:
    type: mcp
    kind: client
    options:
      server: http://bluesky-mcp:3001/mcp
    exit: sys:http_client

  payments_mcp_client:
    type: mcp
    kind: client
    options:
      server: http://payments-mcp:3002/mcp
    exit: sys:http_client

telemetry:
  metrics:
    - mcp.initialize
    - mcp.initialize.duration
    - mcp.tools.list
    - mcp.tools.list.duration
    - mcp.tools.call
    - mcp.tools.call.duration
  exporters:
    prometheus_exporter:
      type: prometheus
      options:
        endpoints:
          - scheme: http
            port: 7190
            path: /metrics

Try the example

The mcp.proxy example runs a full working MCP gateway with two upstream servers, toolkit routing, a 5-minute listing cache, and Prometheus metrics — all from a single docker compose up.