You already let Cursor sweep a folder in Agent mode and read the diffs on the way out. Your Notion database is the folder it cannot open. So the cleanup you keep deferring, normalize the tags, tighten the summaries, fix the rich-text after that long edit cycle, would run live, where every view and linked database reacts the instant a row changes.
Scratch pulls the database down, one file per row. Cursor edits the properties on your laptop; Scratch holds each change as a diff; nothing writes back until you approve it. Page bodies and computed properties stay read-only, so the structure the rest of your workspace leans on does not move.
How it works
- Scratch pulls your database into files. A Notion database becomes a folder on your laptop, one file per row, every property laid out to edit.
- Cursor edits the rows. Open the folder in Cursor. Cmd+K a few rows to settle the prompt, then turn on Agent mode for the table. Normalize the tags on every row and tighten each summary to one line. Cursor works the files, never the live database.
- You review every diff and publish. Scratch shows each changed property beside the original, word by word. Approve what holds up, and Scratch writes only those rows back through the Notion API.
What people use it for
The database tidying that stalls because Notion makes you open each row:
- Normalize tags and categories across every row.
- Bring each summary or description down to one line.
- Standardize a rich-text column after a long, messy edit cycle.
- Clean up the database behind a Notion site so the site reads clean.
- Fill empty select or status cells by reading each row.
Cmd+K a handful of rows to feel the loop, then let Agent mode take the database.
Why not an MCP server?
A Notion MCP server or integration wires Cursor straight to your live workspace. One Agent-mode pass rewrites every row at once, and whatever those databases feed updates instantly.
Scratch gives Cursor the same full read and write access against a local copy instead. The write-back is lifted out and handed to you. Cursor can change anything; only you can commit it. On a database your team works in every day, that gap is the whole point.
What Cursor edits in Notion
- Database properties: titles, rich-text, select, multi-select, and dates
- Relation, people, and files properties
- Cover and icon metadata
Page bodies stay read-only. The connector edits the database side, not the block trees, toggles, or embeds inside a page, and computed properties (formula, rollup, created and edited metadata) stay locked. The full picture lives on Scratch for Notion.
Questions people ask
Is this an MCP server or a Notion integration?
Neither. An MCP or an integration hands Cursor the write button. Scratch keeps it. Cursor gets the same access, and writing back is a separate step you approve, one row at a time.
Will it touch my page content?
No. Cursor edits database properties only. Page bodies, block trees, toggles, and embeds are never exposed, and computed properties like formulas and rollups stay locked.
Can I roll a change back after it writes?
Yes. Scratch keeps the original beside the rewrite, so every written row reverts per row. You decide which version stays.
How is this different from a CSV import or a script?
A CSV import and a script both write straight to the live database with no diff and no per-row approval, and a find-and-replace does only what you spelled out. Cursor handles the rows a rule cannot, and Scratch still holds every change for review before it writes.
Can it handle a whole database?
Yes, that is the use case. Cmd+K a handful of rows to feel the flow, then let Agent mode take the whole database.
Do I need to be technical?
If you run Cursor already, you are set. If you would rather not work in an editor, the Claude desktop app runs the same Scratch loop with a more familiar surface.
See it on your own database
The fastest way to trust it is to watch it run on your data. See it run on your Notion database →, or download Scratch free and take the first pass yourself.