# Engrava 0.5.0: a first-class MCP server

> Source: <https://dev.to/sovantica/engrava-050-a-first-class-mcp-server-2djc>
> Published: 2026-08-22 20:36:42+00:00

Engrava 0.5.0 pulls the MCP server out of the library.

Install `engrava`

now and you get the memory library and nothing else. The server ships separately, as `engrava-mcp`

. The two were never really the same kind of thing — one is a dependency you import, the other is a process your MCP client spawns — and keeping them in one package meant everyone who installed the library also pulled in the server's dependencies, whether or not they ran a server. Splitting them gives each a clean install surface.

If you build directly on the Python API, nothing about your install changes:

```
pip install engrava
```

If you want Engrava as a memory server for an MCP client, reach for the standalone package instead:

```
uvx engrava-mcp
# or
pip install engrava-mcp
```

`engrava-mcp`

is a native stdio Model Context Protocol server that sits in front of an Engrava store. It exposes read tools, optional write tools, `engrava://`

resources, and guided prompts to any MCP client that speaks stdio.

It's also listed in the official MCP Registry as `ai.sovantica/engrava`

— PyPI package `engrava-mcp`

, stdio transport — so a client that reads the registry can find it without you wiring anything by hand.

One detail that looks like a mismatch and isn't: the library is `engrava`

0.5.0, but the server you install is `engrava-mcp`

0.5.1. The two version independently. `engrava-mcp`

follows Engrava's minor line rather than its patch releases — every 0.5.x build targets `engrava>=0.5,<0.6`

— so it moves on its own patch schedule underneath. Today that lands at 0.5.1.

In 0.4 the server rode along inside `engrava`

as the `engrava[mcp]`

extra. In 0.5 it graduates to a package of its own:

| Before | After |
|---|---|
`pip install "engrava[mcp]"` |
`pip install engrava-mcp` or `uvx engrava-mcp`
|
`engrava-mcp` installed by `engrava`
|
`engrava-mcp` installed by the standalone package |
MCP client command: `engrava-mcp`
|
MCP client command: `uvx` , args: `["engrava-mcp"]`
|

This only breaks you if you were running Engrava as an MCP server. A plain `pip install engrava`

library upgrade is untouched, and the server still reads the same `engrava.yaml`

or database path it always did — what moves is the install command and the launch command your client uses.

The packaging is the visible change, but the library moved too, mostly around retrieval and the audit path:

`store.verify_journal()`

, or from a shell with `engrava --db engrava.db verify`

.`session_id`

and `actor_id`

.There's also a set of opt-in lifecycle features you can switch on and evaluate against your own workload: consolidation activation, deterministic memory hygiene, and caller-side whole-turn assembly. They ship in 0.5.0, off by default; whether they earn a place in your setup is yours to judge.

`engrava`

is the library, `engrava-mcp`

is the server — install whichever you need:

```
pip install engrava
uvx engrava-mcp
```

Code and server docs: