For integrating agents
How our names map to the Universal Commerce Protocol
OpenShopGraph describes a discovery/trust layer, not UCP's shopping-catalog layer — this page names the correspondence explicitly instead of leaving it to guesswork.
One-line answer: the names are coherent because they describe a different layer than UCP and say so honestly; we adopt none of UCP's vocabulary, we only document the mapping.
No name changes. No tool or field name is a demonstrated stumbling block for an agent — find_shop, get_shop, list_coupons,
get_trust, report_* are self-explanatory and carry full descriptions. Renaming to UCP names would be a breaking change for every live consumer of the running MCP server, with indefinite alias upkeep, for no benefit. The two real stumbling blocks were not names — they were facts: a stale version string in the agent profile and a miscounted tool total in llms.txt (both fixed separately, in this same change).
| UCP term | OSG term | Coverage | Note |
|---|---|---|---|
| Agent profile (ucp-agent.profile, HTTPS, JSON) | /ucp/agent-profile.json | deckungsgleich | Same discovery handshake. (Version was stale — 2026-04-08 vs. the then-current 2026-08-25 — fixed 2026-09-04, E1.) |
| Capability dev.ucp.shopping.catalog.search | find_shop | teilweise | UCP searches Products (Item); OSG searches Shops. |
| Capability dev.ucp.shopping.catalog.lookup | get_shop | teilweise | Same direction, different granularity (Shop, not Item). |
| Item (id, title, price) | get_shop.offers | teilweise | Schema placeholder only — the Offer table was measured empty as of 2026-07-30; the field exists but never returns data yet. |
| Discount.codes | list_coupons → code | teilweise | UCP models only the code string. OSG additionally carries verificationStatus/lastVerifiedAt/validUntil (see next row) — pressed into Discount.codes, "proven by an actual checkout" would narrow to "a string". |
| no counterpart | verificationStatus, lastVerifiedAt, validUntil | OSG-eigen | The proof concept (a real checkout attempt against a code) has no equivalent anywhere in UCP. |
| dev.ucp.shopping.fulfillment (named as an example only, not verified against a schema) | get_shipping_policy | nicht bewertbar — OPEN | Field schema was not available in the source dossier — left open rather than guessed. |
| no counterpart | get_trust (source, checked_at, signal_coverage) | OSG-eigen | Self-measured trust signals (TLS, hosting, registration) with no aggregate score — no UCP equivalent. |
| Message (type, code, content, path) | report_code, report_issue | no counterpart | Different direction: UCP's Message runs merchant to agent; OSG's reports run agent to OSG. Not the same relationship — do not conflate. |
| Merchant/Customer schema | shop_domain / shop_id_or_domain | nicht bewertbar — OPEN | UCP's merchant-side fields were not available in the source dossier — left open rather than guessed. |
| Checkout, Cart, LineItem, Totals, QuantityUnit, Action, payment instruments, payment_handlers | none | bewusst leer | Deliberately absent — checkout/payment is a different layer (ACP/AP2 territory), not something OSG omitted by accident. No ACP checkout, no AP2 mandates, no payment_handlers. |
Namespace rule for future OSG-specific UCP extensions
OSG-specific terms (verificationStatus, signal_coverage , and others) are, if they are ever exposed over UCP, carried exclusively under a reverse-domain namespace of openshopgraph — for example com.openshopgraph.trust — never unter
dev.ucp.* , which stays reserved for UCP’s own governance.
This is not a hypothetical: UCP's own spec provides for exactly this extension pattern (see Shopify's own dev.shopify.catalog / dev.shopify.catalog.global for precedent), and pressing an OSG concept into an existing UCP field instead would narrow its meaning — the risk this document exists to name and avoid.