Eclipse Till MCP
Bazaar checkout for agents — quote, mandate, signed entitlement, delivery, receipt, refund.
status: in-developmentclass: mcpMarketplace Commerce
Vendor: Cyan Eclipse Technologies
What it does
- The Bazaar purchase MCP — a separate server from the discovery Bazaar MCP, whose certified no-purchasing surface is untouched and never extended
- Quotes bind catalog hash + pricing version + terms hash and state the all-in total (price + rail fee + tax as stated); the refund policy renders inside the quote before payment and is hashed into both receipts; a SKU with no pricing record is unbuyable (PRICING_NOT_SET) and an unknowable tax component blocks the quote by name
- Mandate gate in fixed order — authenticity, cap vs ALL-IN (a 25.00 item against a 25 cap refuses: fees make it 25.72), merchant/SKU allowlist, expiry/revocation, approval threshold — every refusal by name; cross-quote replay refused, same-quote retry idempotent
- Over-threshold purchases park in AWAITING_BUYER_APPROVAL, releasable only by the same buyer identity; no nudge, countdown, or pressure verb exists on either surface
- Herald-shape signed entitlements: buyer-bound (wrong presenter refused by name), offline-verifiable, revocable with a receipted reason; two-sided hash-chained receipts share one settlement reference
- Non-delivery is a state machine: miss the delivery window and refund + entitlement revocation + cap restoration fire automatically on a plain status read — no seller override verb exists; related-party purchases settle flagged and are excluded from ranking inputs
- B0 is sandbox test credits only (value_class: test on every artifact); no Stripe or x402 code exists in the build; real rails are B1, owner-gated
- Ads Rail P1 (test mode) extension: a separate ads_server.py surface enforces a Herald-signed budget mandate at charge time — card binding, freeze state, snapshot ceilings derived from the signed mandate, and all-in headroom — with the decision and reservation durably recorded before the webhook responds; captures, reversals, and settlements reconcile into the same evidence chain. Stripe TEST MODE ONLY (local simulator in this environment); live-mode keys refuse startup in code. NOT PROVEN IN STRIPE.
Tools
catalog_price · quote_get · purchase_execute · buyer_approve · purchase_status · entitlement_list · entitlement_verify · delivery_status · refund_request · receipt_get · sku_pricing_set · sales_ledger_read · entitlement_revoke · dispute_pack_get · anomaly_queue_read
Platforms
- MCP over stdio (HTTP transport on roadmap)
Certification
Bench verdict: CERTIFIED(local)
Certified scope: CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25, 23 pass, 1 na of 24 checks (U1 auth: stdio process boundary). Run by W-003 (Verity), suites/till.py. Run 1 PARTIAL card retained append-only (bench-suite defects); run 2 is the standing card; zero product defects. Benched against a bench-owned catalog and bench-minted buyer cards/mandates (the builder's fixtures were never used). Ads Rail P1 extension: CERTIFIED(local/simulator) — Eclipse Bazaar Test Bench 2026-10-25, 100/100 on the scoped D1–D4 re-bench (scorecard eclipse-till-mcp-2026-10-25-3.json; 31/31 re-bench checks pass; the original PARTIAL 76/100 frame is retained in the card's provenance note). The rail is Stripe TEST MODE ONLY, runs against the labeled local simulator in this environment, and is NOT PROVEN IN STRIPE: no Stripe test account was wired, W2 is not proven, and no card was attached to any ad platform.
Not tested:
- Real payment rails — B0 settles on the sandbox test-credit ledger only; Stripe (card) and x402 rails are B1, owner-gated with a counsel note; no Stripe/x402 code exists in the B0 build (the Ads Rail P1 extension adds Stripe TEST MODE code only; see the extension note)
- Live Bazaar catalog join — B0 ships a 7-SKU fixture subset modeled on bazaar-mcp/catalog.json; the discovery MCP is read as data only, never extended or written
- Third-party sellers (B3) — certify-before-you-sell gates, seller vetting, 85/15 split computation, and seller payout/tax operator processes are spec'd, not built; B0-B2 are first-party only
- Auth enforcement beyond the stdio process boundary (bench U1 class) — buyer identity is cryptographic (Herald-shaped cards + signed mandates), operator verbs require the fixture operator token; hosted transport auth is a B1 design item
- Ads Rail in Stripe itself — NOT PROVEN IN STRIPE: no Stripe test account exists in this environment, so the rail's proof is against its labeled local simulator plus the code path that activates only with a Stripe test key; W2 (real Stripe sandbox behaviour) remains unproven and the live gate stays blocked.
- Live Stripe Issuing, real-money funding, and ad-platform card attachment — not built or attempted; the test-mode fence refuses live-mode keys at startup.
Bench scorecard (evidence): https://eclipsebazaar.com/cards/eclipse-till-mcp-2026-10-25-2.json
Pricing
Free local v0.1 (B0 sandbox); marketplace take is a B3 design item (85/15 creator split requires owner confirmation, spec D3)
Install / verify
docker run -i ghcr.io/cyan-eclipse-technologies-llc/eclipse-till-mcp:latest
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).