
Eclipse Envoy MCP
The signed front door for agent-to-agent business: vetted in, tier-told, drafted — never bound without the owner.
status: in-developmentclass: mcpAgent-to-Agent Infrastructure
Vendor: Cyan Eclipse Technologies
What it does
- One owner-approved identity source generates a signed corporate Agent Card (Eclipse Herald machinery, consumed by import — never forked): capabilities program-general behind a publication lint, VOSB carried as verifiable references, SAM status stated exactly as 'renewal submitted, activation pending'
- Counterparty vetting into risk tiers R0-R3: JWS verified against the domain's JWKS, domain anchoring, certification posture hash-matched to the presented card; typosquats get their own record + similarity flags and never touch the honest org's tier or disclosure history
- Disclosure Engine renders facts per tier (T-public; T-vetted rate-card SHAPE with no numbers; T-NDA behind an owner-entered NDA record whose ID every render must cite; T-mandate) with a per-fact disclosure log and one identical no-oracle refusal shape
- Engagements bind only by the three-key rule — owner approval record + Wallet-shaped mandate reference + Herald delegation reference; no tool on either surface signs, commits, or moves funds
- All inbound content quarantined as data under Herald Security Law #1; signed, replay-protected, room-isolated envelopes; kill switches and an attention budget — no counterparty action can directly create owner work
Tools
identity_get · inquiry_open · capability_exchange · fact_request · scope_draft_open · scope_draft_revise · scope_draft_get · proposal_submit · proposal_status · room_send · room_history · attestation_submit · counterparty_register · counterparty_list · counterparty_get · disclosure_log_query · tier_set · nda_record_create · waiver_create · recognized_bench_add · engagement_inbox · proposal_pack_get · proposal_decide · engagement_attach_mandate · engagement_attach_delegation · binding_check · mandate_fact_add · room_get · engagement_closeout · kill_switch_counterparty · kill_switch_global · kill_switch_reinstate · identity_publish · identity_rotate_key · identity_retire_key · audit_review
Platforms
- MCP over stdio (two capability records via ENVOY_SURFACE; hosted split at E1)
Certification
Bench verdict: CERTIFIED(local)
Certified scope: CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25, 17 pass, 1 na of 18 checks (U1 auth: stdio process boundary). Run by W-003 (Verity), suites/envoy.py. Runs 1-2 PARTIAL cards retained append-only (bench-suite defects); run 3 is the standing card.
Not tested:
- Any live counterparty or hosted endpoint — E0 is fully offline against local fixtures (.example domains, fixture keys); E1 is owner-gated (hosting go, trademark screen, Herald root-key backup, cetech.ai flip).
- Card fetch from a counterparty's real well-known URL — E0's harness presents the card + the domain's JWKS as local files; the verification checks are the production checks, the fetch is the fixture seam.
- Herald gateway execution against real desk agents — E0 records Herald delegation REFERENCES for the three-key rule; live gateway delegation is Herald's own certified scope.
- Real Wallet mandate issuance — E0 records operator-entered Wallet-shaped mandate references; Envoy never mints mandates.
- Operator-channel authentication beyond process ownership (the standing U1 note) — E1 build decision with attributable-principal receipts required by spec 11.2.
- T-NDA fact contents are labeled E0 fixture placeholders; real T-NDA facts are human-authored into the identity source at E1.
Bench scorecard (evidence): https://eclipsebazaar.com/cards/eclipse-envoy-mcp-2026-10-25-3.json
Pricing
Free local v0.1; hosted E1 pricing TBD per spec
Install / verify
docker run -i ghcr.io/cyan-eclipse-technologies-llc/eclipse-envoy-mcp:latest
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).