Skip to main content
Glama

MyMem

Private social memory for AI agents.mymem.space

Every AI assistant starts from zero about you. Meanwhile the platforms hold years of what you posted, saved, liked, watched and searched for — and they will hand all of it back on request. MyMem turns those exports into one searchable memory your assistant can read, so it stops guessing.

Ask it "what do I actually think about X?" and it answers from your own posts, with the dates and the links. Ask it "who am I?" and it briefs your assistant on what you keep coming back to, the positions you repeat and how you write — all counted from what you actually wrote, never inferred.

Your archive stays yours: it is read where it sits, nothing is uploaded to anyone, and private messages are only ever included if you ask for them.

This repository is the engine behind mymem.space. It is open source (MIT), and the rest of this file is for people who want to run it, read it or add a platform to it.


What works today

Status

Database + keyword search index

Working

Search by meaning (local AI model, optional)

Working

mymem import / search / embed / stats commands

Working

Instagram, X, Facebook and Google parsers

Working

LinkedIn parser

Empty stub, documented and waiting

Four sample archives (one fictional person, ~700 items)

Working

MCP server — all 12 tools, incl. whoami

Working

Local viewer app

Working (npm run viewer)

Landing page (front-end/)

Workingmymem.space, deployed (see docs/DEPLOY.md)

Related MCP server: SOMA MCP

Getting your own exports

Request these early — some platforms take 24–48 hours to prepare them. A fictional sample archive ships with this repository, so nothing is blocked while you wait.

Platform

Where

Ask for

Instagram

Accounts Centre → Your information and permissions → Download your information

JSON, all time

Facebook

The same Accounts Centre flow

JSON

X

Settings → Your account → Download an archive of your data

(one format only)

Google / YouTube

takeout.google.com → YouTube and My Activity

history format JSON

LinkedIn

Settings → Data privacy → Get a copy of your data

(CSV; parser not built yet)

The JSON choice matters: pick HTML and the parsers cannot read a thing.

Keep the ZIPs out of the repo and out of screenshots. Then:

npm run mymem -- import path/to/your-export.zip

Running the engine yourself

You do not need to — mymem.space is where MyMem lives. This is for developers who want to see it work end to end.

git clone https://github.com/nixxintools/mymem && cd mymem
npm install
npm test

You should see 84 passing tests and 1 skipped. The skip is expected: it only runs when you ask it to load the real 130MB AI model (MYMEM_TEST_EMBEDDINGS=1).

Then import the sample Instagram archive and search it:

npm run mymem -- import packages/fixtures/samples/sample-instagram.zip
npm run mymem -- search "filter coffee"
npm run mymem -- stats

Expected: 160 items imported, and searches that return dated results with the matched words in [brackets]. Full walkthrough in docs/VERIFY.md.

Two ways of searching

Typing words into a search box only finds what you literally wrote. If you posted "the queue at 7am was down the street" and later search for busy mornings, plain search finds nothing — you never used those words.

So MyMem can search two ways at once:

  • By words. Fast, exact, always on. Finds names, handles, phrases you remember verbatim.

  • By meaning. A small AI model reads each item and writes down what it is about. Searching then finds things that mean the same thing in different words.

Meaning search is off until you switch it on, because it needs a one-time 130MB model download:

npm run mymem -- embed                              # once, after importing
npm run mymem -- search "morning coffee" --semantic

Results are labelled (words), (meaning) or (words+meaning), so you can always see why something came back.

The model runs on your own CPU. Your posts are never sent anywhere — the only thing that ever crosses the network is the model file itself, downloaded once into data/models and then never again.

If any of that fails — the download, the install, the model — nothing breaks. You get a plain-English warning explaining what went wrong, and search carries on working by words alone. There is no state in which MyMem stops working because the AI part is unhappy.

Let an AI assistant read it

The MCP server hands your archive to Claude (or any MCP client) as twelve tools. Point Claude Desktop at it by adding this to its config file — on Windows, %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "mymem": {
      "command": "node",
      "args": ["C:/path/to/social-memory/apps/server/dist/index.js"],
      "env": { "MYMEM_DB": "C:/path/to/social-memory/data/memory.db" }
    }
  }
}

Restart Claude Desktop and ask it "who am I, according to my archive?" — it will call whoami. For Claude Code, run claude mcp add mymem -- node /path/to/apps/server/dist/index.js.

The server opens the archive read-only: an assistant can ask it anything and cannot change or delete a thing. It answers only from rows in your database, so nothing is sent anywhere.

The twelve tools

Tool

What it answers

whoami

"Who is this person?" — a briefing built from their own posts. The flagship

search_memory

"Have I ever mentioned X?" — everything, filterable by platform, kind, date

find_takes

