Backend Bindings

mcp-http · proxy and mcp-openapi · client still need something to name: a hand-authored tool list, or an OpenAPI document to compile. For a handful of common backends, Zilla skips that step entirely. mcp-kafka, mcp-kafka-connect, and mcp-schema-registry are client kind bindings that connect straight to a backend and expose a fixed, built-in set of MCP tools, no options.tools to author, no spec to register, no upstream MCP server in the loop at all.

The Three Backend Bindings

Binding	Connects to	Tool surface
`mcp-kafka`	A Kafka cluster's brokers	Produce and consume messages; create, delete, describe, and configure topics; describe and configure brokers; inspect consumer groups and cluster health
`mcp-kafka-connect`	A Kafka Connect worker's REST API	List, create, describe, update, delete, pause, and resume connectors; inspect tasks and plugins
`mcp-schema-registry`	A Karapace-compatible schema registry	List subjects and versions; register, read, and delete schemas; get and set compatibility

Each one connects directly to options.server (or, for mcp-kafka, options.servers), so the tool call goes straight to the backend, no REST API or MCP server standing in between.

Configuration

Route tool calls to a backend binding the same way you'd route to an mcp · client or mcp-http · proxy, by toolkit:

bindings:
  north_mcp_proxy:
    type: mcp
    kind: proxy
    routes:
      - exit: kafka_mcp_client
        when:
          - toolkit: kafka

  kafka_mcp_client:
    type: mcp-kafka
    kind: client
    options:
      servers:
        - kafka.internal:9092
    routes:
      - when:
          - tool: produce_message
            topics: [ orders ]
        guarded:
          my_jwt_guard:
            - kafka:write
      - when:
          - tool: consume_messages
            topics: [ orders ]
      - when:
          - tool: "*"

Every backend binding's own routes gates individual tools, independent of the toolkit-level guarded: route on mcp · proxy — both checks have to pass. mcp-kafka additionally lets a route restrict produce_message/consume_messages to specific topics by name or glob, so orders:read and orders:write roles can be scoped per topic rather than per binding.

When to Reach for One

A backend binding (mcp-kafka, mcp-kafka-connect, mcp-schema-registry) when the operations you need are already in its fixed tool set — admin and data-plane operations against a specific kind of backend, no schema authoring, no upstream to run.
mcp-openapi when an OpenAPI document already describes the API; it compiles routed operations into tools and resources automatically.
mcp-http when no spec exists, or the fixed set doesn't cover the operation you need, so you name the tool and its schema by hand.
mcp · client when a real upstream MCP server already exists for the backend.

Try It

Try the example

The MCP Gateway demo routes a kafka toolkit straight to mcp-kafka · client, alongside an OpenAPI-derived github toolkit and a reference MCP server, all behind one JWT-scoped gateway.