Korely
v1.0.23
Your Dashboard
Agent Plugins / Cursor

Coding agents

Cursor

Give Cursor memory that survives the session. Add the Korely MCP server to one JSON file: no package to install, just your API key in a header.

Connect Korely's MCP server and Cursor can ask Korely for the current facts and the relevant memories before it answers, and save new ones as you work. Korely does the heavy part on its own servers: it reads each memory, writes the facts, closes an older fact when a newer one contradicts it, and keeps both dates of a fact (bi-temporal). Cursor only calls the tools.

Prerequisites

  • A Korely API key (kor_live_...) without the admin permission. Make it on the dashboard's API keys page, which ticks memories:read and memories:write and leaves admin off. A key from agent signup has admin until you connect it to a dashboard login, and with it a tool can manage the account's projects and close the account; connecting takes admin away, and the key keeps working. The hobby plan is free; Pricing lists its limits.
  • Cursor installed, with MCP support.

Add the Korely MCP server

Korely's agent memory is a remote MCP server at https://api.korely.ai/agent/mcp, authenticated with your key in a header, no browser login. Cursor reads MCP servers from a JSON file. Open ~/.cursor/mcp.json and add: 

{
  "mcpServers": {
    "korely": {
      "url": "https://api.korely.ai/agent/mcp",
      "headers": {
        "Authorization": "Bearer kor_live_..."
      }
    }
  }
}

Replace kor_live_... with your real key. As in the remote example in Cursor's MCP docs, the entry has only url and headers, with no type field. To scope the server to a single project instead of every project, put the same JSON in .cursor/mcp.json in the project root.

Cursor resolves ${env:VAR} inside the url and headers fields, so for a more secure setup keep the key out of the file and read it from the environment: 

{
  "mcpServers": {
    "korely": {
      "url": "https://api.korely.ai/agent/mcp",
      "headers": {
        "Authorization": "Bearer ${env:KORELY_API_KEY}"
      }
    }
  }
}

Then export KORELY_API_KEY in the shell that launches Cursor. Either way, manage the server from the Customize page in Cursor; if it does not connect, open the Output panel and pick MCP Logs.

Save every session without asking. In the repository, run korely init --tool cursor (korely-memory 0.1.26 or later): hooks hand Cursor the repository's memory when a session starts and save the session to it as a memory of kind session. Each prompt and each final answer is saved, at most 3,000 characters per message. Before anything leaves your machine, the hook masks private key blocks, credentials in URLs and long random-looking strings. It masks by shape, so a hexadecimal token or a short password typed in a sentence stays as plain text: keep secrets out of what you type. It also writes a local korely MCP server to .cursor/mcp.json in the repository (~/.cursor/mcp.json with --global), replacing a korely entry already there; with --no-mcp it removes that entry and adds none. Without --global, a server you configured in ~/.cursor/mcp.json is kept. The local server has four of the six tools below (no korely_correct_fact or korely_forget_memory). See Connect a coding assistant.

Korely MCP also supports OAuth, so Cursor can sign you in instead of using a key. The Cursor documentation describes OAuth for remote MCP servers. Korely has not tested OAuth with Cursor. See Connect with OAuth.

What Cursor can do

The Korely server offers six memory tools:

ToolWhat it does
korely_get_contextThe recall call: returns the current facts plus the most relevant memories as one block of text, ready to put in a prompt (the context block). It does not call a language model.
korely_addStore a memory. Korely writes facts from it on its servers, each as (subject, predicate, object), and closes an earlier fact, with its end date, when a model decides a new one replaces it.
korely_searchSearch by meaning over the stored memories, best match first.
korely_get_factsThe facts known about an end user, with point-in-time queries: as_of (what was true then) and known_as_of (what the store knew then).
korely_correct_factFix or end one fact by its id. Give a new subject, predicate or object and the old fact is closed and a corrected one is written, both kept in history. With close=true the fact is only closed, which is how you forget a fact. Needs a key with the memories:write permission.
korely_forget_memoryForget one memory by its id. It drops out of every read and the facts only it stated are closed; with erase=true it is removed for good. Needs memories:write.

Use it

Korely MCP sends its client short instructions: call korely_get_context before answering, and korely_add once a decision or preference is settled. If Cursor follows them, a session looks like this (an example, not a recording): 

You › Remember that this repo deploys to Hetzner, not Render.
      → korely_add("This repo deploys to Hetzner, not Render")


# next session, days later
You › How do we deploy this?
      → korely_get_context("deploy") → "This repo deploys to Hetzner..."
Cursor › This repo deploys to Hetzner (you told me earlier), not Render. ...

Scoping

The four tools korely_get_context, korely_add, korely_search and korely_get_facts accept an optional user_id so one key can serve many end users: a read that names "user-b" never returns a memory written for "user-a". On a write, pass a user_id or an agent_id. With neither, the remote server stores the memory in the project's shared memory, with no end user, under the name your client gave when it connected (a key confined to one end user writes to that one); details. The local server that korely init --tool installs follows the REST rule: it writes under the repository (repo:<name>) and, outside a git repository, has no id to give, so a write that names none is refused with 422 identity_required until you pass an id or save one with korely init --user-id <id> (korely-memory 0.1.29). Omit it on a read and the read covers every end user the key can see. korely_add and the three read tools also accept an optional agent_id. korely_correct_fact and korely_forget_memory take the id of a fact or a memory instead, and treat an id from another project (or, for a confined key, from another end user) as not found. The Korely MCP page lists every argument.

Why this is more than a notepad. Korely keeps each memory's text as written and also extracts typed facts with bi-temporal validity from it. When something changes ("this repo now deploys to Hetzner, not Render"), Korely closes the old fact with its end date instead of overwriting it, so korely_get_context returns what's true now, and as_of can still replay what was true before. The Cloud runs on servers in Helsinki; Data and governance says where text is processed.

Related