Get Started

Vibecoding

Give your coding assistant a memory that survives the session.

You build by prompting — Claude Code, Cursor, Windsurf. The problem is amnesia: every new session your assistant forgets the architecture you settled on, the library you rejected, the convention you agreed. korely-mcp fixes that. It exposes your Korely agent store as MCP tools, so the assistant can recall what it learned and remember new decisions — and what it stores are typed, bi-temporal facts with a graph behind them, not a flat transcript it has to re-read.

Set it up

1. Get a key

One command mints a free hobby key and saves it locally — no signup form:

pip install 'korely-memory[mcp]'
korely init --agent --agent-caller claude-code

The [mcp] extra adds the korely-mcp server; korely init writes the key to ~/.korely/config.json. See Sign up as an agent for the full flow.

2. Add the MCP server to your assistant

Point any MCP-capable client at korely-mcp. The key is read from ~/.korely/config.json (from step 1) or the KORELY_API_KEY env var:

claude mcp add korely -- korely-mcp

Restart the assistant and the four Korely tools appear. That's the whole setup — no rules engine, no separate dashboard.

3. The tools your assistant now has

Tool	What it does
`korely_get_context`	The recall call. Assembles the user's currently-valid typed facts plus the most relevant memories into a prompt-ready block. Call it before answering.
`korely_add`	Remember a decision, preference, or convention — Korely extracts the typed facts. Call it after something durable is settled.
`korely_get_facts`	Read the typed `(subject, predicate, object)` facts. Pass `as_of` for a point-in-time view (what was decided back then).
`korely_search`	Semantic vector search over the raw memories, when you want the source rather than the assembled block.

A starter prompt

Drop this into your assistant's system prompt or rules file so it uses the memory on its own:

You have persistent memory through the Korely MCP tools. Use it instead of asking
the user to repeat themselves:

- Before answering anything about this project, the user's preferences, or past
  decisions, call korely_get_context with a short query to recall what is known.
- After the user settles a durable decision, preference, convention, or fact,
  call korely_add with one clear sentence so it persists across sessions.
- Use korely_get_facts to check the current typed facts (and as_of for a
  point-in-time view); use korely_search to pull up the underlying memories.

Memory persists across sessions and is shared with any other Korely surface
(SDK, CLI, REST). Treat it as the source of truth for what was decided.

What it looks like in practice

You tell the assistant "we're standardizing on Postgres and shipping on Fridays". It calls korely_add; Korely extracts you — uses — Postgres and you — ships_on — Fridays. Next week, in a fresh session, you ask it to scaffold a deploy script — it calls korely_get_context("deploy cadence and stack") first and already knows. If you later switch to a Tuesday cadence, the old fact is invalidated (not deleted) and as_of can still reconstruct what the plan was. That is the difference between a memory layer and a chat log.

Go deeper

Build it into your own agent: the Quickstart and the SDK reference — the same memory, called from code.
Understand the moat: temporal facts and the graph — why recall returns current truth, not the nearest paragraph.
Use the CLI directly: the CLI reference — the same tools as korely context, korely add, for scripts and hooks.