Atlas Mcp

MELRA

Modular Execution Layer for Reliable Autonomy

The open-source autonomy kernel

The LLM reasons. The harness manages the loop. MELRA owns the effect lifecycle.

An agent-independent effect runtime for governed, durable, and verifiable autonomous execution. MELRA begins where the tool call leaves the model loop.

Your models can change. Your agents can change. Your execution foundation shouldn't have to.

> [!WARNING] > MELRA is an alpha release. Its local stdio runtime is tested end to > end, but APIs may change before 1.0. Use an isolated workspace, keep domain > and command allowlists narrow, and review every consequential approval.

Durable Core Alpha — 0.3.0-alpha.11

| Shipped in this source release | Evidence | |---|---| | Restart-safe bounded workflows across nine node kinds | Real MCP process is stopped, replaced, and resumed in E2E | | Encrypted exact task, workflow, and result payloads | AES-256-GCM storage plus plaintext-leak checks across SQLite/WAL and public projections | | Eleven MCP tools for tasks and workflows | Container and stdio discovery checks require the exact tool set | | Recovery without silent mutation replay | 8/8 deterministic recovery scenarios, zero duplicates, zero false success | | Loopback HTTP transport, event stream, and read-only console | Same runtime as stdio, token on every route, 405 on any non-GET to the JSON API | | A client authenticates itself and is named on every receipt | OAuth 2.1 registration through approval to a token, then the approved client at the head of the delegation chain | | Two deployment modes, so a kernel can say whether it is the only door | --unsafe-local and a non-loopback bind are both refused under MELRA_MODE=enforced, no client can self-register, and mode is stamped on every receipt | | HTTP and API calls as a first-class effect | Same nine stages as a file write; a mutation whose reply never arrived is reported unknown rather than failed | | Agents receive capabilities, not credentials | The kernel holds the secret and scopes it by host and capability; grants carry a size as well as an expiry and are drawn down durably | | Evidence says how it is known | execution / state / independent / semantic, derived in one place from the predicate type, so a caller can tell a re-read of the target from the adapter's own word | | An effect can be confirmed by a channel that did not perform it | http_resource_matches executes through POST and verifies through a separate GET, so an accepted-but-not-done request lands partial |

---

Contents

