MCP Memory Server Setup for Any Client in Three Steps
MCP memory server setup takes three moves in any client: create a project key, point the client at https://memory-mcp.audaxic.com/mcp with a Bearer header, and verify the tools list. No local install, no Docker — the same shared memory then works across every client you connect.
On this page
One remote MCP memory URL for every client
Every MCP-compatible chat starts with an empty context window. Your client may see open files, recent edits, or indexed symbols, but it does not remember what the last session decided: which package manager you use, which migration was rejected, which command runs integration tests, which header staging requires. Close the chat and that working state is gone.
The remote MCP server keeps those facts outside the conversation. You store conventions once and each session pulls them back with semantic search — the same gap behind coding agents forgetting conventions.
The server lives at one URL:
https://memory-mcp.audaxic.com/mcp
It speaks Streamable HTTP and authenticates with a project key. The key is an ak_... string you create in the dashboard, sent as a Bearer token in the Authorization header. The MCP overview explains the protocol side if you have not wired an MCP server before.
There is no local process to run and nothing to install. The remote endpoint behaves the same on macOS, Windows, and Linux, with no per-machine upgrades or file syncing.
Scoping is strict. Data is isolated per organization with namespace-scoped vector search, so each project key reads and writes only its own namespace. A fact stored for your web app does not surface in your platform repo. Servers are located in the US and EU, we never train on customer data, and graph memory is included on all plans from Hobby through Enterprise.
MCP memory server setup in three steps
This mcp memory server setup follows the same three moves in every client: create a project key, add the server URL with a Bearer header, and confirm the tools list is live.
The pattern holds whether you use Cursor, Claude Desktop, Windsurf, OpenCode, or another MCP-compatible client. Claude Code, Codex, and OpenCode also offer plugins that save and inject memories automatically, but any client without a plugin uses this exact MCP path. For Cursor specifically, see Cursor MCP memory setup, which walks through the same server from the Cursor side.
Step 1: Create a project key
Open the dashboard, create a project for the repository you want to remember, then create an API key for that project. The dashboard flow is Projects, then View on your project, then Create API Key. Copy the ak_... value immediately because it is shown once.
Use one project per repository. That recommendation keeps retrieval precise: the agent searches only the namespace for the repo it is working in, instead of sorting through facts from five other codebases. If two repos genuinely share conventions, you can point both clients at the same key on purpose, but make that a deliberate choice.
If you work on a team, create the project under the shared workspace so teammates reuse the same namespace. Each teammate still pastes the key into their own client config.
Keep the key separate from code. It is a credential for the data plane at https://api.memory.audaxic.com, and anyone with the key can read and write that project's memories. Store it in your client's settings file or a secret manager, never in a public repo or a screenshot.
Step 2: Add the server URL and Bearer header
Open your client's MCP settings and add a new server entry with the URL and an Authorization header. The field names vary by client — some call it URL, some call it server URL or endpoint — but the values are identical everywhere:
{
"mcpServers": {
"audaxic-memory": {
"url": "https://memory-mcp.audaxic.com/mcp",
"headers": {
"Authorization": "Bearer ak_your_api_key_here"
}
}
}
}
Replace ak_your_api_key_here with the key from Step 1, keeping the Bearer prefix and the single space after it. A missing prefix is the most common failure: the server expects the full header value, not the raw key alone. The MCP setup guide shows where this entry goes in each supported client.
Save the file and restart or reload the client if it caches MCP connections. A healthy server appears as connected with a tool list attached. If it shows as disconnected, check three things in order: the URL has /mcp at the end with no trailing slash issues, the header name is exactly Authorization, and the key belongs to the project you intended.
Do not add extra transport settings. If your client offers a choice between stdio and HTTP, choose HTTP or Streamable HTTP and paste the URL above.
Verify MCP memory tools are live
A green connected indicator only proves the transport opened. Confirm the agent can actually store and retrieve a fact, because that exercises auth, namespace routing, and tool wiring in one pass. This verification is the final move of the mcp memory server setup and it uses the same tools in every client.
Once connected, the client should list five memory tools:
| Tool | What it does |
|---|---|
add_memory |
Stores one fact, with optional metadata |
search_memories |
Semantic search across stored memories |
get_memories |
Lists memories for the project |
delete_memory |
Deletes a specific memory by ID |
delete_all_memories |
Deletes every memory in the project |
Parameter shapes and response formats are documented in the tools reference. You never call these by hand in normal use; the agent calls them when you ask it to remember or recall something.
Run this three-prompt check in a fresh chat:
- Say: "Remember that the release branch is
release/2026.09." - In the same chat, ask: "What is the release branch?"
- Open a second, brand-new chat with no prior context and ask: "What is the release branch?"
The third prompt is the real test. Same-chat recall can be satisfied from the conversation itself, but a fresh chat has nothing to draw on, so a correct answer there proves the fact came back from the memory server. If the first answer works and the third does not, the store succeeded and retrieval or key scoping is the problem — check that both chats use the same project key.
For a stronger check, ask the agent to list memories with get_memories and confirm your test fact appears. Then delete the test with delete_memory so it does not pollute the namespace. There is no update tool in the MCP surface, so correct a wrong fact by deleting it and storing the replacement, or call the REST update endpoint from a script.
Client config variants and where they differ
The URL and header never change, but every client puts them in a slightly different place. Find your client below, then return to the three steps above for the values.
Cursor reads MCP servers from .cursor/mcp.json in the project or from its global MCP settings. Use the project file when you want the entry checked in for a private team repo, and the global file when you want the same memory in every repo on your machine. Cursor connects via MCP only — there is no Cursor plugin — so this entry is the entire Cursor integration.
Claude Desktop and Windsurf each have their own MCP settings screens, but both accept a remote HTTP endpoint with custom headers. Paste the same URL and the same Authorization header, then look for the tool list to confirm. The walkthrough in Claude Desktop and Windsurf memory setup shows both variants with no local server involved.
OpenCode and other MCP-compatible clients follow the same pattern: add a remote server, set the Bearer header, reload. If your client uses a different config key than mcpServers — some use servers or a UI form with URL and headers fields — map the values across without changing them. The wire format is what matters, not the JSON key your client chose for its config file.
Claude Code, Codex, and OpenCode also offer plugins (npx @audaxic/memory-claude install, npx @audaxic/memory-codex install, npm install -g @audaxic/memory-opencode) that save and inject memories automatically. Use the plugin for automatic behavior and MCP for explicit tool calls; both read the same shared memory when they share a project key.
Good practices: one key per project, keep it secret
Treat each project key like a database credential for one repo. One key per project keeps search results relevant, keeps deletes safe, and makes rotation straightforward: if a key leaks, you rotate one project's key without touching the others. The habit to build is simple — new repo, new project, new key.
Keep the key out of version control in public repos. If you commit .cursor/mcp.json or a similar file for team convenience, commit a placeholder such as Bearer ak_REPLACE_ME and let each developer substitute their own copy locally. For private team repos, committing the real key is a judgment call, but prefer your client's global settings or environment-variable substitution when the client supports it.
Save one fact per memory: preferences ("always use pnpm for this repo"), decisions with reasons ("chose Postgres over SQLite for concurrent writes"), and gotchas ("staging requires the X-Env header"). Skip temporary debug state, secrets, or anything false by tomorrow — short, specific statements match best in semantic search.
Understand counting before you let the agent save freely. An add request is counted per memory extracted from a message batch, so one call that extracts five facts counts as five adds. Retrieve requests use tiered counting: the first ten memories retrieved count as one request, and each additional ten counts as one more, so a search returning 25 memories counts as three requests.
Know the plan you are on. Hobby is $0 per month with 10,000 adds, 1,000 retrieves, and unlimited projects, with no credit card required. Paid tiers start at $12 per month for 50,000 adds and 5,000 retrieves, and every plan includes graph memory. Pricing is flat monthly with no per-token fees and no overages, so a busy week changes quota usage, not the bill.
Two limits complete the picture. Management create operations are limited to 100 per hour per IP, with RateLimit-Limit and related headers on responses. On the data plane, 100 failed authentication attempts per four hours per IP returns 429 with Retry-After, which is a guard against credential guessing rather than a cap on normal use. The REST API also takes a date-based X-Api-Version header, currently 2026-09-25, worth pinning if scripts call the API directly.
FAQ
What does MCP memory server setup require for any client?
Create a project key in the dashboard, then add https://memory-mcp.audaxic.com/mcp to your client with an Authorization header of Bearer ak_.... The server speaks Streamable HTTP and the same values work in every MCP-compatible client.
Is there a Cursor plugin, or is MCP the only path?
No. Cursor connects through the remote MCP server only, with the same URL and Bearer project key as every other client. There is no plugin to install for Cursor.
How do I verify the memory tools are live?
Check that the client lists five tools: add_memory, search_memories, get_memories, delete_memory, and delete_all_memories. Then store a test fact and ask for it back in a brand-new chat, which proves retrieval works outside the current conversation.
What does persistent MCP memory cost?
Hobby is $0 per month with 10,000 adds, 1,000 retrieves, and unlimited projects, with no credit card required. Paid tiers start at $12 per month for 50,000 adds and 5,000 retrieves, and graph memory is included on every plan.
Written by Efe — Oct 09, 2026 · More articles · X @AudaxicTech