Summary
Buyer channels use different protocols. The repository's reference design aims to route promoted web, MCP, OpenAPI, A2A, search, WhatsApp, and Telegram adapters through shared cache evaluation and answer-or-refuse policy.
Channel Map
The channel map illustrates possible protocol choices: buyer endpoints for web, MCP metadata and tools for compatible clients, OpenAPI metadata for compatible clients, crawlable public catalog surfaces for search agents, and verified webhooks for messaging. Each adapter requires separate compatibility, credential, and approval evidence.
Source Labels Are Not Optional
The policy goal is to preserve source and freshness on answers. Commitment-bound requests such as final availability, price, payment, holds, refunds, returns, or order status should cross a separately authorized preparation boundary rather than remain simple discovery.
Approval Reality
Some platforms require marketplace review, account setup, Meta verification, bot registration, or app approval. Repository-side manifests, schemas, webhook handlers, privacy copy, and operator checklists are only part of readiness; a channel should not be called live until external approval and credentials exist.
Failure Modes
A production design should reject unsigned or secret-mismatched callbacks, require merchant approval for public catalog routes, and withhold payment or order execution tools unless a separately reviewed design is promoted.
Topics
Ready to try it?
Explore the public playground, or create an account to evaluate an agent with your own approved data and controls.