NotionCodeMirror

This is a submission for the Notion MCP Challenge

What I Built

NotionCodeMirror — a CLI that auto-generates a living code documentation workspace in Notion from any GitHub repo, and keeps it in sync as the code evolves.

Point it at a repo, and within minutes you get a fully structured Notion workspace:

• An Overview with language breakdown and symbol inventory


• An Architecture page written in real prose by Claude


• A searchable API Reference database populated with every function and class


• A module page for each top-level directory

Run it again after a PR merges, and only the changed pages update.

The core idea is multi-MCP orchestration.

Phase 1 uses jcodemunch-mcp to analyze the codebase:

• Extracts symbols


• Ranks them by import-graph centrality


• Traces dependency edges


• Builds class hierarchies
  All of this happens without involving Claude.

Phase 2 hands Claude a compact structured digest (about 8–12K tokens) instead of raw source files, so it can focus entirely on synthesis and writing.

The API Reference database is batch-populated directly via HTTP, bypassing the agent loop for large inserts (100+ rows at a time).

A full run on a medium-sized repo costs roughly 10–15K Claude tokens — closer to a single conversation than a traditional indexing job.

Video Demo

https://www.youtube.com/watch?v=C99oAE69Og0

Show us the code

https://github.com/jgravelle/notion-code-mirror

How I Used Notion MCP

Notion MCP is the write layer of the pipeline.

After Claude analyzes the gathered repo data, it calls four lightweight Python tools: notion_create_page, notion_create_database, notion_update_page, and done. Each of those dispatches to the Notion MCP server via an async stdio session — the same MCP transport pattern used on the code-analysis side with jcodemunch-mcp. Both MCP servers stay open concurrently for the duration of the run.

Each of those dispatches to the Notion API under the hood. The MCP connection is managed as an async stdio session alongside the jcodemunch-mcp session, so both servers stay open for the duration of the run.

The API Reference rows are the one exception: Claude creates the database shell and signals completion via done, then Python batch-inserts every symbol row through the same Notion MCP session — keeping Claude out of a loop that would otherwise cost 100+ tool-call round-trips.

What Notion MCP specifically unlocks is direct writing into a structured workspace instead of dumping out a Markdown file you then have to paste somewhere. Claude doesn’t just generate text. It decides the page hierarchy, picks emoji icons, chooses what belongs in a database versus a prose page, and places everything under the right parent. That produces a workspace that is immediately navigable and shareable rather than a lonely text artifact drifting around your desktop.

The incremental sync story also depends on MCP making page IDs first-class. On the first run, every created page and database ID is saved to a local state file. On --sync, those IDs go back into Claude’s context, and it calls notion_update_page on the existing objects instead of duplicating them.

Without MCP as the integration layer, you’d need a custom Notion client plus a fair amount of bookkeeping to get the same result...

-jgravelle