Cyan Eclipse Haven MCP — Cyan Eclipse Bazaar

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

Certification 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.

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_statusticket_searchticket_getuser_getorg_getticket_createticket_updatereply_draftreply_sendreceipt_list

Problems it addresses

Zendesk has no official MCP server, and its API-token auth dies on 2027-04-30
An agent with helpdesk write access can send public replies with no approval gate

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: test-bench/results/eclipse-haven-mcp-2026-10-25-3.json

Evaluation-intake listing

This listing records the tool's place in the Bazaar's evaluation and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope, and not-tested items included. It is not sold on this site, and its presence in the catalog is not a claim beyond that evidence. The service behind every verdict is the bench: what a bench run buys →