The tools your agent can call.

mneia mcp install
mneia mcp list

The installer detects supported clients and writes each native configuration. Use mneia mcp install --client codex --yes to target one explicitly. See /docs/integrations#mcp-clients for Codex, Claude Code, Claude Desktop, Cursor, Gemini CLI, VS Code, Windsurf, and generic MCP instructions, including a complete prompt to paste into the selected agent.

The server reads the same ~/.mneia/credentials written by mneia login. 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.

All five are resolved before the server accepts a connection. A missing token, an empty token, a token with a Bearer prefix or a trailing newline, a malformed endpoint, or an unparseable project config stops the server at startup with a message naming the variable at fault and what to set it to.

That is deliberate. A server that starts and then fails every tool call is a much worse failure than one that refuses to start, because the agent has already begun working by the time it finds out.

An unrecognised MNEIA_TELEMETRY value is an error, not a fallback to the default. A typo in an opt-out must never quietly leave telemetry on, which is the one failure mode that would make the setting worthless. Two further variables, MNEIA_TELEMETRY_ENDPOINT and MNEIA_TELEMETRY_TOKEN, exist for transmitting events to an endpoint of your own; with the first unset, nothing leaves the machine that way.

The CLI reads MNEIA_TOKEN, MNEIA_API_URL, MNEIA_HOME, and MNEIA_CREDENTIALS_PATH too, so a machine configured once is configured for both. `MNEIA_TELEMETRY` is the exception: the CLI emits no telemetry of its own and there is nothing there for it to switch off - see /docs/cli#environment.

Every surface is a translation of the same verbs. If a tool would need a verb that is not rehydrate, assert, checkpoint, handoff, or conflict, that is the signal it belongs to a different product rather than a new tool here.

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?".

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.

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.

Pass the slice id from your rehydration back with the checkpoint, along with the ids of the items that actually changed what you did. That is the only signal of whether the slice was worth loading, and it cannot be recovered afterwards.

Looks up specific items by kind, status, load-bearing flag, and free text. Use it to check whether a constraint on a topic exists, to read what a decision said, or to find the id of the item you are about to supersede.

Returns a compact list with full item ids and provenance - not a ranked slice. It competes for the same context window as a rehydration, so keep the limit small.

mneia_handoff_create renders the artifact for the current project and returns it with its id and link. Name a recipient to direct it, or leave it open for whoever picks the work up. The rendered markdown is frozen at that moment; the item links stay live.

mneia_handoff_receive fetches one and marks it received. An agent resuming work should call this before rehydrating - the handoff says what the sender thought mattered, and the slice says what the store thinks matters now. They are different questions and both are worth asking.

Lists the items waiting on a human to confirm. An agent assertion that would overrule a human-confirmed item is never applied silently - it queues here instead, and stays queued until a person rules on it.

Surfacing unresolved disagreement is a tool an agent may read and must not settle. Where the disagreement is between two people, resolution is theirs to make; the useful thing an agent can do is surface it and stop, rather than picking the newer row and continuing. A dedicated mneia_conflicts tool is deferred to M4.

Records one decision a person just made on one queued item: approve marks it human-confirmed, reject retires it with the reason they gave. It is the relay for the ask your client already knows how to run - an approval prompt in Claude Code, an inline approval in Cursor, or a plain question in anything else.

The decision is never the agent’s to make. Show the item verbatim, ask, wait for the answer, and only then call this. The tool takes the actor from the token the server is authenticated with and reads its kind from the database, so a server running as an agent is refused outright rather than being trusted to say whose answer it is carrying.

• A rejection must carry a reason - months later, an unexplained rejection is indistinguishable from a mistake.
• An item a person already confirmed is refused, not overwritten.
• When the write fails, the answer says nothing was recorded, so a decision is never quietly lost.

mneia review --drain in the CLI is the terminal route to the same write, where confirm is one keypress. Neither surface can decide an item without a person.

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.

The distinction between the middle two is there so an agent can tell a name it got wrong from a tool this server is not carrying, and stop retrying in the second case.