Cyan Eclipse Till MCP

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio (HTTP transport on roadmap)

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

Problems it addresses

• My agent can find tools on the Bazaar but has no governed way to buy one — no quote, no mandate check, no receipt
• A seller took payment and never delivered, and the refund depended on someone answering email
• I need to prove exactly what my agent bought, at what all-in price, and under which refund terms

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: test-bench/results/eclipse-till-mcp-2026-10-25-2.json