Eclipse Muster MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ECLIPSE_MUSTER_STATE | No | Override for the location of the state file. State lives in data/state.json by default. | data/state.json |
| ECLIPSE_MUSTER_POLICY | No | Override for the location of the policy file. Policy lives in policy.json by default. | policy.json |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| record_ingestB | Ingest a canonical Customer Graph record (person / company / deal / ticket / conversation / activity). Every field must carry provenance; a Data Rights Ledger block is required. Customer-authored conversation text is tagged untrusted and instruction-shaped content is quarantined at ingest. |
| record_readA | Read one graph record with egress masking applied (surface: owner = full email, analytic = domain-only email; phone always partial; gov/payment/health fields null). Receipted. |
| record_searchB | Search graph records by kind + substring; returns masked summaries. The query itself is receipted by hash only. |
| merge_proposeA | PROPOSE an identity merge between two same-kind records. Returns evidence (matching keys by hash, conflicts) + a proposal hash. Executes nothing (Beacon propose-only doctrine). |
| merge_executeA | Execute a proposed graph merge. Requires the owner-confirm token bound to the proposal hash (confirm-merge-<proposal_id>-). Graph nodes only — never merges records inside a platform. The pre-merge snapshot is stored on the merge record for unmerge. |
| merge_unmergeA | Undo a confirmed merge from its receipt snapshot, restoring the pre-merge nodes exactly. Requires confirm-unmerge-<merge_id>. |
| reply_draftB | Draft a ticket reply ONLY from record facts, with a citation list. Untraceable facts become MISSING_FACT markers. Customer text is never a fact source; quarantined (instruction-shaped) messages are reported, never obeyed. |
| policy_showA | Show the tier floors, effective tiers, kill switches, and masking rules in force. |
| receipt_listB | List the append-only, hash-chained receipts and verify the chain. Receipts carry IDs + hashes only — never content. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct resource and action: record operations, merge lifecycle stages, reply drafting, policy inspection, and receipt listing. The staged merge tools (propose/execute/unmerge) are explicitly separated by required tokens and side effects, preventing confusion between them.
All nine tools follow the same noun_verb resource_action convention: record_ingest, merge_propose, reply_draft, policy_show, receipt_list, etc. There is no mixing of camelCase, vague verbs, or inconsistent ordering.
Nine tools is a well-scoped set for a governed customer graph service with ingestion, search, merge lifecycle, reply drafting, policy visibility, and receipts. Each tool has a clear role and none appear gratuitous.
The merge lifecycle is complete and governance operations are covered, but there is no explicit record update, delete, or erasure operation despite the data-rights framing. Agents can work around some gaps via re-ingest or merges, but lifecycle coverage is notably incomplete for a customer record graph.