Virtual Server

mcp · proxy aggregates responses from all upstream servers into a single unified view. When an agent calls tools/list, Zilla fans out the request to every configured upstream, merges the results, deduplicates by toolkit, and returns one response. The agent has no awareness of how many upstreams exist.

Configuration

Add one mcp · client binding per upstream MCP server, then define a route for each toolkit:

bindings:
  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
      - exit: internal_tools_client
        when:
          - toolkit: internal

  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

  internal_tools_client:
    type: mcp
    kind: client
    options:
      server: http://internal-tools:3003/mcp
    exit: sys:http_client

Adding a new upstream is one new binding and one new route entry. Existing upstreams and routes are unaffected.

HTTP APIs as Upstreams

REST APIs can be exposed as MCP tools without running an MCP server. Use mcp-http · proxy as the exit instead of mcp · client, defining each tool by name with a schema converter and a route that maps the tool call to an upstream HTTP request:

  payments_http_proxy:
    type: mcp-http
    kind: proxy
    options:
      tools:
        get_payment_status:
          description: Look up the status of a payment by identifier.
          schemas:
            input:
              model: json
              catalog:
                payments_catalog:
                  - subject: get_payment_status_params
                    version: latest
    routes:
      - when:
          - tool: get_payment_status
        exit: sys:http_client
        with:
          headers:
            ":method": GET
            ":scheme": http
            ":authority": payments-api:8080
            ":path": /payments/${args.paymentId}

See HTTP APIs as Tools for full configuration.

Backends as Upstreams

Some upstreams don't need mcp-http's hand-authored tools either. mcp-openapi · client compiles an existing OpenAPI document into tools and resources automatically, and mcp-kafka, mcp-kafka-connect, and mcp-schema-registry each expose a fixed, built-in tool set straight against their backend, no upstream MCP server, no REST hop, no schema authoring:

  kafka_mcp_client:
    type: mcp-kafka
    kind: client
    options:
      servers:
        - kafka.internal:9092
    routes:
      - when:
          - tool: "*"

Route a toolkit to it the same way as any other exit, by toolkit name on mcp · proxy. See Backend Bindings for the full set and when to reach for each one.