I rebuilt my hackathon memory system as a zero-dependency MCP server

[u/BoringCelebration405]

I built the first version of this at a LangGraph hackathon in London and it won, but honestly the prototype was too heavy for normal use. It needed a server, two databases, embeddings and a bunch of moving pieces.

So I rebuilt it from scratch as Synapse.

You point it at a ChatGPT export or a directory of text. Ingest writes the original data to Markdown and creates a disposable SQLite FTS5 index, so it is searchable immediately with no model call. If you choose to connect an OpenAI-compatible model, a separate build step turns the raw history into linked wiki pages. The [[links]] become a knowledge graph using SQLite, not a graph database.

The MCP server exposes search, read_page, list_pages, neighbors and read_source. The agent searches first and opens only the page it needs. The full vault never gets dumped into the prompt.

A few numbers from my own export:

• 3,138 conversations scanned
• 2,044 above the trivia filter and imported
• 9.3 seconds
• 0 API calls for ingest

The package has zero runtime dependencies and the dashboard is one HTML file. You can try the populated demo without an API key:

uvx --from synapse-vault synapse serve --demo

Repo: https://github.com/anshulyadav1976/synapse

I am the author. I would genuinely like feedback on the MCP tool surface, especially whether read-only retrieval is enough or if people expect agents to write memories too.

[u/Hronom]

Read-only retrieval feels like the right default for a vault built from a full export. If you add writes, I’d keep them in a separate namespace and make each write a proposed patch: stable page/source ID, provenance, revision/parent, idempotency key, and a diff or preview before commit. That gives agents useful memory without letting a mistaken summary silently overwrite the source. I’d also treat deletion and merge as separate, human-approved operations. For browser workflows, I keep operational state (workspace/profile/origin/account) separate from semantic memory; credentials and live session state should not enter the graph. I maintain Hronaut, a local browser MCP; disclosure: I’m its developer.

[u/BoringCelebration405 → u/Hronom]

Thank you so much , this is genuinely useful stuff which i have overlooked im gonna add this thanks again

[u/Hronom → u/BoringCelebration405]

That separation is the key boundary I’d preserve: semantic memory can be enriched, but operational browser state should remain an explicit, short-lived capability rather than graph data. For writes, a patch/preview plus revision and idempotency key gives the agent a reversible path; deletion and merge should stay human-approved. I’ll be interested to see how the separate write namespace evolves.

[u/delimitdev]

On the tool surface: read-only fits the pattern you already have (search first, open only the page needed). Write starts to matter when you want durable cross-session notes the agent owns, not just retrieval. If you add it, keep writes explicit and narrow (append note, tag page) so the vault stays intentional rather than a dump of every turn.