Last Updated: 8/20/2026

Use Your Memory from Any AI Agent (MCP)

Overview

Jolli Memory captures the reasoning behind your commits. This page connects that memory to your AI agent through the Model Context Protocol (MCP), so the agent can read your history from inside the chat. No terminal, no copy-paste. Ask “what did we decide about auth?” or “recall this branch,” and the agent answers from your real stored Memories instead of guessing.

Prerequisites

• Install your agent first, then run jolli enable in the repository - enable registers the MCP server with whichever agents it finds.
• Restart the agent afterwards. A session that was already running will not see the new server.
• At least one commit with a Memory, so there is something to ask about.
• For the hosted endpoint: a sk-jol- API key or a browser sign-in. An org admin can turn the MCP surface off entirely.

What you get

Enabling Jolli exposes a set of tools to your AI agent. Most are read-only; a couple write on your behalf (push_memory and bind_space publish to and bind a Jolli Space, covered below). Four read tools cover the everyday “remember what we did” job:

• search - Ask “have we handled rate limiting before?” and the agent searches every branch’s Memories for the answer.
• recall - Ask it to recall a branch and it loads that branch’s full context: decisions, plans, notes, and commits.
• get_decision_timeline - Ask how a decision evolved and it traces that topic across commits, oldest first.
• list_branches - Ask which branches have Memories and it lists them with their topics.

You ask in plain language. The agent picks the tool and answers in the chat.

Also available: get_pr_description and queue_status power the pull-request workflow (see Create PR in Getting Started with Jolli Memory); bind_space, list_spaces, and push_memory back Share in Jolli (see Jolli Spaces); and status reports the health of your Jolli setup for this repo - which hooks are installed, your hook runtime, account and API-key configuration, detected AI integrations, and your stored-Memory count. You never call these by name; your agent reaches for them when the task calls for it.

When you are signed in, the server may also register additional Jolli-hosted tools defined by the backend, so your agent can see more than the built-ins listed above. Set mcpPlatformToolsEnabled to false for a built-ins-only server.

Automatic setup

Jolli’s MCP server is CLI-hosted: a local stdio process - jolli mcp - that each host spawns on your own machine and talks to over standard input and output, registered under the server key jollimemory. It reads the Memories stored with your repo, on your machine.

That is the right server for an agent that runs on your own machine. For an agent that cannot spawn a local process, Jolli also serves a hosted endpoint over the web - see Connect a hosted agent below.

There is no separate MCP install. When you enable Jolli in a repo, the jollimemory server is registered for you into every supported AI host that Jolli detects on your machine:

Claude Code and Cursor are configured per repo. The other nine share one machine-wide config.

Three of these are easy to mistake for something else. Antigravity reads ~/.gemini/config/mcp_config.json, which is a different file from the Gemini CLI’s ~/.gemini/settings.json even though both sit under ~/.gemini/; the per-variant mcp_config.json files point back to that one. For Cline it is the VS Code extension that is wired up, once per VS Code flavor you have installed - the Cline CLI keeps no MCP config of its own, so there is nothing to register for it. And Kimi Code keeps its MCP servers in mcp.json, not in the config.toml next to it, so a server added to the TOML file will not be found.

A host is wired up only if Jolli detects it when you run jolli enable, and registration does not repeat on its own afterwards. So install the agent first, then run jolli enable. If you add one later, run jolli enable again to register it.

Every Jolli surface registers the server:

• CLI - jolli enable from the repo root.
• VS Code extension (including forks such as Cursor and Windsurf) - Enable Jolli Memory in the Status panel.
• JetBrains plugin - Enable in the tool window. It needs Node.js on your PATH for the MCP server and for both skills; the plugin sets them up by running its bundled CLI. Without Node, those are skipped cleanly and the tool window shows “MCP & Skills: Node.js not found.” Both /jolli-recall and /jolli-search are unavailable until Node is installed, and the tool window says so. Memory generation keeps working through the plugin’s native Java hooks.
• Claude Code, Cursor and Codex plugins - each registers Memory’s MCP tools itself. On Cursor the server is written once you opt the repository in, and it registers disconnected, so enable jollimemory in Customize. See Jolli Memory in Your AI Agent.

