Summary

Implement the mcp_asyncapi · proxy binding in a new binding-mcp-asyncapi
module. Accepts mcp streams and produces asyncapi streams. Derives tool
names, call semantics, and schemas from AsyncAPI specs held in catalogs — no
tool code required.

Stream type

• Accepts: mcp
• Produces: asyncapi (resolved to the protocol declared in the spec servers
  block by the downstream asyncapi binding — Kafka, HTTP, etc.)

Responsibilities

• options.specs — named spec references pointing to catalog subjects,
  consistent with binding-asyncapi.spec patterns
• send operations become fire-and-forget produce tools
• send + reply (AsyncAPI 3.x Operation Reply Object) becomes a
  request/reply tool
• receive operations become fetch tools
• Protocol resolved from spec servers block via the asyncapi stream layer —
  not declared in mcp_asyncapi config
• Routes reference the spec by api-id and operation-id, with when in MCP
  tool terms

inputSchema derivation

The tool inputSchema is derived from the AsyncAPI operation's message
payload schema — the application-level fields declared in the spec. Protocol
concerns (Kafka topic, key, headers, partitions; HTTP method, path, headers)
are fully resolved by the downstream asyncapi binding from the spec servers
and channels blocks. They are never exposed in the tool schema.

For example, a send operation whose message payload is:

{
  "type": "object",
  "properties": {
    "orderId":  { "type": "string" },
    "amount":   { "type": "number" },
    "currency": { "type": "string" }
  },
  "required": ["orderId", "amount"]
}

produces a tool whose inputSchema is exactly that object — the agent passes
{ orderId, amount, currency } and has no awareness of the underlying protocol.

For receive operations, the tool inputSchema exposes a limit parameter
(integer, optional, default 10) controlling how many messages to return. The
outputSchema is the receive operation's message payload schema — the binding
returns an array of payload objects.

Operation-to-tool semantics

The reply block is the native AsyncAPI 3.x Operation Reply Object — no
custom extension. Static example:

operations:
  placeOrder:
    action: send
    channel:
      $ref: '#/channels/orders'
    reply:
      channel:
        $ref: '#/channels/orderConfirmations'

Dynamic example (reply address in request header):

operations:
  placeOrder:
    action: send
    channel:
      $ref: '#/channels/orders'
    reply:
      address:
        location: "$message.header#/replyTo"
      channel:
        $ref: '#/channels/orderConfirmations'

Configuration

catalogs:
  asyncapi_orders0:
    type: apicurio
    options:
      url: https://apicurio.internal
      group: orders
      artifact: orders-api
 
bindings:
  mcp_asyncapi_orders0:
    type: mcp_asyncapi
    kind: proxy
    options:
      specs:
        asyncapi_orders0:
          catalog:
            asyncapi_orders0:
              subject: orders-api
              version: latest
    routes:
      - exit: asyncapi_client_kafka0
        when:
          - tool: place_order
        with:
          api-id: asyncapi_orders0
          operation-id: placeOrder
      - exit: asyncapi_client_kafka0
        when:
          - tool: get_order_status
        with:
          api-id: asyncapi_orders0
          operation-id: getOrderStatus
      - exit: asyncapi_client_kafka0
        when:
          - tool: list_pending_orders
        with:
          api-id: asyncapi_orders0
          operation-id: listPendingOrders

Blocked by

• binding-mcp: implement mcp · server binding (binding-mcp: implement mcp · server binding #1668) — defines the mcp
  stream type
• binding-asyncapi.spec (existing) — defines the asyncapi stream type and
  spec resolution

Additional context

• AsyncAPI 3.0 Specification
• AsyncAPI Request/Reply
• MCP Specification