Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Eclipse Constellation MCP evaluate resizing self-vm to 4 vCPU under fleet policy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Powered by Cyan Eclipse Technologies — https://cetech.ai
Eclipse Constellation — the governed, vendor-neutral VM fleet layer for agents: one policy, one receipt ledger, every cloud and hypervisor underneath.
Every cloud and hypervisor now ships its own agent surface, and each one owns exactly its own estate. What none of them provides is the layer above: who may do what to a machine, under whose authority, within what limits — and the receipts to prove it afterwards. Constellation is that layer. It is the Agent Wallet pattern transposed from money to machines: policy is written by a human, checked before anything executes, and every decision is ledgered.
Related MCP server: Dvarapala
v0.1.0, spec phase C0+ (fleet state + policy evaluation). OBSERVE-ONLY: this build contains no mutation code paths at all. Nothing in this file can start, stop, resize, snapshot, or destroy a machine — lifecycle actions exist only as policy evaluations that return ALLOW/DENY with reasons. Local stdio transport, Python stdlib only. The only target probed is this host itself, over its declared channel. No certification claimed — bench pending.
Explicitly NOT in v0.1, by spec and by the build's safety brief:
No execution adapters. ALLOW is a policy verdict, not an action. Execution lands in phase C1+ behind an owner gate.
No Tier-3 ALLOW. Destroy, network changes, and snapshot deletion require explicit human confirmation every time; the approval channel is not wired in v0.1, so Tier-3 evaluations always DENY here, with the reason stated.
The Eclipse Connect droplet is NOT a declared target. Its migration (spec §6.4: declare → read → snapshot discipline → gated mutation) is owner-gated; v0.1 declares this VM only.
Tool | What it does |
| Lists declared targets only: name, kind, address, declared channel, owner agent, desk, declared resources. Undeclared targets are invisible to every tool. |
| Evaluates a lifecycle action against policy — quotas (arithmetic shown on refusal), image + network allowlists, TTL + purpose discipline, the snapshot-before-mutation precondition, Tier-3 approval gating. Returns ALLOW/DENY + reasons + per-check results. Every evaluation is receipted, DENYs included. Evaluates only; never executes. |
| Read-only probes against a declared target over its declared channel. Probes are fixed command templates chosen by name ( |
| Probes every declared target and stores a receipted fleet snapshot with per-target status, probe results, and freshness. |
| Lists ledger receipts (evaluations incl. DENYs, probes, snapshots) and verifies the append-only hash chain. |
Targets are declared, never discovered or improvised: targets.json is the fleet's Device Registry. Each target declares its kind, address, channel (local for this host — it runs no sshd, and this build does not start one; ssh for future declared remote targets, via the system ssh client in batch mode), owner agent, desk, and declared resources. A target with no declared channel is inventory-only; the layer never invents one.
Shipped registry v0.1: one target, self-vm — this VM (2 vCPU / 8 GB declared). Declared-resource figures in targets.json and image hashes in policy.json are declared metadata: the image entries are named registry slots whose real hashes land when the first allowlisted images are registered at C1.
Quotas are caps. Per-desk and fleet ceilings on vCPU, RAM, disk, VM count. A creation that would breach a cap is refused with the arithmetic in the reason string.
Image + network allowlists. Creations boot only from registered images (name, and hash when supplied); targets join only declared networks. A new network is a policy change, not a runtime flag.
Snapshot-before-mutation is mechanical. resize, image_change, exec_push, rollout, and destroy require a fresh snapshot receipt for the same target. No snapshot receipt, no mutation — checked, not advised.
Ephemeral by default. Creations require a purpose tag and a TTL within the policy ceiling (default 24h, ceiling 168h). Permanence is a human grant.
Identity is bound. Every evaluation names its actor (agent + desk). Anonymous evaluations are denied.
Receipts are the product. Append-only, hash-chained, GENESIS-anchored — evaluations, probes, and snapshots all land in the same ledger (data/state.json, overridable via env).
Snapshot-receipt binding (v0.1 semantics, stated plainly): until execution adapters land, a qualifying snapshot receipt is the ALLOW evaluation receipt of a snapshot_create action for the same target, fresh within policy.snapshot_fresh_seconds (24h). C1 adapters will record execution receipts of the same shape; the precondition check does not change.
python3 server.py # MCP over stdio, stdlib only, no dependencies
python3 smoke.py # end-to-end smoke over real stdio (temp state)
python3 -m unittest discover tests # test suiteEnv overrides: ECLIPSE_CONSTELLATION_STATE, ECLIPSE_CONSTELLATION_TARGETS, ECLIPSE_CONSTELLATION_POLICY.
C1 — lifecycle execution under policy on the first declared adapter (owner-gated; the droplet migration is its own owner decision). C2 — exec + console layers over declared channels. C3 — a second substrate behind the same policy core, which is when the vendor-neutrality claim becomes testable, then sayable.
A Cyan Eclipse Technologies product. The "Powered by Cyan Eclipse Technologies" attribution travels with it.
Probe every declared target and store a receipted fleet snapshot with per-target status and freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that this is a write action ('store a receipted fleet snapshot') covering all declared targets and that results include per-target status and freshness, but it omits permission requirements, whether prior snapshots are overwritten, failure handling, and cost or latency characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single front-loaded sentence with no wasted preamble. 'Receipted' is slightly jargon-like without explanation, but the sentence remains efficient and action-first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no annotations and no output schema, the description gives the essential action and a hint at returned content ('per-target status and freshness'). It still leaves important gaps around persistence behavior, returned snapshot structure, and operational safety, which matter more because structured metadata does not cover them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and nothing in the description misrepresents the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific compound action (probe every declared target and store a snapshot) and names the resource (fleet snapshot). It implicitly distinguishes itself from the sibling probe_target by operating across all declared targets, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'every declared target' versus the single-target probe_target sibling, but the description never states when to use this tool instead of probe_target, receipt_list, or target_list. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a lifecycle action against policy — evaluation ONLY, nothing executes (v0.1 is observe-only). Returns ALLOW/DENY + reasons + per-check results; every evaluation is receipted, DENYs included. Args: actor {agent, desk}, target, action, params.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | ||
| action | Yes | ||
| params | No | ||
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does a good job: it discloses that nothing executes, that the result is ALLOW/DENY plus reasons and per-check results, and that every evaluation writes a receipt including DENYs. Undisclosed are permission/auth prerequisites and any rate limits on receipt-writing evaluations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact clauses, front-loaded with the no-execution guarantee, followed by return shape and the argument list. No filler sentences; every clause adds information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Absent an output schema, the description usefully covers return values and the receipt side effect, which is the hardest part to infer. For a tool with a nested actor object and zero documented parameters, though, it should also clarify valid actions and target/params shape before an agent can call it confidently on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 0% schema coverage the description must compensate, and it only partly does: it uniquely reveals that `actor` has the subfields {agent, desk}, which the schema does not. But `target`, `action`, and `params` are merely named — there is no indication of valid `action` values, what a target identifier looks like, or what belongs in `params`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Evaluate a lifecycle action against policy") and immediately pins the scope with "evaluation ONLY, nothing executes (v0.1 is observe-only)." That scope note cleanly separates it from the sibling tools, none of which are policy-check operations, so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The observe-only framing tells the agent this is the tool to call when it wants a verdict without side effects, which is a real usage condition. It stops short of naming exclusions or alternatives (e.g. use receipt_list to inspect prior evaluations), so the routing guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run read-only probes against a DECLARED target over its declared channel. Probes are FIXED templates chosen by name (identity, uptime, disk, memory, services) — there is no free-form command argument, by law.
| Name | Required | Description | Default |
|---|---|---|---|
| probes | No | ||
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well for the safety profile: it declares the operation read-only, forbids free-form command input, and enumerates the fixed template names. It stops short of covering failure modes (unknown probe name), auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with the purpose and the key constraint front-loaded, no repetition. Emphatic capitalization and the phrase 'by law' are colorful but not wasteful since they reinforce the hard constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations and no output schema, the description covers intent and input constraints but says nothing about the shape of the returned probe results or whether probes run in parallel. Adequate to invoke, thin on what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the probes array is an unconstrained string list, so the description's enumeration of valid probe names (identity, uptime, disk, memory, services) is essential information the schema lacks. It does not clarify what happens if 'probes' is omitted, given only 'target' is required, nor does it define what counts as a 'declared' target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('run read-only probes') and a specific resource/scope ('a DECLARED target over its declared channel'), plus names the concrete probe templates available. It distinguishes itself from siblings like fleet_snapshot and policy_evaluate by being per-target and read-only, though it never explicitly contrasts with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'DECLARED' hints that the target must already exist (presumably from target_list), which is a useful prerequisite signal, but there is no explicit when-to-use/when-not or named alternative such as fleet_snapshot for fleet-wide reads. Usage is implied rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ledger receipts (evaluations incl. DENYs, probes, snapshots) and verify the hash chain.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It reveals that the call performs a hash-chain verification (a non-obvious side behavior), but says nothing about whether verification is automatic, what happens on a mismatch, auth requirements, or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the core resource and record types front-loaded; nothing is wasted. It is dense but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and no parameter documentation mean the description should do much more. It omits pagination behavior, return shape, and the result of the hash-chain verification, all of which an agent needs to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The parenthetical listing evaluations/DENYs/probes/snapshots loosely hints at values for the 'type' parameter, but 'limit' is entirely unexplained and no filtering or paging semantics are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List ledger receipts') and enumerates the record kinds returned (evaluations incl. DENYs, probes, snapshots), which pins down the domain clearly. It does not explicitly contrast itself with siblings like target_list or fleet_snapshot, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus the sibling listing tools, no prerequisites, and no exclusions. The 'verify the hash chain' clause hints at an audit use case but the agent must infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DECLARED targets only (name, kind, address, declared channel, owner agent, desk, declared resources). Undeclared targets are invisible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the key scoping behavior (only declared targets appear, undeclared ones are invisible) and the return field set. It says nothing about ordering, pagination, volume limits, or whether the list is authoritative vs. cached, which matter for a zero-argument list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the scope constraint and the field enumeration, with zero redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the enumerated fields are the only return-value documentation and they are included. What's missing is minor framing: whether results are ordered, bounded, or filtered by any ambient scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter guidance because there is nothing to parameterize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List DECLARED targets') and enumerates the returned fields (name, kind, address, declared channel, owner agent, desk, declared resources), so an agent knows exactly what it gets back. It does not name or contrast with the obvious sibling probe_target, so sibling differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Undeclared targets are invisible' implies this is the wrong tool when the agent needs undiscovered targets, but it never says so explicitly or points to probe_target/fleet_snapshot as the alternative. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0fleet_snapshotpolicy_evaluateprobe_targetreceipt_listtarget_listScored across 5 tools
Each tool targets a distinct resource or operation: listing targets, listing receipts, probing a single target, snapshotting the fleet, and evaluating policy. The only potential overlap is fleet_snapshot vs probe_target, but the descriptions clearly separate aggregate snapshotting from single-target probing.
All names use snake_case, but the ordering is mixed: probe_target is verb_noun, receipt_list/target_list/policy_evaluate are noun_verb, and fleet_snapshot is noun_noun. It remains readable, but there is no single predictable pattern.
Five tools is well-scoped for an observe-only fleet observability and policy-evaluation server. Each tool earns its place, and the set is neither thin nor bloated.
The surface covers the core observe-only workflow: target listing, probing, fleet snapshotting, policy evaluation, and receipt auditing. Minor gaps exist, such as no direct snapshot-detail retrieval or target-declaration operation, but those are arguably outside the stated v0.1 scope.
Governance runtime for compliance: verified, human-approved writes to a tamper-evident record.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Deterministic allow/require_approval/deny verdicts for agent actions, before they happen.
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
