{"version":"1.2","checkout_guide":"https://trusteed.xyz/.well-known/agent-checkout-guide.json","spec":"https://trusteed.xyz/en/for-merchants","generated_at":"2026-10-07T06:10:03.268Z","total_merchants":0,"total_merchants_all_types":3,"network_status":{"total_production_merchants":0,"eligible_production_merchants":0,"eligible_merchants_all_types":2,"total_merchants_all_types":3,"accepts_real_payments":false,"accepts_real_payments_basis":"no_settlement_rail_in_production","accepts_real_payments_contract":{"applies_to":["network_status.accepts_real_payments","merchants[].accepts_real_payments"],"states":{"true":"This merchant can settle real money. Not currently reachable: it requires a per-merchant settlement fact that the upstream directory does not publish yet.","false":"Derived as impossible, not merely unobserved: no settlement rail is in production, so nothing can be charged over one. Read accepts_real_payments_basis for which derivation produced it.","null":"UNKNOWN. A settlement rail is in production, so the platform-wide derivation no longer holds, and this registry has no per-merchant settlement fact to replace it with. Absence of a claim, never a claim of absence."},"valid_test":"Treat anything that is not exactly true as 'do not assume you can be charged'. That is the only correct test, and it stays correct if a fourth state is ever added.","invalid_test":"Do NOT write `accepts_real_payments === false` to decide it is safe to proceed: this field has three states, and null — which means we do not know — would fail that comparison and silently take the branch meant for 'we are sure nobody charges'. Same for `=== true` as a refusal test; compare against true positively instead."},"reason":"beta_closed","agent_guidance":"Network is in Beta and closed for real money: no settlement rail is in production, so no merchant among the 3 registered can charge over one — see accepts_real_payments_basis. Discovery, search and checkout previews work; settlement does not. Do not attempt a purchase you expect to be charged for. 0 of 0 production merchants currently meet the published agent-API eligibility rule.","closure_horizon":{"opens_at":null,"status":"no_committed_date","note":"No opening date is committed anywhere on the platform, and none is invented here: opens_at is null because no such date exists, not because this document omitted it. Do not infer a timeline from the absence, and do not infer permanence either. This registry is rebuilt on every request, so re-read reason and accepts_real_payments rather than scheduling against a date this document cannot give you."},"production_merchants_classified_by_default":0,"eligibility_blockers":{"verification_below_basic":0,"trust_score_below_threshold":0,"trust_score_unknown":0,"both":0,"note":"Which half of eligibility_rule fails, counted over production merchants with the same predicate and thresholds as each row's meets_agent_api_eligibility. A merchant failing both sides is counted once, in `both`, so these add up to the non-eligible production merchants and never double-count. `trust_score_unknown` is NOT a low score: it means no score has been measured, which the rule treats as not met (fail-closed) without claiming the merchant scored badly. Read this before inferring why the network has no eligible merchant: a verification blocker and a score blocker have different causes and different time horizons."},"eligibility_rule":"Counted with the rule /.well-known/agent-commerce.json publishes: verification level BASIC or above AND trust_score >= 0.3. It is the same rule POST /api/v1/search applies, with one difference that matters: search does NOT additionally filter by merchant_type, so eligible_merchants_all_types — not eligible_production_merchants — is the population search can return. Counts are taken over every registered merchant and do not change with ?include=."},"canonical_domain":"https://trusteed.xyz","data_source":"https://api.trusteed.xyz","partial":false,"unavailable_sources":[],"data_source_note":"This registry is served from canonical_domain but its data is read from data_source. The two hostnames may be served by the same deployment or by different ones, and this document does not assert which: compare the `deployment` field of GET /api/v1/health on each host. Equal values mean the same database, and a field read here and a field read from the MCP endpoint are one observation. Different values mean two databases: verification_level, trust_score, product_count and freshness then describe data_source's database, and the same merchant can report a different verification_level and trust_score depending on which host you ask — both signed, both valid, neither stale — so treat them as two observations. This document-level data_source names the backend queried to build the whole list; spec-066 I2 adds a data_source field on EACH merchant object naming that merchant's own home — the two can differ once a store moves.","deprecated_domains":["https://www.agenticmcpstores.com","https://agenticmcpstores.com","http://www.agenticmcpstores.com","http://agenticmcpstores.com"],"endpoint_template":"https://trusteed.xyz/{storeSlug}/mcp","endpoint_template_by_bucket":"https://trusteed.xyz/{storeSlug}/mcp/{discovery|customer|checkout}","endpoint_migration_note":"endpoint_template is the legacy unified MCP alias. Its Sunset header is a migration target, not proof that every merchant has a working successor: retirement is deferred while a per-store canary roster exists. endpoint_template_by_bucket is the declared successor. Its availability is per merchant, not global: each merchant object carries mcp_endpoints_by_bucket_availability, and 'canary' means those URLs MAY answer 404 (code bucket_not_enabled_for_store). This registry cannot resolve canary membership itself: the roster lives in the API deployment's configuration. Probe order: POST tools/list to each merchant's bucket endpoint, then fall back to that merchant's unified endpoint on bucket_not_enabled_for_store. A GET 404 does not prove a bucket is closed. Read the actual Sunset response header for the target deployment; do not assume the date in this index reflects its environment override.","canonical_scope":"Public merchant registry for agent discovery. Lists active stores with trust scores, freshness tiers, and MCP endpoints. For agent policies see agent-policy.json.","description":"Public registry of merchants available on Trusteed. Each merchant exposes an MCP endpoint for agent-based product discovery and checkout.","environment_note":"Default listing is merchant_type:'production' only — sandbox/platform-docs/app_review/test stores are provisioning and review-flow artifacts, not merchants a checkout-capable agent should treat as real. Pass ?include=sandbox,test (any of sandbox,platform-docs,app_review,test, or ?include=all) to see the rest; total_merchants_all_types reports the unfiltered count so this filtering is never silent. 'production' = real merchant with real products, 'sandbox' = demo/test store with simulated data, 'platform-docs' = platform self-indexing for capability discovery, 'app_review' = store auto-provisioned by an app marketplace review flow (Shopify or similar), 'test' = ad-hoc test signup, which includes stores whose slug derives from a development tunnel host (ngrok, trycloudflare, localtunnel and similar). app_review/test are classified by slug pattern, not a stored field — treat catalog freshness and trust_score as more reliable signals than this label. Whether any merchant settles real money is NOT asserted here in prose — read network_status.accepts_real_payments together with network_status.accepts_real_payments_basis, which names why it holds. That fact is currently PLATFORM-WIDE, not per merchant: this registry's upstream directory publishes no settlement field per store, so what is derived is a floor — no settlement rail is in production, therefore no merchant can charge over one. The day a rail does settle, the floor stops holding and the field goes null (unknown) rather than flipping to a claim nobody measured. This sentence used to claim 'false for all merchants during Beta'; a hand-written claim about a computed fact is how a document starts lying without anything breaking.","eligibility_note":"Each merchant carries meets_agent_api_eligibility, the rule published in /.well-known/agent-commerce.json → eligibilityRequirements (verification level BASIC or above AND trust_score >= 0.3) evaluated against that merchant's current values. A merchant listed here with meets_agent_api_eligibility:false is registered and reachable at its MCP endpoint but will not surface in /api/v1/search results. Listing and eligibility are two different facts and this registry publishes both rather than filtering one away.","deprecated_fields":[{"field":"inventory_freshness_minutes","successor":"catalog_freshness_minutes","sunset":"2027-03-10T00:00:00Z","note":"Named 'inventory' but measured the store's sync ATTEMPT (last_sync_at), not the catalogue an agent reads: a skipped or failed sync stamped freshness with no new product. Its value is unchanged and it will keep answering until sunset. Read catalog_freshness_minutes for the age of the data, sync_attempt_age_minutes for the old meaning under an honest name."}],"related_documents":{"agent_policy":"/.well-known/agent-policy.json","agent_commerce":"/.well-known/agent-commerce.json","agent_trust_manifest":"/.well-known/agent-trust-manifest.json","mcp_server_card":"/.well-known/mcp.json","mcp_manifest":"/mcp.json","llms_txt":"/llms.txt"},"merchants":[]}