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 freeWhy build it yourself
On a small project, Jira or Linear is a second place to keep up to date. You find a bug while Claude Code is in the middle of something else. By the time you've opened a browser tab, written the ticket and pasted the stack trace, you've lost the thread.
Claude Code is in the repo and has read the stack trace. Ask it to file the bug in one sentence, with the file and the line, and to close it with the commit that fixed it. Every later session can ask what's open before it starts.
Connect Claude Code to databasedmcp
databasedmcp is a remote MCP server that gives AI assistants private SQLite databases, with nothing to install.
claude mcp add --transport http databased https://databasedmcp.com/mcp
Then run /mcp in Claude Code, pick databased and choose Authenticate. Your browser opens a databasedmcp page: sign in and select Allow.
Any other MCP client works the same way; the docs have the details.
Copy this prompt to build it
Paste this into Claude Code to set up the database, its tables and its guide in one go. The rest of this article walks through what it makes and how you use it.
Set up a bug tracker for this repo in databasedmcp, in one go. 1. Create a database called bugs, described as "Bug tracker for this repo: bugs filed from the terminal, closed with the fixing commit". 2. Create two tables: - bugs: id, title (required), severity (1 for broken for everyone to 4 for cosmetic, defaults to 3), status (open, doing, fixed or wontfix, defaults to open), path (the file where the bug lives), repro (how to reproduce it), fixed_in (the commit that fixed it), opened_at (defaults to now), closed_at (NULL until it's closed). - comments: id, bug_id (references bugs), body (required: what was tried, what was found), at (defaults to now). 3. Write the database a guide that says what each table is for, that comments are appended and never edited, to file a bug with a reproduction whenever I say something is broken and close it with the short commit hash, and the query for "what's open, worst first" to run before starting work. From then on: when I say something is broken, file a bug with the file and a reproduction. When you start on one, set it to doing and add what you find as comments. When you commit a fix, set it to fixed, with the short commit hash in fixed_in and closed_at set. Show me the tables when you're finished.
Ask for the database
You don't write the schema. Describe what you want:
Create a bug tracker for this repo in databasedmcp: bugs with severity, status, the file they're in and how to reproduce them, plus a comment log. When I say something's broken, file it; when you fix one, close it with the commit.
Claude Code creates a database called bugs and its tables:
CREATE TABLE bugs (
id INTEGER PRIMARY KEY,
title TEXT NOT NULL,
severity INTEGER NOT NULL DEFAULT 3 CHECK (severity BETWEEN 1 AND 4),
status TEXT NOT NULL DEFAULT 'open' CHECK (status IN ('open', 'doing', 'fixed', 'wontfix')),
path TEXT,
repro TEXT,
fixed_in TEXT,
opened_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP,
closed_at TEXT
);
CREATE TABLE comments (
id INTEGER PRIMARY KEY,
bug_id INTEGER NOT NULL REFERENCES bugs(id),
body TEXT NOT NULL,
at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);
It also writes the database a guide on how the tables are meant to be used. The guide comes back with the schema whenever an assistant looks the database up. Claude Code files things the same way next week as today, and so does any other assistant you connect.
# bugs: this repo's bug tracker
- **bugs**: one per bug. severity: 1 (broken for everyone) to 4 (cosmetic). status: open, doing, fixed, wontfix. `path` is the file where it lives, `fixed_in` the commit that fixed it.
- **comments**: what was tried, what was found. Append; never edit.
Before starting work, check what's open: `SELECT id, severity, title, path FROM bugs WHERE status IN ('open', 'doing') ORDER BY severity, id`
File a bug with a reproduction whenever the human says something is broken. Close it with the short commit hash.
Use it
From here on you talk, and Claude Code writes the rows. Each request below is one statement:
The CSV export breaks on names with commas. File it, it's not urgent.
INSERT INTO bugs (title, severity, path, repro) VALUES (?, ?, ?, ?) RETURNING id -- params: ["CSV export breaks on names with commas",3,"src/export/csv.ts","Export a customer named \"Smith, Jane\": the row gets an extra column."]
Look into bug 1.
UPDATE bugs SET status = 'doing' WHERE id = ? AND status = 'open' -- params: [1]
Note what you found.
INSERT INTO comments (bug_id, body) VALUES (?, ?) -- params: [1,"Fields are joined with commas without quoting. Use the csv-stringify helper the import side already uses."]
Commit that and close the bug.
UPDATE bugs SET status = 'fixed', fixed_in = ?, closed_at = datetime('now') WHERE id = ?
-- params: ["a41c9e2",1]
Ask it questions
Once there's data, each report you'd pay for is a single query:
What's open, worst first?
SELECT id, severity, title, path FROM bugs WHERE status IN ('open', 'doing') ORDER BY severity, id
Which files keep breaking?
SELECT path, count(*) AS bugs FROM bugs WHERE path IS NOT NULL GROUP BY path ORDER BY bugs DESC LIMIT 10
How long do bugs stay open, by severity?
SELECT severity, count(*) AS fixed, round(avg(julianday(closed_at) - julianday(opened_at)), 1) AS days_open FROM bugs WHERE status = 'fixed' GROUP BY severity ORDER BY severity
You can also open the database on the website, page through its rows and run read-only SQL yourself.
What you give up
Nobody outside the terminal sees it as a board. Anyone on your account can browse the rows on the website, but you get no drag-and-drop, customer-facing portal or notifications. If designers, support or customers file bugs, they need Linear or GitHub Issues.
There are no integrations. Commits don't close bugs by themselves, and nothing pages you. The fix is a sentence in CLAUDE.md asking Claude Code to check open bugs at the start of each session and close them when it commits a fix.
Try it
databasedmcp is free to start, with no card. Free has 100 tool calls a week, enough to set this up and try it for a week. Starter has 1,000 for everyday use.