"What do I think about X?" — public positions only, restatements collapsed

check_consistency

"Does this draft contradict me?" — nearest past posts to each claim

search_saved

"That thing I saved about X" — bookmarks, saves and likes only

people_lookup

"Who is Divya?" — matching accounts across platforms, with contact dates

relationship_history

"When did we last speak?" — everything exchanged with one person

top_content

"What worked?" — best performers, where the export includes numbers

on_this_day

"What was I doing this week in other years?"

timeline

"What was I doing in March 2021?"

ad_profile

"What do the platforms think I like?" — ad interests, side by side

stats

"How much is in here?" — counts per platform, kind and year

The commands

mymem import <export.zip> [--include-dms] [--db <path>]
mymem search "<query>"    [--semantic] [--platform x] [--kind post] [--limit 20]
mymem embed               [--limit n] [--batch 32] [--force]
mymem stats
mymem adapters

npm run mcp                 # start the MCP server (an AI client normally does this for you)
npm run viewer              # browse the archive in a local web page

Direct messages are skipped unless you ask for them with --include-dms. That is deliberate: your DMs are the most sensitive thing in the archive, and importing them should be a decision, not a default.

How it is put together

export ZIP ──▶ parser (one per platform) ──▶ { items, people, profile_facts } ──▶ data/memory.db
                                                                                      │
                                                          word index (FTS5) ──┬── meaning index (optional)
                                                                              │
                                                                        merged results
                                                                              │
                                                                        MCP server ──▶ your AI assistant

Every parser has exactly one job: turn a ZIP into three lists. It never touches the database, the search index, or the AI layer. That is what lets five parsers be written in parallel by five different people without colliding.

Folder

What is in it

packages/core

The database, the search index, the parser contract, the mymem command

packages/adapter-instagram etc.

One parser per platform. All stubs right now, each documenting its own traps

packages/fixtures

The fake sample archives, and the test every parser must pass

apps/server

The MCP server that exposes the archive to AI assistants

data/

Your actual archive. Git-ignored, never committed

docs/

The spec, the export-format cheat sheet, the build plan

What goes in the database

Three tables, frozen early on purpose — changing them changes what every parser has to produce.

  • items — one row per thing that happened: a post, reply, comment, DM, like, save, bookmark, video watched, search made, story, or connection. With its date (always UTC), text, media paths, permalink where one exists, and the untouched original record so nothing is ever lost in translation.

  • people — everyone who appears anywhere in the archive.

  • profile_facts — what the platforms claim to know about you: ad interests, inferred topics, account details.

Plus one optional table, item_vectors, holding what the AI model made of each item. Delete it and everything still works — that is the point of it being separate.

Privacy

  • The database, any media, and the AI model all live in data/, which is git-ignored.

  • Real export ZIPs are git-ignored too, wherever you put them.

  • Direct messages require --include-dms.

  • No telemetry, no cloud services, no API keys, no accounts.

  • The AI model runs on your machine. Your posts and messages are never sent anywhere. The single network request in the whole project is downloading that model file, once — and you can skip it entirely and still use MyMem.

  • Agents developing this project work against the fake sample archives, never against real data.

Contributing

Each parser is one package with one job: turn an export ZIP into items, people and profile_facts. It never touches the database, the search index or the AI layer, which is what lets several be written in parallel without colliding. If you want to add a platform, copy packages/adapter-linkedin (a documented stub), add a sample archive to packages/fixtures, and make the contract test pass — that test is the whole specification.

Next up

See docs/social-memory-ao-build-plan.md. The short version: the parsers for the remaining platforms, then your own exports. Search by words and by meaning both work, and the AI tool layer sits on top of them.

A
license - permissive license
-
quality - not tested
B
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to query end-to-end encrypted memories from Cognia workspace via MCP. Supports search, retrieval, and action execution against connected services like Slack, Notion, and GitHub.
    5
    8
    MIT
  • A
    license
    -
    quality
    B
    maintenance
    A private, self-hosted MCP server that wraps a retrieval pipeline over your own data, enabling trusted AI agents to access and manage your personal memory through standard MCP tools.
    Apache 2.0
  • A
    license
    -
    quality
    B
    maintenance
    Enables AI assistants to query local conversation transcripts and relationship data via a local MCP server, allowing retrieval of past conversations and facts about people.
    1
    AGPL 3.0

View all related MCP servers

Related MCP Connectors

  • User-owned memory for AI agents, Copilot, Claude, IDEs, CLIs, and chat apps over remote MCP.

  • Person-owned, portable AI memory as a remote MCP server, readable and writable by any MCP client.

  • The personal context layer for AI: your profile and files, read by any MCP client over OAuth.

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nixxintools/mymem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server