Coding agents
Antigravity
Give Antigravity memory that survives the session. Add the Korely MCP server to your MCP config with your API key in a header.
Connect Korely's MCP server and Antigravity 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). Antigravity only calls the tools.
Prerequisites
- A Korely API key (
kor_live_...) without theadminpermission. Make it on the dashboard's API keys page, which ticksmemories:readandmemories:writeand leavesadminoff. A key from agent signup hasadminuntil you connect it to a dashboard login, and with it a tool can manage the account's projects and close the account; connecting takesadminaway, and the key keeps working. The hobby plan is free; Pricing lists its limits. - Antigravity installed, with MCP support (Manage MCP Servers in the IDE).
- For the fallback bridge only: Node.js with
npxon yourPATH, the bridge runs as a Node process.
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
an Authorization: Bearer header. Register it in the global
config at ~/.gemini/config/mcp_config.json (or
.agents/mcp_config.json in the workspace). In the IDE you can
open the live file via
Manage MCP Servers → View raw config. These paths and the
serverUrl and headers fields are the ones in
Antigravity's MCP docs.
{ "mcpServers": { "korely": { "serverUrl": "https://api.korely.ai/agent/mcp", "headers": { "Authorization": "Bearer kor_live_..." } } }}
Replace kor_live_... with your real key. Restart Antigravity
(or reload MCP servers) and korely should show as connected.
Fallback, the mcp-remote bridge
If your build does not send the header to a remote server (one report, on version 1.0.0, is
antigravity-cli #25),
register Korely as a local command server that runs
mcp-remote instead:
{ "mcpServers": { "korely": { "command": "npx", "args": [ "-y", "mcp-remote", "https://api.korely.ai/agent/mcp", "--header", "Authorization:${KORELY_AUTH}" ], "env": { "KORELY_AUTH": "Bearer kor_live_..." } } }} mcp-remote speaks stdio to Antigravity and forwards each call to
https://api.korely.ai/agent/mcp over Streamable HTTP, injecting
the Authorization header.
About the bridge. mcp-remote is a
third-party, open-source npm proxy
(punkpeye/mcp-remote,
MIT licence), not published or maintained by Korely or Google. It needs
Node.js on your machine and runs locally as a command
server. Your key reaches it through the KORELY_AUTH
environment variable, and it forwards the key to Korely in the header.
If a server doesn't load
-
Use the IDE's View raw config to open whichever file is
actually live, and check that
korelyis in it. -
With the bridge, confirm
npxresolves in the environment Antigravity launches from, the bridge is a Node process.
Korely MCP also supports OAuth, so Antigravity can sign you in instead of using a key. The Antigravity documentation describes OAuth for remote MCP servers. Korely has not tested OAuth with Antigravity. See Connect with OAuth.
What Antigravity can do
The Korely server offers six memory tools:
| Tool | What it does |
|---|---|
korely_get_context | The 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_add | Store 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_search | Search by meaning over the stored memories, best match first. |
korely_get_facts | The 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_fact | Fix 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_memory | Forget 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 Antigravity 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 laterYou › How do we deploy this? → korely_get_context("deploy") → "This repo deploys to Hetzner..."Antigravity › 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. 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
- Korely MCP, the full MCP surface and other clients.
- Get context, the call behind
korely_get_context. - Memory as a tool, the same pattern when you build the agent loop yourself.