Eclipse Warranty
Warranty registration witness for agent purchases: binds serial, buyer mandate, and retailer receipt into one transferable claim pack. LOCAL/fixture scope only — the pack is a witness record, not a warranty contract; no adjudication, coverage, or enforceability is claimed.
status: in-developmentclass: mcpTrust & ReceiptsAgent Commerce / Procurement
Vendor: Cyan Eclipse Technologies
What it does
- Novel mechanism — the claim pack is transferable on resale because it is bound to the product serial + sealed purchase proof (buyer mandate ref + retailer receipt ref), not to a retailer account login. verify_pack recomputes the seal from the serial, bindings, and transfer chain alone — no account credential, no original-holder proof. Bench: register → transfer in one process, then verify_pack by pack_id only in a fresh process = VALID with the original holder uninvolved; the exported pack object also verifies VALID in the fresh process with bindings intact.
- Sealed bindings + chained transfers: the five bindings (serial, product_ref, buyer_mandate_ref, retailer_receipt_ref, purchase_ts) are immutable at registration; transfer appends a chained record (each transfer's prev_seal equals the actual superseded seal, genesis prev_hash GENESIS) and re-seals without ever editing the bindings. Bench tamper matrix: 5/5 bound fields → INVALID, 11/11 chain tampers → INVALID, 6/6 supplied-pack attacks (seal transplant, naive SHA-256 reseal without the HMAC key, chain truncation + holder rollback, replayed duplicate transfer, seal deleted, mandate swap) → INVALID; a tampered pack refuses transfer with PACK_INVALID and claim_check reports transferable:false.
- Full-content seal (v0.1.1 fix for bench defect D1, MEDIUM): the seal now covers the complete pack object minus the seal field, and verify enforces strict structure — any key outside the specced top-level/binding/transfer sets, a missing or wrong-typed field, or a scope/seal_type outside the spec vocabulary (scope must be exactly LOCAL/fixture) verifies INVALID, supplied or stored. get_pack refuses structurally out-of-spec stored packs (PACK_INVALID) instead of serving injected or relabelled content as sealed pack content. Re-bench D1 attacks PASS 26/26, including bindings.injected_coverage = 'lifetime-full' and a top-level scope relabel to 'LIVE/production' — both INVALID.
- Advertised schemas enforced at dispatch (v0.1.1 fix for bench defect D2, LOW): required fields present, declared types exact (an int purchase_ts or a list serial is a clean validation error, never coerced via str()), and extra argument keys rejected per additionalProperties: false. Re-bench D2 attacks PASS 24/24 — every rejected attempt registered nothing, a serial burned by a rejected attempt remains registrable with correct types, and rejected calls left a good pack untouched and VALID.
- Disclosed seal break (not hidden): packs sealed under v0.1.0's projected seal verify INVALID under v0.1.1 — the bench crafted a pack with the exact v0.1.0 formula under the same demo key and confirmed the break is real. At LOCAL/fixture scope there is no migration: fixture packs are re-registered (SPEC Bench Fix addendum + BUILD-RECORD state this plainly). Any future scope upgrade would need a migration story.
- Honest scope: LOCAL / fixture only — registrations operate on fixture purchase records supplied by the caller (refs/strings the caller asserts); no retailer, manufacturer, or payment network is contacted. Seals are HMAC-SHA256 with a local demo key (runtime-generated into gitignored keys/demo.key, mode 0600; bench hygiene 6/6 — no key material in tree or history). Python 3 standard library only; MCP over stdio; exactly the 5 specced tools; no payment anything. The pack is a witness record, not a warranty contract: no adjudication, coverage, eligibility, or enforceability claim exists anywhere in the product.
Tools
register_warranty · get_pack · verify_pack · transfer_pack · claim_check
Platforms
- MCP over stdio
Certification
Bench verdict: CERTIFIED (local, fixture)
Certified scope: CERTIFIED (local, fixture) — Verity independent bench 2026-10-26, REBENCH-1 of the v0.1.1 D1/D2 fix round (repo @ 6fd6784): 96 probes recorded, 95 asserted PASS, 0 FAIL, 1 observation (O1, design-consistent, no condition attached). D1 attacks PASS 26/26 (supplied-pack injections/relabels/wrong-types → INVALID; store copies → INVALID + transfer refused; get_pack structural refusal 3/3); D2 attacks PASS 24/24 (wrong-type and extra-field arguments rejected cleanly on all five tools, zero coercion, nothing registered by a rejected call); P2 tamper matrix PASS 5/5 bound fields + 11/11 chain + 6/6 supplied-pack attacks; P4 negative space PASS 18/18 (unregistered serial = plain negative, duplicate serial SERIAL_ALREADY_REGISTERED, unknown tools NO_SUCH_TOOL); P1 mechanism spot-check PASS 3/3 (fresh-process verify VALID after transfer, no original holder). Prior verdict on v0.1.0 (VERDICT.md): CONDITIONAL (local, fixture), 67 asserted PASS / 0 hard FAIL, defects D1 (MEDIUM, unsealed-field injection) + D2 (LOW, schemas unenforced) — both closed by this re-bench. The v0.1.0 seal break is verified real and its disclosure judged honest and complete for LOCAL/fixture scope: packs sealed under v0.1.0 verify INVALID under v0.1.1, no migration, fixtures re-registered. Scope = LOCAL/fixture only: caller-supplied fixture purchase refs, stdio transport, HMAC-SHA256 demo seal with a local demo key. The pack is a witness record, not a warranty contract — no adjudication, coverage, eligibility, or enforceability is claimed by the product or tested here. Observation O1 stands on the record: get_pack refusal is structural-only by design (a pure value tamper is still returned by get_pack but gated everywhere it matters — verify INVALID, claim_check transferable:false, transfer refused); consumers must treat verify_pack, not get_pack, as the validity gate (SPEC §5.3). Bench note D3 (informational, by design): transfer requires no holder authorization — possession of pack_id is a bearer capability, exactly as SPEC §3/§5 specify for v0.1; it must be revisited before any hosted/live scope.
Not tested:
- Live retailer, manufacturer, or payment integration — not in v0.1.1 by design: no third party is contacted and no claim is filed anywhere; registrations operate on caller-supplied fixture refs only
- Hosted or remote serving — v0.1.1 is local stdio only; transfer is a bearer capability on pack_id possession (bench D3, informational, by SPEC design) and must be revisited before any hosted/live scope
- Warranty adjudication, coverage, eligibility, or enforceability — none exists in the product at any scope; the pack is a witness record, not a warranty contract
- Migration of v0.1.0-sealed packs — none exists by disclosed design: v0.1.0 packs verify INVALID under v0.1.1 and fixture packs are re-registered (SPEC Bench Fix addendum)
Live state note: Bench evidence: argus-batch-20261026/bench/warranty/VERDICT.md + REBENCH-1.md (Verity, independent bench over stdio JSON-RPC only, store copies only). This bench issued no test-bench/results scorecard; scorecard_ref is null and no scorecard is claimed or hosted for this product.
Pricing
FREE — free local v0.1.1; funnel role: free warranty registration drives Eclipse Procure order volume and Till receipts. No payment anything in this server — no price, no checkout, no payment language applies.
Install / verify
No install command is published for this product in the catalog or its registry record.
Official MCP Registry name: io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-warranty-mcp
Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC%2Feclipse-warranty-mcp/versions/0.1.1
Repository: https://github.com/CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-warranty-mcp
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).
Verification
Issued by Verity (Cyan Eclipse Technologies) — a role-separated internal desk of the same company that publishes this catalog. Issuer relationship: first-party. The bench is not an external third-party evaluator.
Availability
Catalog status: in-development
Distribution: MCP over stdio
Live-state note (from the catalog record): Bench evidence: argus-batch-20261026/bench/warranty/VERDICT.md + REBENCH-1.md (Verity, independent bench over stdio JSON-RPC only, store copies only). This bench issued no test-bench/results scorecard; scorecard_ref is null and no scorecard is claimed or hosted for this product.
Test verdict
Bench verdict: CERTIFIED (local, fixture)
Certified scope: CERTIFIED (local, fixture) — Verity independent bench 2026-10-26, REBENCH-1 of the v0.1.1 D1/D2 fix round (repo @ 6fd6784): 96 probes recorded, 95 asserted PASS, 0 FAIL, 1 observation (O1, design-consistent, no condition attached). D1 attacks PASS 26/26 (supplied-pack injections/relabels/wrong-types → INVALID; store copies → INVALID + transfer refused; get_pack structural refusal 3/3); D2 attacks PASS 24/24 (wrong-type and extra-field arguments rejected cleanly on all five tools, zero coercion, nothing registered by a rejected call); P2 tamper matrix PASS 5/5 bound fields + 11/11 chain + 6/6 supplied-pack attacks; P4 negative space PASS 18/18 (unregistered serial = plain negative, duplicate serial SERIAL_ALREADY_REGISTERED, unknown tools NO_SUCH_TOOL); P1 mechanism spot-check PASS 3/3 (fresh-process verify VALID after transfer, no original holder). Prior verdict on v0.1.0 (VERDICT.md): CONDITIONAL (local, fixture), 67 asserted PASS / 0 hard FAIL, defects D1 (MEDIUM, unsealed-field injection) + D2 (LOW, schemas unenforced) — both closed by this re-bench. The v0.1.0 seal break is verified real and its disclosure judged honest and complete for LOCAL/fixture scope: packs sealed under v0.1.0 verify INVALID under v0.1.1, no migration, fixtures re-registered. Scope = LOCAL/fixture only: caller-supplied fixture purchase refs, stdio transport, HMAC-SHA256 demo seal with a local demo key. The pack is a witness record, not a warranty contract — no adjudication, coverage, eligibility, or enforceability is claimed by the product or tested here. Observation O1 stands on the record: get_pack refusal is structural-only by design (a pure value tamper is still returned by get_pack but gated everywhere it matters — verify INVALID, claim_check transferable:false, transfer refused); consumers must treat verify_pack, not get_pack, as the validity gate (SPEC §5.3). Bench note D3 (informational, by design): transfer requires no holder authorization — possession of pack_id is a bearer capability, exactly as SPEC §3/§5 specify for v0.1; it must be revisited before any hosted/live scope.
Publication integrity
Receipt hash: none published — no receipt is linked to this record in the current records
Anchor state: NOT_ANCHORED No receipt hash is linked to this record in the published records; verdict anchoring ships with Phase-1 D2 of the Eclipse Anchor program.
Full verification view — integrity result, digests, and evidence for this listing.
Operational status
Trust state: UNVERIFIED · Drift: UNKNOWN
Benched version: — · Latest seen: 0.1.1
Verify it yourself
- Cross-check the verdict and scope against this product's record in the append-only verdict feed (/verdicts.json) — corrections arrive only as superseding records.
- On-chain: not yet available for this verdict — no receipt is linked to it in the published records (per-verdict anchoring arrives with Phase-1 D2). The scorecard and the verdict feed are the complete published record until then.