Cyan Eclipse Orbit MCP

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Governing proxy (the Eclipse WRAP posture) in front of HubSpot's official MCP server: policy, approval gates, masking, and receipts around the vendor's tools
• Pinned classification registry: unclassified vendor tools are invisible to clients; vendor T3 tools (delete, bulk) are classified but never surfaced in v1
• Drift defense: if a vendor tool's tier rises under the wrap, the proxy halts it and emits a notice receipt until an owner clears the halt by name
• T2 calls (ticket reply send, deal stage move) require approval tokens bound to the tool plus the exact arguments hash
• HubSpot custom objects are a declared OBJECT_GAP on every inventory view — absent from the vendor tool set and never reached around

Tools

Problems it addresses

• HubSpot's official MCP acts as the signed-in user with no approval gate
• A vendor can quietly ship a more powerful tool into my agent's hands

Not tested

• The real HubSpot MCP server (mcp.hubspot.com) — C0's vendor is a local stub shaped like its tool surface; the live wrap is C1 against an owner account (spec 11.5).
• Real OAuth 2.1 + PKCE connector flow and per-portal scope lists — recorded at live connection, not in C0.
• Free-tier tool parity of the vendor server — flagged [verify] in the spec for C1.
• Custom objects — declared OBJECT_GAP (absent from the vendor tool set); not reachable through Orbit by design (spec 11.4).
• Vendor drift against the REAL vendor inventory cadence — the drift rules are proven against stub fixtures (tier rise, added tool).

Bench scorecard: test-bench/results/eclipse-orbit-mcp-2026-10-25.json