Eclipse Consent MCP
per-agent, per-purpose consent receipts for personal data — a grant an agent must present, and a revocation that propagates.
status: in-developmentclass: mcpIdentity, Trust & Reputation
Vendor: Cyan Eclipse Technologies
What it does
- A check-gate, not a registry: a processor agent presents a consent receipt id at action time and gets ALLOW/DENY + reason + record id synchronously — a revocation is effective at the very next check, for every processor, with no sync step and no consent copies held by processors
- Provenance law: every grant names subject, grantor, grantee, purpose, data classes, capture method, capture evidence ref, captured_at and expiry — a record without provenance is void, refused at grant time and denied at check time
- Separation of duties by name: the grantee can never write its own consent (CONSENT_SELF_ASSERTED); grants issue only from the subject or a recorded delegate; revocation is subject/delegate only
- Append-only, hash-chained records; revocation is a new record that supersedes at check time, and consent_dependents returns the propagation map — exactly the processors who presented a receipt — with the revocation notices issued to them
- Purposes, data classes, capture methods and revocation sources are versioned vocabularies shipped as data (vocabularies.json), not code; consent_bulk_import / consent_extend / consent_check_skip do not exist and refuse -32602 at the transport; family T3 is empty — no enforcement verb at any tier
Tools
consent_grant · consent_check · consent_revoke · consent_history · consent_dependents
Platforms
- MCP over stdio — local v0.1 build over a local state file; no network transport
Certification
Bench verdict: CERTIFIED(local)
Certified scope: CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25: 23 pass, 1 na of 24 checks (U1 na), 0 fail — 23/23 scored checks, single bench, no fix round. CEILING — read exactly: CERTIFIED(local) over FIXTURE subjects only, and the fixture boundary is enforced by the product, not by convention: v0 refuses any non-fixture subject by name (SUBJECT_NOT_FIXTURE) and every subject in the package is synthetic. Real-subject personal-data processing is NOT built and is held at gate G-COUNSEL (spec §17); jurisdiction packs (state privacy / AI-law vocabulary variants) are NOT built (G-COUNSEL per pack) — the versioned-vocabulary mechanism they would ride on ships in v0 as data. Consumer-facing grant UX is NOT built (G-OWNER); v0 has no consumer surface at all, and no hosted or network form exists. Consent records consent; it does not manufacture it, and no output certifies any party.
Not tested:
- Real-subject personal data — NOT built, held (G-COUNSEL, spec §17); v0 refuses any non-fixture subject by name (SUBJECT_NOT_FIXTURE)
- Jurisdiction packs (state privacy / AI-law vocabulary variants) — NOT built (G-COUNSEL per pack)
- Consumer-facing grant UX — NOT built (G-OWNER); v0 has no consumer surface at all
- Hosted / live registry service form and any network transport — NOT built; v0 is a local stdio server over a local state file
Bench scorecard (evidence): https://eclipsebazaar.com/cards/eclipse-consent-mcp-2026-10-25.json
Pricing
Free local v0.1; hosted pricing TBD per spec (owner-gated phase)
Install / verify
docker run -i ghcr.io/cyan-eclipse-technologies-llc/eclipse-consent-mcp:latest
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).