MCP Gateway

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.

Features

HTTP APIs as Tools

Skip writing an MCP server: point at a REST API or an OpenAPI document and agents can call it today.

REST API as ToolsExpose a plain REST API as MCP tools with no MCP server standing between it and the gateway, and no application code to write.OpenAPI Specs as ToolsPoint at an OpenAPI document you already have and get tools and resources generated automatically, instead of hand-authoring each one.OverlayPatch a third-party OpenAPI document with an overlay, adding security requirements, servers, or MCP metadata without forking the original spec.Resources, Static & TemplatedMap a GET endpoint to an MCP resource instead of a tool, a fixed URI lists once in resources/list, a {captured} URI becomes a resource template read with a value filled in.

Kafka Topics as Tools

Produce, consume, and administer a Kafka cluster as MCP tools, no REST hop, no custom MCP server.

Stream EventsLet an agent produce and consume Kafka messages directly as MCP tools, no custom MCP server, no application code standing in front of the topic.Topic ManagementCreate, delete, list, describe, and configure topics as MCP tools, covering partitions, replicas, and per-topic config overrides.Broker & Cluster InspectionDescribe and configure brokers, and check cluster health, controller status, and under-replicated or offline partitions as MCP tools.Consumer Group ManagementList and describe consumer groups, inspect member partition assignments, and reset committed offsets as MCP tools.Kafka Connect as ToolsList, create, update, pause, and resume connectors on a Kafka Connect worker as MCP tools, with a fixed, built-in tool set out of the box.Schema Registry as ToolsList, register, read, and delete schema subjects on a Karapace-compatible schema registry as MCP tools, with a fixed, built-in tool set out of the box.

Virtual Server

Give agents one endpoint, no matter how many upstreams sit behind it.

Multi-Server AggregationMerge tool, prompt, and resource listings from every upstream MCP server into one response, so an agent never has to know how many upstreams exist.Toolkit RoutingRoute each tool call to the right upstream automatically, based on the toolkit prefix in the tool's name.Listing CacheAnswer tools/list from a TTL'd cache instead of re-querying every upstream on every request.

Tool Discovery

Add hundreds of tools without burying an agent's context window in definitions.

Eager & Cold ToolsKeep the tools an agent actually reaches for listed by default, and hold the rest back without hiding them permanently.Search, Describe, ExecuteLet an agent find a cold tool by keyword, resolve its schema, and call it, all without that tool ever crowding the default listing.

Human-in-the-Loop

Let a tool call pause mid-flight and ask the person behind the agent something.

Form ModeRelay an upstream tool's request for a missing field or confirmation back to the client, unmodified, in the same round trip.URL ModeRelay an out-of-band step, like an OAuth consent screen, and the completion notification once the user finishes it in a browser.

Secure Agent Access

Turn agents away before a tool call ever reaches an upstream, no code in the agent or the upstream.

JWT BearerValidate the access token an agent presents against a JWKS endpoint, directly on the gateway's entrypoint.Role-Based Tool AccessGate an entire toolkit, a single tool inside it, or both at once by role, one policy at the gateway instead of auth logic duplicated per upstream.Client CredentialsAuthenticate the gateway itself to an upstream with a service account, independent of whatever credential the agent presented.Token ExchangeSwap an agent's inbound token for the credential each upstream actually expects, without the agent ever holding it.TLSEncrypt the inbound connection an agent opens to the gateway.Mutual TLSRequire an agent to present a trusted client certificate on top of an encrypted connection.

Architecture

Binding	Role
mcp · server	Terminates the inbound Streamable HTTP connection from the AI agent
mcp · proxy	Routes tool calls to upstream providers by toolkit name
mcp · client	Connects to an upstream MCP server over HTTP, WebSocket, or SSE
mcp-http · proxy	Exposes any HTTP API as MCP tools with no MCP server needed upstream
mcp-openapi · client	Compiles an OpenAPI document from a catalog into MCP tools and resources, no hand-authored tool list
mcp-kafka · client	Exposes a Kafka broker's produce, consume, topic, and admin operations as fixed MCP tools, no REST hop
mcp-kafka-connect · client	Exposes the Kafka Connect REST API as fixed MCP tools
mcp-schema-registry · client	Exposes 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, or How It Works for how a request flows through the binding pipeline end to end.

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.

Related Reference

• mcp · server
• mcp · proxy
• mcp · client
• mcp-http · proxy
• mcp-openapi · client
• mcp-kafka · client
• mcp-kafka-connect · client
• mcp-schema-registry · client