The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Mercantry Registry listing page.
Mercantry is an open commerce registry for AI agents — structured merchant data, honest signals, and real-world booking fulfillment.
Current status — read this first. Mercantry is pre-launch. What is real and what is not, precisely:
- The merchant data is real: 168,000+ restaurants across Los Angeles, Hong Kong, and Tokyo, built exclusively from openly licensed sources (Overture Maps CDLA-P-2.0 + official government registers), conflated with per-field provenance and QA-gated versioned releases. Live counts:
get_registry_meta.- Real merchants are discovery-only for now:
place_bookingagainst a real merchant returns the structured rejectionfulfillment_not_live. A booking guard makes it structurally impossible for our booking simulator to dial a real restaurant.- The booking loop is testable end-to-end against
sandbox: truemerchants — fictional records with deterministic outcomes ("test cards for bookings"). Do not call sandbox phone numbers; they are not real businesses.- Fulfillment, when it launches, is human-operated phone booking on a phone-verified merchant tranche (voice automation is deferred). Outbound-calling sections of the spec operate only after legal review — publication of the spec is not operation.
- Mercantry is built and operated by a team of AI agents with human oversight, stated here as a fact rather than a gimmick.
The live endpoint serves MCP over Streamable HTTP:
/v1 — self-describing via /v1/openapi.json/.well-known/mcp.json · agent card: /.well-known/agent-card.json · health: /healthz · PII-free ops stats: /v1/stats · privacy policy: /privacy · demo & reviewer guide: /demoPOST /v1/keys with developer_name + contact. All reads are free and unauthenticated.GET /v1/export/merchants.ndjson — caching, embedding, and training on the data are permitted under the open license.Copy-paste integrations — curl, Claude Code/Desktop, raw MCP JSON-RPC, OpenAI Agents SDK, LangChain, webhook receiver: examples/. Agent-first tool documentation with example transcripts: docs/mcp-tools.md. If you are an agent working in this repo, read AGENTS.md.
search_merchants (filter-based, never ranked, deterministic documented order) · get_merchant (full signal dump: every field, raw feedback history, operational stats, per-field provenance) · get_availability (honest: performed_at_booking) · place_booking (async) · get_booking_status · modify_booking · cancel_booking (mandatory when plans change — no-shows are tracked per developer key) · submit_feedback (confirmed bookings only, once, within 14 days) · get_registry_meta (evaluate the registry itself, staleness included)
| Surface | Where |
|---|---|
| MCP (Streamable HTTP) | http://localhost:4100/mcp |
| REST mirror + OpenAPI | http://localhost:4100/v1 |
| Landing page (public fact page) | http://localhost:4100/ |
Ops Console (gate with OPS_TOKEN) | http://localhost:4100/ops/ |
| Booking status pages | http://localhost:4100/status/:booking_id |
Deployment (Docker/Fly.io), agent onboarding, and the security checklist: docs/deployment.md.
The customer is the agent, not the human. One uniform interface with swappable fulfillment backends: agents integrate once; behind the interface, fulfillment can graduate from human phone calls to native merchant integrations without the agent changing a line.
get_availability says performed_at_booking instead of pretending; get_registry_meta exposes our own staleness; sandbox vs. real is labeled per merchant.The full product spec lives at docs/requirements.md. Sections describing outbound calling are published for openness but nothing in them operates until legal review is complete — see the banner at the top of that document.
Apache-2.0. The registry spec, code, and data schema are open — openness is the strategy, not a concession.