| | | | |---|---|---| | [Why MELRA](#why-melra) | [Where it sits](#where-it-sits-) | [Quickstart](#quickstart-) | | [Reference effect adapters](#reference-effect-adapters-) | [Where to use it](#where-you-can-use-melra-) | [MCP tool surface](#a-deliberately-small-mcp-surface-) | | [How execution works](#how-execution-works-) | [Safe defaults](#safe-defaults-) | [Evidence](#evidence-not-leaderboard-theatre-) | | [Reproduce the scores](#reproduce-the-scores-) | [SDKs](#sdks-and-implementation-languages-) | [Repository map](#repository-map-) | | [Documentation](#documentation-) | [Contributing](#contributing-) | [Roadmap](ROADMAP.md) |

---

Why MELRA

An LLM decides what to do. A harness runs the loop that gets it there. Something still has to decide whether the resulting effect is allowed, run it exactly once, prove it worked, and survive a crash in the middle. Today that machinery is rebuilt inside every agent harness, in a way that dies with the harness.

MELRA is that machinery, factored out and made agent-independent:

> The LLM reasons. The harness manages the loop. MELRA owns the effect > lifecycle.

An effect is a named operation that changes or observes the world outside the model — file.write, terminal.execute, browser.click, computer.keyboard, http.request, database.mutate, stripe.refund, github.merge. MELRA does exactly nine things to every one of them, and nothing else:

| | MELRA does | Which answers | |:--:|---|---| | 1 | Types the effect against a strict, bounded schema | Exactly what may change? | | 2 | Classifies it as read, mutation, or destructive | How much does this matter? | | 3 | Authorises it against policy, re-checked at execution | Is this allowed, still? | | 4 | Gates it on an exact human approval phrase | Does a person decide? | | 5 | Records it durably before anything runs | What was in flight? | | 6 | Deduplicates it by idempotency key | Has this already happened? | | 7 | Runs it under a budget and a cancel signal | When does it stop? | | 8 | Verifies it against declared evidence | What proves it worked? | | 9 | Receipts it, redacted and hash-linked | What can be audited later? |

That list is the whole job. Everything upstream of it — what to attempt, in what order, and why — stays with the model and the harness.

Which is why MELRA never receives a goal. "Fix the production server" requires judgement about what is broken and what should change; that is reasoning, and it belongs to the model. The model resolves it to a bounded operation, and that is what arrives:

{ "effect": "terminal.execute", "command": "systemctl",
  "args": ["restart", "api"], "environment": "production" }

An interface that accepted the sentence would have to interpret it, and a kernel that interprets is a kernel whose guarantees depend on a model.

Most tool servers hand a model a tool and hope. A command runs, a click lands, a file is written — and "it returned without an error" is treated as success. MELRA separates the action succeeded from the goal was achieved.

🚫 Typical tool server ✅ MELRA

• Tool call executes immediately
• Success = no exception thrown
• Policy, if any, checked once
• Mutations are indistinguishable from reads
• Output is trusted
• No durable record
• Rules live inside one agent

• Plan and execute are separate tool calls
• Success = declared evidence predicates passed
• Policy re-evaluated at execution time
• Mutations need evidence and an exact approval phrase
• Page content is explicitly marked untrusted
• Redacted receipt + SHA-256 execution certificate
• Rules outlive the agent that used them

If a mutation succeeds but its required evidence is missing or false, the task is partial — never verified_success.

Agents should be replaceable. The infrastructure that owns consequences should not be. Swap the harness on Friday; the policies, approvals, credentials, workflow history, idempotency records, and receipts are still there on Monday.

Next to the two layers it is most often mistaken for:

| | Agent harness | MCP server | MELRA | |---|:---:|:---:|:---:| | Model loop and reasoning | ✓ | ✗ | ✗ | | Tools | ✓ | ✓ | via adapters | | Execution | ✓ | ✓ | ✓ | | Agent-independent policy | usually ✗ | possible | core | | Durable effect state | sometimes | rarely | core | | Idempotency across restarts | varies | rare | core | | Crash recovery without replay | varies | rare | core | | Independent verification | uncommon | possible | core | | Evidence receipts | uncommon | possible | core | | Works across agents | ✗ | ✓ | ✓ | | Credential isolation | varies | varies | core | | Hard capability boundary | varies | usually ✗ | partly shipped |

Plenty of MCP servers can do these things — this is not a claim that none of them do. The difference is that in MELRA they are the execution contract rather than a per-tool option. The boundary is partly shipped: MELRA_MODE=enforced closes every door MELRA owns, but the OS isolation that stops a harness reaching the filesystem around the kernel is the operator's to build, and there is no Unix-socket transport yet (#52). A kernel cannot verify it is the only door; enforced mode is the operator asserting that, and MELRA holding up its end.

---

Where it sits 🧭

Three layers, not two. The reasoning loop is the model and the harness together; the effect lifecycle is below both of them.

            ┌────────────────────────────────────────────┐
  reasoning │  LLM    Claude · GPT · Gemini · Llama      │
            │  reasons · decides what should happen      │
            └────────────────────────────────────────────┘
                           ▲ tool call   │ tools + context
                           │             ▼
            ┌────────────────────────────────────────────┐
   the loop │  AGENT HARNESS   OpenClaw · Hermes ·       │
            │  ATLAS · Claude Code · your own            │
            │  sessions · context · prompts · dispatch   │
            └────────────────────────────────────────────┘
                                   │  effect request
                                   ▼
            ╔════════════════════════════════════════════╗
    effects ║  MELRA — autonomy kernel                   ║
            ║                                            ║
            ║  identity · capability · policy ·          ║
            ║  authorization · credential broker ·       ║
            ║  durable execution · idempotency ·         ║
            ║  recovery · verification · evidence        ║
            ╚════════════════════════════════════════════╝
                                   │
                                   ▼
            ┌────────────────────────────────────────────┐
   adapters │  EFFECT ADAPTERS                           │
            │  files · terminal · browser · computer ·   │
            │  HTTP — planned: database · cloud · SaaS   │
            └────────────────────────────────────────────┘
                                   ▼
             Linux · macOS · Windows · APIs · cloud

Many harnesses, one execution foundation:

   OpenClaw ─┐
   Hermes ───┤
   ATLAS ────┼──→  MELRA  ──→  your systems
   Custom ───┘

Who owns what, and this does not move:

| Layer | Owns | |---|---| | LLM | Reasoning · tool selection · planning | | Harness | Conversation · prompt construction · model routing · semantic memory · agent personality · subagent reasoning | | MELRA | Effect authorization · effect execution · durable effect state · recovery · verification · evidence · credentials and capabilities |

MCP is one way to reach the kernel, not what the kernel is. MCP, CLI, SDK, and loopback HTTP all enter the same runtime, take the same policy decision, and write the same durable record.

---

Reference effect adapters 🔌

The kernel is the contract; these are its shipped implementations of it. Every one passes through the same policy, approval, budget, verification, receipt, and certificate pipeline — an adapter that skipped it would not be an adapter.

| | Adapter | What is implemented | |:--:|---|---| | 🗂️ | Files | Root-confined read, hash, atomic write, move, mkdir, and delete with symlink-escape defenses | | 💻 | Terminal | Shell-free foreground and supervised background processes with allowlists, traits, timeouts, interactive input, cancellation, and redaction | | 🌐 | Browser | Isolated Playwright sessions, semantic DOM targets, bounded artifacts, network policy, popup policy, opt-in profiles, and condition-based post-action settling | | 🖥️ | Computer | Capability discovery plus governed screenshot, pointer, keyboard, and scroll adapters on macOS and supported Linux/X11 setups | | 📡 | HTTP | GET/HEAD as reads and every other method as an approval-gated at-most-once mutation, pinned to the address the destination check resolved, with credentials injected by the kernel rather than handed to the caller |

The diagram above also shows database, cloud, and SaaS adapters. Those are designed and on the [roadmap](ROADMAP.md) — not shipped today. HTTP is, because a serious amount of autonomous work happens through APIs rather than mouse clicks, and an API effect needs the same nine guarantees as a file write.

Operational memory is a kernel service rather than an adapter: what MELRA knows about its own effects — which operation changed what, which attempt was already committed, what a previous run observed. Scoped SQLite storage with hybrid lexical ranking, episode context, confidence, freshness, expiry, supersession, provenance, and redaction. Semantic memory about the user — preferences, project context, conversation history — belongs to the harness above, not here.

---

Where you can use MELRA 🛠️

MELRA works with any MCP client that can launch a local stdio server.

| Client | Setup | Status | |---|:--:|:--:| | Claude Desktop | [docs](docs/INSTALLATION.md) | | | Cursor | [docs](docs/INSTALLATION.md) | | | VS Code | [docs](docs/INSTALLATION.md) | | | Any stdio MCP client | [docs](docs/INSTALLATION.md) | |

> [!NOTE] > A named client is marked verified only after the released artifact — > not a source checkout — passes discovery, planning, approval, execution, > cancellation, and receipt retrieval in that client. Current per-client status > is tracked in [COMPATIBILITY.md](docs/COMPATIBILITY.md).

What people actually do with it

| | Use case | Small example | Verified outcome | |:--:|---|---|---| | 👩‍💻 | Coding clients | Inspect a repository, run pnpm check, write a bounded file change | Exit code, file existence, content, or hash | | 🌐 | Browser workflows | Open an allowlisted page, inspect it, fill a form after approval | Final URL and page content | | 💻 | Terminal automation | Run a shell-free build or supervise a background process | Exit code and bounded stdout | | 🖥️ | Computer use | Discover local support, capture a screenshot, approve pointer or keyboard input | Adapter result plus declared evidence | | 🧠 | Project memory | Store a test command, architectural decision, or operating procedure | Scoped record with provenance and redaction | | 🔁 | Durable workflows | Inspect, write an approved artifact, restart between nodes, then checkpoint | Ordered events, independent file evidence, receipt, and certificate |

Show a governed terminal operation

A coding client submits one bounded operation with the evidence it expects:

{
  "goal": "Run the repository checks",
  "operation": {
    "kind": "terminal",
    "action": "run",
    "command": "pnpm",
    "args": ["check"]
  },
  "requiredEvidence": [
    { "type": "exit_code", "value": 0 }
  ]
}

The task reaches verified_success only if the process exits 0. A process that runs and exits 1 is a completed action with failed evidence — reported as partial.

Show scoped project memory

pnpm melra run --request examples/07-project-decision-memory/task.json

Records are scoped, provenance-tagged, and pass through secret redaction before they are persisted.

See all [runnable examples](examples/README.md) — browser inspection, verified file writes, terminal checks, scoped memory, and computer capability discovery.

---

Quickstart 🚀

npm (fastest — needs Node 22+):

npx @melra/cli@alpha setup

One command: writes a safe local policy, prints a ready-to-paste MCP client config, and runs every readiness check. Add --client claude|cursor|vscode|codex to label the config for a specific client. Use doctor alone to check readiness without writing anything.

Container (no Node install needed):

docker run --rm ghcr.io/xagi-lab/melra:alpha doctor

Prebuilt release: Download from the releases page, extract, and run:

tar -xzf melra-node-.tar.gz -C melra
node melra/dist/bin.js doctor

From source (for development):

git clone https://github.com/XAGI-Lab/melra.git
cd melra
corepack enable
pnpm install --frozen-lockfile
pnpm build
pnpm melra setup

GoalCommand Set up policy, client config, and readiness

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: XAGI-Lab
• Source: XAGI-Lab/melra
• License: Apache-2.0
• Homepage: https://xagilab.com/research/#melra-benchmarks

Install and usage instructions live in the source repository linked above.