databasedmcp

← Articles

How to build a read-later list with Grok

Hand Grok a link and a line about why you saved it. When you have twenty minutes, ask it for something worth reading.

6 min read

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 free

Why build it yourself

A read-later app is mostly a list of links with a reason attached. Raindrop.io and Instapaper do it well, with apps, highlights and clean reading views. But if you mostly save things and rarely find them again, the list is what matters.

Saving a link to Grok takes one sentence, and you can note why while you still remember. Later, ask for what you saved about pricing last month, or something short you haven't read. The answer comes from your own list, not a search.

Connect Grok to databasedmcp

databasedmcp is a remote MCP server that gives AI assistants private SQLite databases, with nothing to install.

Open grok.com/connectors, add a new connector, choose Custom and enter https://databasedmcp.com/mcp. When Grok opens the databasedmcp page, sign in and select Allow. Then turn the connector on in a chat.

Any other MCP client works the same way; the docs have the details.

Copy this prompt to build it

Paste this into Grok 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.

prompt
Set up a read-later list for me in databasedmcp, in one go.

1. Create a database called reading, described as "Read-later list: links, why I saved them, tags, and what I thought after reading".
2. Create two tables:
   - links: id, url (required, unique), title (required), site, why (my reason for saving it, in my words), minutes (rough reading time, if I give one), status (unread, read or dropped, defaults to unread), verdict (what I thought once I've read it), added_at (defaults to now), read_at (NULL until I've read it).
   - tags: link_id (references links), tag (lowercase, reused), with one row per link and tag.
3. Write the database a guide that says what each table is for, to check a URL isn't already saved before adding it, and to check the existing tags before inventing a new one. Include the queries for "something to read now": up to five unread links that fit in the minutes I have, oldest first, and "by tag": the links with a given tag, newest first.

From then on: when I give you a link, save it with the title, the site and my reason, and tag it. When I say I've read something, set it to read with read_at and my verdict. When I say I'm not going to read it, set it to dropped. Show me the tables when you're finished.

Ask for the database

You don't write the schema. Describe what you want:

Make me a read-later list in databasedmcp: links with a title, the site, my note on why I saved it, roughly how long it is, and tags. Track whether I've read it, and what I thought afterwards.

Grok creates a database called reading and its tables:

schema
CREATE TABLE links (
  id INTEGER PRIMARY KEY,
  url TEXT NOT NULL UNIQUE,
  title TEXT NOT NULL,
  site TEXT,
  why TEXT,
  minutes INTEGER,
  status TEXT NOT NULL DEFAULT 'unread' CHECK (status IN ('unread', 'read', 'dropped')),
  verdict TEXT,
  added_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP,
  read_at TEXT
);

CREATE TABLE tags (
  link_id INTEGER NOT NULL REFERENCES links(id),
  tag TEXT NOT NULL,
  PRIMARY KEY (link_id, tag)
);

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. Grok files things the same way next week as today, and so does any other assistant you connect.

guide
# reading: links to read later

- **links**: one per URL. `why` is my reason for saving it, in my words. `minutes` is a rough reading time if I gave one. status: unread, read, dropped. `verdict` is what I thought once read.
- **tags**: one row per link and tag, lowercase, reused (pricing, sqlite, design). Check existing tags before inventing one.

Check the URL isn't already saved before adding it.

Something to read now: `SELECT id, title, minutes, why FROM links WHERE status = 'unread' AND minutes <= ? ORDER BY added_at LIMIT 5`

By tag: `SELECT l.id, l.title, l.status FROM links l JOIN tags t ON t.link_id = l.id WHERE t.tag = ? ORDER BY l.added_at DESC`

Use it

From here on you talk, and Grok writes the rows. Each request below is one statement:

Save https://www.sqlite.org/whentouse.html for later. It's the SQLite page on when to use it; I want it for the architecture doc. About 15 minutes.
execute
INSERT INTO links (url, title, site, why, minutes) VALUES (?, ?, ?, ?, ?) RETURNING id
-- params: ["https://www.sqlite.org/whentouse.html","Appropriate uses for SQLite","sqlite.org","For the architecture doc: when SQLite is enough.",15]
Tag it sqlite and architecture.
execute
INSERT INTO tags (link_id, tag) SELECT ?, value FROM json_each(?)
-- params: [1,"[\"sqlite\",\"architecture\"]"]

json_each turns a list into rows, so any number of tags is still one statement.

Also save https://www.w3.org/WAI/fundamentals/accessibility-intro/, the W3C intro to accessibility. Short, maybe 10 minutes. Tag it design.
execute
INSERT INTO links (url, title, site, why, minutes) VALUES (?, ?, ?, ?, ?) RETURNING id
-- params: ["https://www.w3.org/WAI/fundamentals/accessibility-intro/","Introduction to web accessibility","w3.org","Before the signup form redesign.",10]
Read the SQLite one. Good: the part on server-side use answered my question.
execute
UPDATE links SET status = 'read', read_at = datetime('now'), verdict = ? WHERE id = ?
-- params: ["Good. The section on server-side use settles the question for the architecture doc.",1]

Ask it questions

Once there's data, each report you'd pay for is a single query:

I've got 10 minutes. What should I read?
query
SELECT id, title, minutes, why FROM links WHERE status = 'unread' AND minutes <= ? ORDER BY added_at LIMIT 5
-- params: [10]
What have I saved about sqlite, and did I read it?
query
SELECT l.id, l.title, l.status, l.verdict FROM links l JOIN tags t ON t.link_id = l.id WHERE t.tag = ? ORDER BY l.added_at DESC
-- params: ["sqlite"]
How much do I save versus read, month by month?
query
SELECT strftime('%Y-%m', added_at) AS month, count(*) AS saved, sum(status = 'read') AS read, sum(status = 'unread') AS still_unread FROM links GROUP BY month ORDER BY month DESC

You can also open the database on the website, page through its rows and run read-only SQL yourself.

What you give up

It stores the link, not the page. Raindrop.io and Instapaper can keep a copy, give you a clean reading view, let you highlight and work offline. Here you read the article on its own site, and if the page goes away, you have the title and your note but not the text.

You get no browser extension, share sheet or app. Saving means telling Grok, and nothing arrives from other apps by itself. A read-later app is faster if you save dozens of links a day from your phone. For a few links you want to remember the reasons for, this is enough.

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.

Create an account

More articles · databasedmcp · Docs