Four tools your agent can call.

The MCP server is client-neutral by design. It speaks stdio, it works in Claude Code, Cursor, Codex, or anything else that speaks MCP, and it exposes no vendor-specific behaviour.

7 min read · 7 sections

Configuring the server

json
{
  "mcpServers": {
    "mneia": {
      "command": "mneia-mcp",
      "env": {
        "MNEIA_TOKEN": "<token>"
      }
    }
  }
}

Omit env if you ran mneia login — the server reads the same ~/.mneia/credentials the CLI wrote. The project binding comes from .mneia/config.json in the working directory, so an agent working in a bound repository needs no further configuration.

Configuration is resolved before the server accepts a connection. A missing token, an empty token, a malformed endpoint, or an unparseable project config stops the server at startup with a message naming the variable at fault.

The tools

ToolCall it when
mneia_rehydrateStarting a task, and whenever the task changes. Cheap, safe to call unconditionally
mneia_assertOne thing is settled mid-session and should not be lost
mneia_checkpointA batch of items is being captured at a task or day boundary
mneia_searchYou already know the specific thing you are looking for

mneia_rehydrate

Loads the minimal high-signal slice for the task about to start: the active constraints that must not be violated, the decisions already made and why, the open questions, and what was recently superseded so it is not re-proposed.

Returns rendered markdown plus the slice id and the ids of the included items, so a later checkpoint can be correlated with what the agent was actually shown. Its p95 latency budget is 300ms — a rehydration nobody waits for is a rehydration nobody calls.

Reach for mneia_search instead when you already know what you are after. Rehydration answers "what do I need to know here?"; search answers "where is this one thing?".

mneia_assert

Records one durable item as soon as it is settled, without waiting for a checkpoint. Use it the moment a decision is made, a constraint is stated, or a question is left open.

Pass supersedesId when the item replaces an existing one. A replacement of a human-confirmed item is never written automatically — it comes back pending for a human to confirm.

mneia_checkpoint

Records a batch of already-extracted items as one atomic checkpoint. Hand it the candidate decisions, constraints, open questions, facts, and artifact refs extracted from the session.

It does not read the transcript itself. Extraction is the agent’s job, and the boundary is explicit for the same reason: ambient capture produces noise, and a batch a human can review produces a record worth trusting.

  • Candidates that are load-bearing are held in a pending queue rather than written.
  • Candidates that supersede an existing item are held too.
  • The pending queue must be surfaced to a human verbatim — summarising it is how the disagreement a person needed to settle gets erased.

How failures come back

Arguments are validated before anything is read or written, so an invalid call changes nothing. Every failure carries a code, a summary of what went wrong, and a remedy stated in terms of what to do next.

CodeMeaning
invalid_argumentsThe arguments did not validate. Nothing was read or written
tool_not_availableA real Mneia tool this server did not load, or one that ships in a later milestone
unknown_toolNot a Mneia tool at all
tool_failedA fault in the server. Retry once; then continue without it and report the failure rather than assuming the answer

mneia_handoff_create and mneia_handoff_receive ship in M2, and mneia_conflicts in M4. The server names the milestone rather than returning "unknown tool", so an agent can tell "not yet" from "wrong name" and stop retrying.