Any other MCP host

Only those eleven hosts are auto-registered, but the jollimemory server is a standard stdio MCP server, so any MCP-capable host can use it. If yours isn’t on the list, wire it up by hand.

With the CLI installed, register a stdio server with command jolli and args ["mcp"], under whatever key that host uses for its stdio servers. That’s the same jolli mcp process the supported hosts spawn.

With nothing installed, point the host at npx -y @jolli.ai/cli mcp instead. That gives your agent read access to the Memories you already have, with no global install and nothing written to your repositories. Recording new Memories still needs Jolli enabled in the repo, because capture runs off git hooks.

Connect a hosted agent

Everything above spawns jolli mcp locally. An agent that runs somewhere else - a hosted agent, an automation platform, anything that cannot start a process on your machine - connects to Jolli over the web instead.

Point it at https://jolli.ai/mcp, as a Streamable HTTP MCP server. There are two ways to prove who you are.

Sign in from the agent

If your agent supports connectors that sign in for themselves, this is the better option. Add it as a connector and the agent sends you to Jolli in your browser, where you approve the connection and it returns with access.

• You choose which organization it reaches. The approval screen asks, and it checks your answer against the organizations you currently belong to. This is the practical difference from a key: if you belong to more than one organization, approving is where you say which one, rather than finding out afterwards.
• Approving also finishes setting up your account in that organization if you were invited and have not opened it yet. Without that step an agent would connect successfully and then find nothing, which looks the same as an empty workspace.
• Nothing is shared until you approve, and you can approve again later for a different organization.

If your agent connects but every request comes back refused, it most likely asked for no permissions when it sent you to approve. Jolli tells it which permission to ask for, and a connector that follows the standard will send you through approval once more and then work. Approving again is the fix.

An API key

For anything that cannot open a browser, authenticate with a Jolli API key as a bearer token:

POST https://jolli.ai/mcp
Authorization: Bearer sk-jol-...

• The key decides which workspace you reach, so there is nothing else to configure and no workspace name anywhere in the URL.
• Create the key under Settings → Jolli Memory. It needs the MCP scope, which every API key carries while MCP is enabled for the organization.

An organization admin can turn the whole MCP surface off, which makes this endpoint unavailable along with the rest, whichever way you connect.

What a hosted agent can read

Over this endpoint an agent can read your organization’s memory as well as your documentation:

Both are scoped to what the key’s creator is allowed to view; a search that reaches further silently drops what they cannot see. Personal Spaces and deleted Articles are never returned.

Writing a memory from a conversation

This is the one tool on this surface that writes. A few things govern where it lands and whether it is allowed:

• Where it goes. Pass a space id to choose the target, or leave it out and it writes to your organization’s default memory space. If your organization has no default and you name none, the call fails and creates nothing. It never creates a space for you: make one in the web app, and that choice becomes the default for later writes.
• Memory spaces only. Documentation spaces and personal spaces are refused. The refusal reads the same whatever the reason, so the tool cannot be used to work out which spaces exist.
• What actually gates it is the per-space contribution permission of the person who created the API key. If they cannot contribute to the target space, neither can the agent.
• Repeating a create updates rather than duplicates, so an agent that retries does not leave two copies behind.
• Memories written this way are grouped separately from the ones your repositories push, and kept per author, so two people capturing the same title do not collide.

The documentation tools are unchanged and still leave memory and personal Spaces out, so pointing an agent at documentation does not quietly hand it your team’s memory, and the reverse holds too. For the documentation tools and the older REST endpoints, see Settings.

The rest of the endpoint

Memory and documentation are the tools most people come here for, but they are not the whole surface. A connected agent also gets repository reads and Workflow control. Worth reading before you authorize an agent, since browser approval hands it everything below at once.

Reading a connected repository. Available to any authorized agent, scoped to what the key’s creator can reach.

Workflows. These need Workflows to be enabled for your organization.

Running a Workflow on your own machine. Four tools drive a local run end to end, which is how the CLI recipes work: start_local_run takes the Workflow id and hands back the plan and the branch to write into, report_local_run_progress keeps the run alive while the work happens, and complete_local_run or abandon_local_run closes it out - the first with the pull request number, the second releasing the lock so the Workflow can run again.

