How to set up an MCP memory server for ChatGPT, Claude & Cursor

What an MCP memory server is, the two ways to connect one (OAuth or manual config), high-level setup steps for ChatGPT, Claude, and Cursor, and the mistakes that quietly break it.

An MCP memory server is a process that stores your context — decisions, preferences, project facts — and exposes it through the Model Context Protocol so any compliant AI client can read and write to it. To set one up, you connect it to each tool once, either through a single OAuth flow or by adding a config entry with an endpoint and credentials. After that, ChatGPT, Claude, and Cursor can all reach the same memory.

This guide covers what the server actually is, the two connection patterns, the high-level steps per tool, and the pitfalls that make memory look connected when it is not.

What is an MCP memory server, exactly?

It is an MCP server whose job is persistence. Where a typical MCP server might expose tools to query a database or edit files, a memory server exposes tools to store and retrieve context. The model itself stays stateless — MCP is just the wiring that lets it reach a system that remembers. If the protocol itself is new to you, What is MCP (Model Context Protocol)? is the prerequisite read.

A memory server generally offers a small set of capabilities:

• Write — save a memory: a decision, a constraint, a preference, a fact about the current project.
• Search — retrieve the memories most relevant to the current conversation, usually via semantic search rather than keyword match.
• List or read — pull back stored records so you can inspect or correct them.

The point of doing this through MCP rather than a tool-specific plugin is reach: one server, many clients. The same memory is addressable from ChatGPT, Claude, Cursor, Perplexity, and Gemini without a separate integration each.

OAuth vs manual config: which connection pattern?

There are two ways an AI client connects to a remote MCP server, and the difference matters more than it first appears.

• OAuth connection — you click connect, authorise in a browser, and the client and server exchange tokens automatically. No secrets are copied by hand. Token refresh is handled for you. This is the lowest-friction and lowest-error path.
• Manual config — you edit a JSON config file (or a settings panel) and supply the server URL plus an API token yourself. More control, but every field is a chance to paste the wrong value or leak a token into a dotfile that ends up in version control.

A minimal manual config entry for a remote server tends to look like this:

{
  "mcpServers": {
    "memory": {
      "url": "https://your-memory-server.example.com/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

Both patterns end at the same place — the client can call the server's tools. OAuth just removes the parts where humans make mistakes.

How do you connect an MCP memory server to Claude?

Claude supports remote MCP servers through its connectors interface. At a high level:

1. Open settings and find the connectors or MCP section.
2. Add the server. If it supports OAuth, you authorise in a browser tab and return connected. If not, paste the server URL and token.
3. Confirm the server's tools appear as available, then test by asking Claude to save and recall a memory.

The verification step is not optional. A server can be listed and still fail silently on its first real call.

How do you connect an MCP memory server to ChatGPT and Cursor?

The shape is the same; the surface differs. In ChatGPT, remote MCP servers are added through its connector settings — the OAuth path is a browser authorisation, the manual path is a URL and key. In Cursor, MCP servers are configured in the MCP settings, often via the same JSON structure shown above. Cursor is editor-centric, so the value of shared memory is highest when the decisions you made in chat are visible while you code — see Keep context between Claude and Cursor for why that handoff is the part that usually breaks.

Whichever tool you start with, the goal is one logical memory store reachable from all of them — not three separate stores that happen to be named the same thing.

What are the common pitfalls?

• Per-tool silos. Connecting a different memory server to each tool gives you the illusion of memory with none of the portability. The store must be shared, not just the pattern.
• Expired tokens. Manual configs with long-lived bearer tokens fail quietly when the token rotates. OAuth refresh avoids this entirely.
• No write discipline. A connected server that nothing ever writes to stays empty. Memory needs a habit, not just a connection.
• Unbounded capture. Saving every message produces noise that degrades retrieval. Curated decisions and constraints beat raw transcripts.
• No way to inspect or delete. If you cannot read back what is stored, you cannot correct a wrong memory — and a wrong memory is worse than none.

How does Vilix do the one-OAuth version?

Vilix is a persistent memory layer delivered as a single MCP connection. Instead of standing up and maintaining your own server and a token per tool, you connect once via OAuth — no tokens or config files for most tools — and that same memory is reachable from ChatGPT, Claude, Cursor, and Perplexity. It captures full conversation context with semantic, source-aware retrieval, and you can export or delete everything at any time. It is not the only way to get an MCP memory server; it is the version where the setup is one click instead of one integration per tool.

If you would rather skip the server-maintenance work entirely, you can try Vilix free for 7 days.

Frequently asked questions

Do I have to build my own MCP memory server?

No. You can run an open-source or self-hosted server if you want full control, or use a hosted memory layer that exposes itself as an MCP server so you only connect, not operate.

Does one MCP memory server really work across ChatGPT, Claude, and Cursor?

Yes, that is the design intent of MCP. Because the protocol is provider-neutral, a single server can serve every MCP-capable client. The catch is that you must connect the same store to each, not configure a separate one per tool.

Is OAuth or manual config more secure?

OAuth is generally safer in practice because no long-lived secret is copied by hand or stored in a plaintext config, and token refresh is automatic. Manual config gives more control but more ways to leak a credential.

Why isn't my MCP memory server remembering anything?

The usual cause is that nothing is writing to it. A connection only enables memory; something — you, a prompt convention, or the tool — still has to save context for retrieval to have anything to return.

Can I delete what an MCP memory server has stored?

You should be able to. Inspect-and-delete is a baseline requirement for trustworthy memory. If a memory system does not let you read back and remove records, treat that as a reason not to rely on it.