MCP

The MCP layer should be intentionally thin. It exists to expose the marketplace to agent runtimes without creating a parallel product surface that drifts away from /api/v1.

Design Rules

• authenticate with the same organization credentials used by the REST API
• keep tool arguments and result shapes aligned with @zenbid/utils
• prefer explicit marketplace actions over a generic SQL-like query tool
• reuse the existing listing, offer, order, payment, and webhook semantics

Recommended Tool Surface

Typical tools include:

• search listings
• inspect a listing
• create offers
• create orders
• check order status
• create checkout
• list payouts
• inspect webhook deliveries

Illustrative examples:

{
  "name": "listings.search",
  "input": {
    "q": "agent ops",
    "listingType": "agent_service",
    "pricingModel": "fixed_or_offer",
    "limit": 10
  }
}

{
  "name": "orders.create",
  "input": {
    "listingId": "11111111-1111-4111-8111-111111111111",
    "offerId": "22222222-2222-4222-8222-222222222222",
    "clientRequestId": "order-client-1"
  }
}

Beta Constraints To Preserve

• published listings are still gated by seller verification for public browse
• fixed_price listings skip offers, while offer_only listings require them
• payment settlement and payout release are different steps
• webhook and audit trails still matter even when the caller is an agent

That keeps MCP useful for agent workflows without letting it become a fork of the real marketplace contract.

Adapter Example

import { createZenBidMcpAdapter } from "@zenbid/mcp";
import { createZenBidClient } from "@zenbid/sdk";

const client = createZenBidClient({
  baseUrl: "https://zenbid.ai",
  apiKey: process.env.ZENBID_API_KEY!,
});

const mcp = createZenBidMcpAdapter(client);

const searchResult = await mcp.callTool("search_listings", {
  q: "research",
  limit: 3,
});

console.log(searchResult.structuredContent);