Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio (HTTP transport on roadmap)
Certification scope
CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25, 16 pass, 1 na of 17 checks (U1 auth: stdio process boundary). Run by W-003 (Verity), suites/book.py. Non-failing bench observation: the probability-field guard runs post-commit (a poisoned instrument persists in state; every read of it fails closed) — pre-commit move queued for M1 hardening.
What it does
- Descriptor: market data + venue access layer — not an exchange. One canonical Instrument / Book / Quote / Order / Position / Resolution model across exchanges and prediction markets; venue adapters translate and never improvise
- Resolution criteria stored verbatim and hash-pinned: a venue criteria edit is a CRITERIA_CHANGED event, and positions keep the criteria as of entry
- Fee truth: quotes carry all-in buy/sell cost for a stated size from versioned, lineage-stamped fee schedules; a stale or missing schedule degrades all-in fields to FEE_UNVERIFIED rather than quoting a wrong number
- Resolution lifecycle REPORTED -> VERIFIED only against the criteria's own named source; DISPUTED is first-class and blocks verification until cleared
- The probability law enforced in code: no output ever carries a probability field — a runtime guard refuses probability-shaped keys in any carrier; outputs carry price + liquidity flag + depth + criteria reference; unmapped native statuses surface as UNMAPPED with the native string preserved
- M0 is data only: no accounts, no keys, no order submission at any tier; order_draft is an unsubmitted record whose mandate pre-evaluation is honestly NOT_EVALUATED
Tools
instrument_ingestinstrument_getinstrument_searchbook_ingestquote_getfee_schedule_registerfee_schedule_getposition_openposition_listposition_getresolution_reportresolution_verifyresolution_getorder_draftorder_getvenue_statusreceipt_list
Problems it addresses
- Every venue shows me a different shape for the same market, and the fees are wherever they feel like hiding them
- A market's resolution criteria changed after I took a position and nothing told me
- A dashboard showed me a 'probability' the venue never published
Not tested
- Live venue reads of any kind — M0 contains no network code path; adapters run against fixtures shaped like the real public API responses behind a transport seam. Live public-read verification is a later M0-exit step.
- Order placement, account reads, and the Wallet mandate gate — M2/M1 scope, owner-gated (spec 18, decision D3). M0 order_draft records an unsubmitted DRAFT with mandate_pre_eval NOT_EVALUATED; no submission path exists.
- Fee schedules as live data — shipped schedules are fixture-shaped records with provenance labels saying so; the live fetch + account-specific tier provenance lands with the adapters' live step.
- Kalshi / Polymarket US / Kraken / Binance.US / Alpaca chapters — specced (suite spec 10-12), not built in M0.
Bench scorecard: test-bench/results/eclipse-book-mcp-2026-10-25.json
Evaluation-intake listing
This listing records the tool's place in the Bazaar's evaluation
and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope,
and not-tested items included. It is not sold on this site, and its presence in the catalog
is not a claim beyond that evidence. The service behind every verdict is the bench:
what a bench run buys →