The two run-control tools and the four local-run tools act, they don’t just read. Everything else on this page reads. Permission is checked when the call is made, against what the person behind the credential is allowed to do, so an agent can never run a Workflow its key’s creator couldn’t run by hand.

Turn it on and verify

1. Enable Jolli in your repo (see above) and make sure the repo has at least one commit with a Memory.
2. Restart your AI agent. This is the step people miss. An agent reads its MCP config at startup, so a session that was already running will not see the new server until you restart or reload it. In VS Code (or a fork such as Cursor or Windsurf), reload the window; in a JetBrains IDE, restart it; for a CLI agent, quit and reopen.
3. Ask the agent to use it:

• “Recall this branch.”
• “What did we decide about the caching layer?”
• “Have we dealt with duplicate webhook deliveries before?”

If it answers with specifics grounded in your commits, you are set.

On Claude Code the tools appear namespaced as mcp__jollimemory__search, mcp__jollimemory__recall, and so on. Other hosts list them under a jollimemory server. You rarely need the exact names; plain language is enough.

Skills vs tools

Alongside the MCP tools, jolli enable installs guided skills. On Claude Code they are slash commands; on other hosts they are Agent Skills. They call the MCP tools for you (and fall back to the CLI when a host has no MCP support), so they are the easy front door:

• /jolli:recall - deep on one branch. Loads that branch’s full Memory and synthesizes an answer. Use it to resume or understand a specific branch.
• /jolli:search - broad and shallow across every branch. Returns relevance-ranked hits. Use it to find where something was decided.

Those are the names in Claude Code, where the plugin owns the /jolli:* namespace. The Cursor plugin uses /jolli-recall and the Codex plugin uses $jolli:recall - see Jolli Memory in Your AI Agent. Where the CLI installs the skills itself instead (Gemini CLI, GitHub Copilot, OpenCode, and Codex or Cursor without the plugin) they are unnamespaced, as /jolli-recall and /jolli-search.

jolli enable installs three more alongside them, into the same place:

• /jolli on its own opens a menu of the Jolli actions available in that session and runs the one you pick. Claude Code has its own version of this menu; every other host gets it from the CLI.
• /jolli-local-run and /jolli-remote-run run a Jolli Workflow from your agent, on your machine or on Jolli’s backend. See Reference for what they need.

All five are written to one shared location, so any agent that reads Agent Skills from your project picks them up. There is no per-host skill setting.

Rule of thumb: search to find the branch, recall to go deep on it.

Troubleshooting

The tools do not show up.

• Restart the agent. Its MCP config is read at startup (see above).
• Check that your agent is one of the eleven supported hosts listed under Automatic setup. If it was not installed when you ran enable, install it, then run jolli enable again. Registration only happens during an explicit jolli enable, so a host added afterwards stays unregistered until you re-run it.
• IntelliJ only: confirm Node.js is on your PATH, then reopen the project to retry. The tool window’s “MCP & Skills” row reports the current state.

Some tools are there and others are missing. The tools that answer for a repository are hidden when the server was started outside a project, which some editors do. Rather than answering with an empty result that reads as “there are no memories here”, they do not appear at all. Listing your Jolli Spaces and your workspace’s own platform tools do not depend on a repository, so they still work. Reopen the agent on the project folder to get the rest back.

Several open sessions. Sessions working in the same checkout share one Jolli MCP server rather than each starting its own, so opening more of them costs less than it used to. Nothing about how your agent talks to Jolli changes. If you need each session to run its own server, set JOLLI_MCP_NO_DAEMON=1 in the environment your agent starts in.

Search results look stale or empty. The search index is a disposable local cache, separate from your stored Memories. Rebuild it:

jolli mcp --reindex

It reindexes from your stored Memories and prints how many documents it loaded.

For anything else, run jolli doctor and see the troubleshooting section in Reference.

Next steps

• Getting Started with Jolli Memory - install, enable, and your first Memory.
• Reference - the MCP tool list, config keys, and CLI commands.
• Recall vs Search - what recall and search do, and when to reach for each.