databasedmcp gives your AI assistant databases it keeps between conversations, so everything in this article works from the day you connect it. Free to start, no card.
Get started freeThe ten minutes at the start of every session
You open a new session and ask for the next thing. Claude reads the code, finds the test command, works out again that the webhook handler has to stay idempotent, and asks whether you still want the v1 API. You answered that yesterday, in a session that has since ended.
Claude Code gives you two places to keep things between sessions: CLAUDE.md, which you write and keep up to date, and memory files on your own machine. Both are text files, good for rules that rarely change. They're less good for what changes every day: which task is half done, what was decided and why, what someone found out at six in the evening. Those want rows. An agent adds one in a single call and can ask for what's still open. Every session on every machine reads the same rows.
Connect a database
databasedmcp is a remote MCP server that gives your agents private SQLite databases. There's nothing to install. In your repo, run:
claude mcp add --transport http databased https://databasedmcp.com/mcp
The first time Claude uses it, your browser opens so you can sign in. You don't copy a key.
Ask for one, from a template
You don't design a schema. Ask Claude:
Create a databasedmcp database for this repo from the project template, and keep what you learn about the repo there.
Claude calls create_database with the project template and gets two tables. tasks is a work board. memory holds everything else, and each row has a kind: decision, convention, finding, question, parked or handoff. The database also carries a guide, which get_database returns with the schema. It tells Claude how to claim a task, when to record a decision and how to hand off unfinished work.
One line in CLAUDE.md
The database outlasts the session, but the next session has to know it's there. Add a line to CLAUDE.md:
Shared memory: databasedmcp database `acme-api` (project template). Run get_database on it at the start of every session and follow its guide.
From then on, every session starts by reading the briefing: tasks in progress, open questions, the conventions in force and the latest decisions. It's one query:
SELECT * FROM briefing
Or copy this prompt to do it all at once
With databasedmcp connected, this prompt does every step above in one session. It creates the database, adds the CLAUDE.md line and files what Claude can tell about the repo.
Give this repo a memory in databasedmcp, in one go. 1. Create a database for this repo from the project template, named <owner>-<repo> from git remote get-url origin (lowercase, hyphens), so it can't collide with another repo's board. Read its guide with get_database and follow it. 2. Add one line to CLAUDE.md: "Shared memory: databasedmcp database `<name>` (project template). Run get_database on it at the start of every session and follow its guide." 3. File what you can already tell from the code as memory rows: the test and build commands as conventions, and anything that looks like a deliberate choice as a decision, with the reason if the code or docs give one. 4. Run SELECT * FROM briefing and show me what a new session will see. From now on, record decisions, conventions, findings and open questions as they come up, and write a handoff before you stop in the middle of something.
What's worth writing down
The test is whether it would make a session starting cold tomorrow act differently. A decision and the reason for it passes. So does a convention, a finding that took an hour to pin down, an open question for you, and a handoff when a session stops halfway through a task.
Progress notes, summaries of what the code does and anything git already records don't pass. The next session can read those from the repo, and a memory full of them buries the rows that matter.
Secrets never go in. The server rejects writes that contain known key formats, and the agent stores the name of the environment variable that holds the secret instead.
A week in
This is what the memory table of a small repo might look like after a week of sessions:
| id | kind | title |
|---|---|---|
| 3 | convention | Run npm test before every commit; CI runs the same command |
| 7 | decision | Keep invoices in Postgres; SQLite stays for local caches |
| 12 | finding | Stripe can send invoice.paid before checkout.session.completed |
| 15 | question | Drop the v1 API in December, or keep it until March? |
| 21 | decision | Retry webhooks from a queue, not inline (supersedes 9) |
| 24 | handoff | Webhook queue: consumer done, dead-letter handling next; see task 11 |
Rows aren't edited once written. When a decision changes, Claude writes a new row that supersedes the old one, so you can see what changed and when. Row 21 replaced an earlier decision to retry webhooks inline.
You can open the database on the website, page through its rows and run read-only SQL. If you disagree with something Claude wrote down, tell it, and it writes a replacement.
More than one session at once
The same database works when two sessions run side by side, in two terminals or on two machines. Each claims a task before starting on it, with a write that only succeeds if nobody else claimed it first, so they don't do the same work twice. They read each other's decisions as soon as they're written.
Try it on your next session
databasedmcp is free to start, with no card. Connect it, ask for a database, add the CLAUDE.md line, and see what your next session already knows.