MCP + Eigenmesh: giving every AI tool a shared memory

Every AI tool you use keeps its own copy of you. ChatGPT remembers one version. Claude remembers another. Cursor knows what's in your repo but nothing about the meeting you had this morning. Your notes app has the meeting notes but no idea what code you've been writing. The actual context that makes you useful is split across a dozen silos, and you re-explain yourself to each of them.

The Model Context Protocol (MCP) is the standard that's trying to fix this — a common way for AI clients to call external tools over HTTP. Eigen Mesh exposes your memory through MCP so any compliant client can read and write the same second brain. This post walks through what that actually looks like.

What MCP is, in one paragraph

MCP is an open protocol for AI assistants to call external services. A client (Cursor, Claude Desktop, anything that speaks the protocol) connects to a server, discovers the tools it exposes, and calls them as part of a normal model loop. The model decides when to call, the server executes, the client feeds the result back. It's function calling, but the functions live on a server you control instead of being baked into the client.

Eigen Mesh is an MCP server. Your memory is the resource. The tools are memory operations.

The endpoint

https://<your-app-origin>/api/mcp

One URL. Same for managed and self-hosted — the only difference is the origin. The transport is Streamable HTTP per the MCP spec, so any client that supports the modern transport can connect directly. Clients that only speak stdio need a local bridge; the client setup docs cover that.

Authentication is a Bearer API key:

Authorization: Bearer <your-api-key>

You create keys in the product UI at /api-keys. The server resolves the key to your user_id before any tool runs, and all queries are scoped by Row Level Security. You never see another user's thoughts; another user never sees yours. The key is the boundary.

The four tools

The HTTP MCP surface is intentionally small. Four tools, no more.

That's the whole v1 contract. Full argument and response shapes are in the MCP tools reference; this post is the conceptual tour.

capture_thought

Stores a raw thought. Tier 1 returns immediately after the text persists; tier 2 enrichment (classify, embed, graph sync) runs in the background. You don't wait on embeddings to get an acknowledgment. The as_user flag lets an agent record something on behalf of the human — useful when the user says "remember this" in chat and you want it stored as their memory, not yours.

retrieve_thoughts

The read side. Two modes:

• Search — pass a query, get hybrid results: vector ANN over pgvector, lexical FTS over lexical_text, and precomputed graph neighbors from Apache AGE, fused and reranked by an LLM listwise pass.
• Browse — omit the query (or set order=created_at), get newest open thoughts first. This replaces the old list_thoughts tool. Paginate with cursor_created_at + cursor_id.

Results contain text, category, score, and metadata. They do not contain embedding vectors — that's a hard boundary, documented at /developers/embeddings-boundary.

edit_thought and delete_thought

Edit takes a thought_id and either a natural-language edit_request (the LLM rewrites the text) or a direct raw_text replacement (skip the LLM). Both paths re-embed, re-sync the graph node, and log activity. Delete is a soft archive — reversible, same family as "archive" / "not relevant" edits. Nothing is hard-deleted through MCP.

The pattern MCP doesn't give you

There is no answer_question tool. This is deliberate.

A common first instinct is "I want to ask my memory a question and get an answer back." MCP doesn't model that well — the protocol is about exposing tools, not about composing responses. So Eigen Mesh doesn't fake it. Instead, the pattern is two steps in the client:

1. Call retrieve_thoughts with the question as query.
2. Compose the answer in your client using the returned thought texts and citations.

The in-app Chat UI (/chat) does this internally via its agent tool loop. HTTP MCP clients do the same in their own code. The advantage: you control the prompt, the citations, the model. The disadvantage: you write a few lines of orchestration. Most MCP clients already have that orchestration built in.

What this looks like in practice

You're in Cursor, about to start a feature you discussed in a meeting last week. You type "what did we decide about the billing refactor?" Cursor's model calls retrieve_thoughts with that query. Eigen Mesh runs hybrid retrieval, reranks, returns the three relevant thoughts with scores. Cursor's model reads them, writes an answer citing the memories, and you start coding with the actual decision in front of you — not the version you half-remember.

Later, you tell Cursor "remember: we went with the wallet-based approach, not the per-token one." Cursor calls capture_thought with as_user: true. The thought lands in your memory, classified and linked overnight. Next week, in Claude Desktop, you ask a related question — and the same memory surfaces, because it's the same database behind both clients.

That's the point. One memory, many clients, no re-explaining.

Security boundaries worth knowing

• Tenant isolation. RLS on all user data. The API key resolves to a user_id before any query runs. Cross-user access is not possible through MCP.
• Embeddings stay in the DB. Tool results are text and scores. Vectors are never returned. See /developers/embeddings-boundary.
• Notes tools are not on HTTP MCP. The in-app chat agent has a richer Notes surface (create_text_file, search_text_files, etc.). Those are deliberately not exposed over HTTP MCP. If you want notes-style operations from an external client, build them on the REST API.

Connecting a client

The short version: create an API key at /api-keys, point your MCP client at https://<your-app-origin>/api/mcp, set the Bearer header. The client discovers the four tools and starts calling them.

Step-by-step for Cursor and Claude Desktop is at /developers/cursor-and-claude. The full tool contract is at /developers/mcp-tools. The conceptual overview is at /developers/mcp-overview.

Why this matters

MCP is the first credible path to "my memory follows me between tools." Not because it's exotic — it's a standard HTTP tools surface — but because it's the first time the major AI clients are converging on the same wire format. Eigen Mesh's job is to be the boring, reliable memory server on the other end of that connection.

If you want to try it, start on managed with 100 free credits, create an API key, and point your MCP client at it. You'll have a shared second brain across every tool you use in about ten minutes.