A join card is a short, seller-declared block of metadata on a data listing that tells a buyer how the data joins with other data: what one record represents, and which columns or parameters are join handles, with their exact formats. It moves the knowledge every data fusion needs from the seller’s head — where it’s free — to the listing, where every buyer can read it before paying.
{
"row_represents": "one company",
"join_keys": [
{
"column": "domain",
"description": "website domain, lowercase, no www"
}
],
"grain_notes": "one row per company, refreshed monthly"
}
Lookup endpoints (APIs, MCP tools) declare both directions instead —
accepts (“a company domain via the domain param”) and returns (“traffic
stats keyed to that domain”) — which turns them into composable enrichment
steps.
The three properties that make it work
- Free text, thin skeleton. No ontology, no controlled vocabulary — the card is written in the seller’s own words, because its readers are agents (and data scientists), not rigid parsers.
- Deterministically verified. The platform checks that every declared column actually exists in the listing’s response schema; verified cards earn the ⧉ Fusion-ready badge, stale ones are flagged. No AI sits in the middle.
- Searchable.
search_marketplace(joinable_on="domain")returns only listings whose card offers a matching handle — so a card is what makes a listing findable by an agent planning a data fusion. Listings also show how many others share a handle (joins_with), mapping the catalog as a joinable graph rather than a shelf of files.
Why it exists
The expensive part of buying data was never the merge — it’s rediscovering, after purchase, which column is the key and how it’s formatted. A join card makes that knowledge public, verified, and searchable, so fusion becomes plan-then-buy instead of buy-and-hope.
Go deeper: the seller guide · what buyers do with cards · why fusion is the real product