Eclipse Lineage MCP
spawn trees, model/config lineage, and version ancestry for agents — who spawned whom, running what, changed when.
status: in-developmentclass: mcpIdentity, Trust & Reputation
Vendor: Cyan Eclipse Technologies
What it does
- Generation semantics: a behavior-relevant config change (model id, system-prompt hash, tool-surface hash, policy ref) MINTS a new generation identity as a new append-only record — a write aimed at an existing generation refuses GENERATION_IMMUTABLE by name
- Per-root hash chains, signed: lineage_verify recomputes each root's chain and names the first broken link; system prompts and configs are recorded as hashes + owner-held refs only — there is no prompt_get
- Provenance labels that never overclaim: self-emission is a subject-provided claim forever; parent+child signature corroboration is labeled corroborated — and in v0, presented corroboration strings are unverifiable by construction (no per-agent key registry), so they are labeled corroboration_unverified inside the signed record body; a spawn without a mandate ref is recorded UNMANDATED, visible, never hidden
- Hash values are shape-validated everywhere they enter (SHA-256, 64 hex chars) — non-digest values refuse HASH_VALUE_INVALID with nothing stored
- Self/consented emission only: framework emission adapters (G-LIVE per framework) and any external or hosted emission surface (G-OWNER) are held, not built; family T3 is empty — no rewrite, prune, delist or enforcement verb exists
Tools
lineage_spawn · lineage_config_change · lineage_retire · lineage_tree · lineage_verify
Platforms
- MCP over stdio — local v0.1 build; records stay on the operator's machine
Certification
Bench verdict: CERTIFIED(local)
Certified scope: CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-26, standing card run 3 (scoped re-bench): 10 pass, 0 na of 10 checks — L10/L14/L4, minors m1–m3 and spot regressions L1/L5/L8 re-probed PASS; all other lines stand as scored on run 2. Runs 1 and 2 FAILED and are retained append-only (test-bench/results/eclipse-lineage-mcp-2026-10-26.json, eclipse-lineage-mcp-2026-10-26-2.json); run 3 closed D1 (corroboration forgery), D2 (unvalidated hash values) and D3 (behavior_relevant laundering parameter) at the mechanism level, not the fixture level. CORROBORATION HONESTY — read exactly: in v0 there is no per-agent key registry, so presented corroboration strings are UNVERIFIABLE by construction; they are labeled corroboration_unverified in the signed, hash-chained record body (tamper-evident, proven at L10), and absence shapes stay claim_only. Self-emission is labeled a subject-provided claim forever; no surface upgrades a claim to a fact. CEILING: CERTIFIED(local), self/consented emission only — framework emission adapters are NOT built (G-LIVE per framework), external/hosted lineage is NOT built (G-OWNER); v0 signs with a local seed key (keys/, gitignored) and production findings-key custody is a gated decision.
Not tested:
- Framework emission adapters — NOT built (G-LIVE per framework); v0 emission is self/consented only via the MCP tools
- External emission / hosted lineage for enterprises — NOT built (G-OWNER); records stay on the operator's machine
- Production findings-key custody — v0 signs with a local seed key (keys/, gitignored, chmod 600); custody is a gated decision
Bench scorecard (evidence): https://eclipsebazaar.com/cards/eclipse-lineage-mcp-2026-10-26-3.json
Pricing
Free local v0.1; hosted lineage pricing TBD per spec (owner-gated, G-OWNER phase)
Install / verify
docker run -i ghcr.io/cyan-eclipse-technologies-llc/eclipse-lineage-mcp:latest
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).