Trusted Master Data

Trusted Master Data is a paid API and MCP server that gives AI agents trusted master data: governed golden records and reference data for suppliers, locations, and organizations. Every answer is drawn from cleared public sources, with provenance and licence terms surfaced alongside the records.

This page is the public documentation skeleton. Each section below is a placeholder that fills in as the corresponding surface ships or as the Operator resolves the open decision behind it.

Coverage

Placeholder. The v1 entity domains are exactly supplier, location, organization, and reference data. The concrete source catalogue is an open Operator decision; sources, jurisdictions, and field groups will be documented here once the public-data eligibility inventory is approved.

Pricing

Placeholder. Paid operations are priced per call through the x402 protocol, with amounts as base-10 strings in atomic units. The machine-readable price catalogue is served at /v1/pricing; until the Operator resolves the deployment pricing configuration it fails closed with HTTP 503 rather than serving invented amounts.

A deployment may serve those priced operations without a payment challenge for a bounded promotional window, ending at a fixed instant the Operator configures. While that window is open the operation executes and answers normally, no 402 is issued and no payment is verified or settled; a request that carries a payment header is served the same way and nothing is charged. The price identifiers and amounts are unchanged — the window bypasses the challenge rather than revising a price — so a client reads the window, never the catalogue, to know whether a call costs anything: tools/list availability carries free_until, the instant it closes, on each priced tool while it is open and not otherwise. Every operation served that way is recorded in the service's own audit record under the disposition served_free rather than served, with no payment request and no payer, so an unpaid answer is never indistinguishable from a paid one. Which terms govern such a call, and what the Operator undertakes during the window, are stated in the published terms and not here.

Public-data eligibility

Only sources cleared by the public-data eligibility policy are served, and the inventory of those sources is published at /eligibility/public-data-inventory. It is free, anonymous, and never behind a payment challenge: it states the terms that bind a buyer, so reading it costs nothing. Each source row names its licence, jurisdiction, clearance class, entity domains, allowed field groups, prohibited fields, redistribution restrictions, attribution, retention, reviewer, review time, and next_review_at. Join meta.sources[].source_id on any response to sources[].source_id in the inventory to find the row governing a value you received.

The response states two versions and one marker. inventory_schema_version says which document schema the inventory was authored against; policy_version says which eligibility policy its rows were reviewed under, and is the value to compare against the policy_version a served public-use decision carries. The two are not guaranteed to be equal — a deployment may serve a snapshot built under an earlier policy — and the served version_notice says so rather than implying a guarantee. synthetic is true when the published inventory is the committed fictional example; the release gate refuses to release a deployment publishing one, and an absent marker is read as true.

Provenance and freshness policies

Placeholder. How provenance is attached to every record, and the freshness policy for each source, are open Operator decisions and will be documented here once ratified.

Error guide

Every REST error is an RFC 9457 application/problem+json document and every MCP tool error is an isError result carrying the common error envelope; both name a stable code, an honest retryable, and a message an agent can act on. The paid flow of the wired tools (search_master_data, resolve_master_data_entity): a call without payment answers 402 with a PAYMENT-REQUIRED challenge quoting the tool's price identifier; the signed payment is verified, the operation executes exactly once, settlement is recorded in the append-only ledger, and the answer carries the settlement summary in meta.payment with the full receipt in the PAYMENT-RESPONSE header; an idempotent retry replays from the ledger and charges nothing. Stable codes of these operations: payment_not_available (payments not servable, or no data loaded for the domain — nothing executes and no challenge is minted), invalid_arguments (the request violates the committed input schema, or a resolution names neither identifiers nor attributes — decided before the payment tier), unknown_entity_type, cursor_expired (restart from the first page), and data_version_unavailable (the cursor's data version is no longer served; restart from the first page). None of these are retryable as sent.

Availability is published before it is enforced. Every entry in the MCP tools/list result carries the reserved _meta member holding exactly one key, com.agentmasterdata/availability, whose value is an object with three members, and a fourth while a promotional window is open. available is a boolean, false when calling that tool right now would be refused before anything executed. reason is null when available is true, and otherwise the stable code that refusal carries in its error data — payment_not_available for a paid tool while paid calls cannot be served at all or while the deployment carries no data to sell, and payment_requirements_unavailable for one this deployment cannot quote, which is what an operator sees when no challenge signing key is configured: payments are deliberately disabled and free discovery keeps serving. price_ids is the tool's immutable x402 price identifiers in contract order, an empty array for the free discovery tool. free_until is the fourth member: the RFC 3339 UTC instant a promotional window closes, present only while that window is open and only on a priced tool, and absent — never null — otherwise, so its presence is the whole signal. A window makes a priced tool available with a null reason even on a deployment that could not quote it, because the call is served without a challenge; a paused deployment still refuses, and a deployment with no data to sell still answers payment_not_available, both while disclosing the window. The value is computed at serve time from the very guards a tools/call would be refused by, so the listed answer and the called answer cannot disagree.

Three conditions refuse a paid call before anything executes, and both hosts — the native binary and the Cloudflare Worker — answer the same code and the same status for each. payment_not_available (501) means this deployment cannot be paid at all: no payment configuration is resolved, payments are paused by its operator, or it carries no data to sell. payment_requirements_unavailable (503) means it could be paid but cannot state what payment would be, which is what an operator sees when no challenge signing key is configured — a supported serving-only deployment, deliberately disabled rather than broken, with free discovery unaffected. payment_configuration_unavailable (503) means a payment configuration is present but unusable: unparseable, or naming a network, asset, recipient, or facilitator credential that will not render into payment requirements. That third one reports a defect in the deployment rather than a choice its operator made, and it is the one condition the _meta above cannot anticipate — it is decided from host configuration read at serve time, which the tools/list guards do not see, so a tool listed available may still answer it. Nothing is quoted, executed, or charged by any of the three, and none is retryable as sent: each needs a deploy to change.

An ordinary MCP client should read this object before calling a tool: an available of false means the call would be refused before anything ran, so making it buys nothing at all, and reason already names the code that refusal would carry. An x402-aware client may ignore it, and lose nothing by doing so: it learns the same facts from the payment challenge on the call itself.

Contacts

Three addresses, all monitored, all reaching the operator of this deployment. They accept mail from anyone; no account or prior relationship is needed.

These are the contacts the paid public data terms mean when they say the support and security contacts are published in the service discovery document. Mail is received at these addresses; nothing is sent from this domain, so a reply will come from the operator directly.

Machine-readable surfaces