Quickstart

memnode has two first-class paths: a hosted SaaS flow for shared tenants and a local MCP flow for users who want everything on their own machine. Start with the one that matches how you plan to run your agents.

Hosted path

Create an account and open the dashboard.
Provision a hosted tenant for your workspace.
Create a scoped API token with `memory.read` and `memory.write`.
Validate the token with `GET https://memnode.dev/api/v1/whoami`, then send memory traffic to `https://api.memnode.dev`.

curl -sS https://memnode.dev/api/v1/whoami \
  -H "Authorization: Bearer $MEMNODE_TOKEN"

curl -sS https://api.memnode.dev/v1/recall \
  -H "Authorization: Bearer $MEMNODE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"question":"what does this agent already know about the user?"}'

If you want the hosted MCP connector path rather than plain HTTP, use Claude’s OAuth connector flow rather than pasting a dashboard token into Claude. The hosted connector metadata lives at /.well-known/oauth-authorization-server, the public install and review links live on /mcp, and raw MCP probes can reuse an OAuth-issued access token against https://api.memnode.dev/mcp.

Local MCP path

The local mode still matters. Run the Rust data plane yourself, point your MCP client at `memnode mcp`, and keep memory entirely on your own machine or repo path.

cargo run --bin memnode -- server --bind 127.0.0.1:8080
export MEMNODE_URL=http://127.0.0.1:8080
export MEMNODE_API_KEY=replace-with-your-local-api-key

Reference examples

Conversational assistant

Recall before reply, then record both sides of the turn so memory survives restarts.

examples/conversational_assistant

Coding assistant

Model projects and conventions as typed entities instead of loose text memories.

examples/coding-assistant

Research agent

Track whether a claim is observed, reported, inferred, or hypothesized, plus the source chain.

examples/research_agent

Structured query for memory health

Memnode is not only semantic recall. You can also inspect memory structurally now, using the same predicate-tree shape over HTTP and MCP. This is the practical path toward `SQL for memory`: exact filters when you need cleanup, audit, or operator control.

POST /v1/query
{
  "label": "Observation",
  "filter": {
    "$and": [
      {"_epistemic_type": {"$eq": "summary"}},
      {"_support_count": {"$gte": 3}}
    ]
  },
  "limit": 20
}

Find low-evidence claims

Surface semantic memories that are being reused even though the support is still weak.

curl -sS https://api.memnode.dev/v1/query \
  -H "Authorization: Bearer $MEMNODE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Observation",
    "filter": {
      "$and": [
        {"_epistemic_type": {"$eq": "summary"}},
        {"_support_count": {"$lt": 2}},
        {"_recall_count": {"$gte": 3}}
      ]
    },
    "limit": 10
  }'

Find stale or junk memory

Pull back memories that look weak on salience and have not been reinforced recently.

query_memory({
  label: "Observation",
  filter: {
    "$and": [
      {"_salience_long_term": {"$lt": 0.15}},
      {"_salience_recent": {"$lt": 0.15}},
      {"_memory_status": {"$in": ["provisional", "quarantined"]}}
    ]
  },
  limit: 20
})

Find high-recall, low-trust memories

Catch memories that are showing up a lot but still have weak support or ambiguous status.

query_memory({
  label: "Observation",
  filter: {
    "$and": [
      {"_recall_count": {"$gte": 5}},
      {"$or": [
        {"_support_count": {"$lt": 2}},
        {"_memory_status": {"$in": ["provisional", "disputed", "quarantined"]}}
      ]}
    ]
  },
  limit: 20
})

The point of these queries is not analytics for its own sake. They give the operator a way to spot weak memories before the agent keeps repeating them.

Reserved query fields

These are the current built-in fields that matter most for memory inspection. They are the practical control surface for finding weak memory, stale memory, and over-relied-on claims.

_epistemic_type

How the memory should be interpreted: observed, reported, inferred, hypothesized, summary, or procedural.

Use this when you want observed-only or summary-only inspection.

_memory_status

Lifecycle or trust state for semantic memories, such as provisional, supported, canonical, disputed, deprecated, or quarantined.

Useful for cleanup, review queues, and trust-sensitive recall.

_support_count

How many supporting episodes or observations currently reinforce the memory.

Low values are the fastest way to spot weak semantic claims.

_recall_count

How often the memory has been surfaced by recall.

Combine this with low support to find risky memories that keep getting reused.

_last_recalled_at

Unix timestamp of the last time this memory was reinforced by recall.

Use this to find stale memory that has not been touched recently.

_salience_long_term

Longer-horizon salience signal that survives beyond one recent burst of usage.

Best for ranking likely durable memory.

_salience_recent

Shorter-horizon salience signal that reacts quickly to recent reuse.

Best for finding recently active or recently cooled-off memory.

_created_at

Not currently exposed as a first-class query field on the hosted memory nodes.

If you need a time anchor today, use fields like `_last_recalled_at` or the memory’s own domain time fields such as `_valid_from`.

What makes Memnode different

Typed provenance instead of one undifferentiated memory bucket.
Hosted tenants and local MCP are both part of the product story.
Dashboard-issued tokens map cleanly onto `memory.read`, `memory.write`, and `memory.admin` scopes.
The hot path stays in the Rust data plane; Supabase remains the source of truth, not the read path.

Framework compatibility →Compare products →