
Eclipse Haven MCP
The governed Zendesk server: OAuth-first, drafts until approved, and a receipt for every touch.
status: in-developmentclass: mcpCustomer Service / Helpdesk
Vendor: Cyan Eclipse Technologies
What it does
- Governed Zendesk MCP (public REST API v2 shape) — the BUILD-side answer for the largest support installed base, which has no official MCP server
- OAuth-first by construction: API-token auth is not implemented at all (Zendesk sunsets all API tokens 2027-04-30); presenting one is refused by name on all 10 tools
- Public replies send only as a draft plus an approval token bound to the draft's exact content hash; status/assignee changes are likewise token-gated
- Internal notes and public replies are never flattened into one visibility class
- Deletes, platform merges, bulk updates, macro/trigger edits, and refund actions are prohibited in v1
Tools
auth_status · ticket_search · ticket_get · user_get · org_get · ticket_create · ticket_update · reply_draft · reply_send · receipt_list
Platforms
- MCP over stdio
Certification
Bench verdict: CERTIFIED(simulator)
Certified scope: CERTIFIED(simulator) — Eclipse Bazaar Test Bench 2026-10-25, run 3 (re-bench after H1 fix): 13/14 checks pass, 1 na (U1), 0 fail. H1 passes: presenting an api_token credential is refused with TOKEN_AUTH_NOT_IMPLEMENTED + the 2027-04-30 sunset date on all 10 tools — auth_status and receipt_list now call check_auth first and both schemas declare the auth property; the builder regression test (enumerating S.TOOLS) was independently replicated against a pre-fix copy, failing on exactly those 2 tools. Regression spot-checks H3 (visibility non-flattening), H4 (T2 cross-ticket/changeset replay), H5 (re-draft token kill) all pass unchanged. Run by W-003 (Verity), suites/haven.py. FAILED run-2 card (eclipse-haven-mcp-2026-10-25-2.json) retained in results/ per append-only history.
Not tested:
- Any live Zendesk instance — C0 runs on synthetic fixtures shaped like REST API v2 responses; live connection is C1 against an owner-controlled instance (spec 12.5).
- Real OAuth grant flows (authorization code / client credentials) — the auth SHAPE is implemented and token auth is refused by construction; live grants need the owner's registered OAuth app at C1.
- Webhooks, incremental export, satisfaction-rating writes — not in the C0 surface.
- Feeding canonical records into Eclipse Muster live — the mapping shapes align with spec 5.1/12.3; cross-product ingest is a C1 bench item.
Bench scorecard (evidence): https://eclipsebazaar.com/cards/eclipse-haven-mcp-2026-10-25-3.json
Pricing
Free local v0.1; family pricing TBD per spec
Install / verify
docker run -i ghcr.io/cyan-eclipse-technologies-llc/eclipse-haven-mcp:latest
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).