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
...and the results:
https://www.notion.so/jcodemunch-mcp-CodeMirror-32b752802a7f812da7bee46c5460beb1
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
Top comments (1)
A viewer notes synching isn't continuous. Toward further token frugality, this is by design. The command can be embedded with the --sync argument easily enough in one's push workflow.
Also asserted, our workflow summarizes the repo through caps and truncation. Claude offers its own comprehensive defense below:
===
The critique undersells what's actually happening under the hood, and isn't accurate for the API Reference.
The 100-result cap on search_symbols is bypassed entirely when token_budget is set. The tool ranks all symbols in the repo by BM25 + import-graph centrality, then greedily packs results until the budget is exhausted. Phase 1 uses token_budget=20_000. At standard detail level (~150–300 bytes per symbol), that's potentially 500+ symbols inserted into the API Reference database, not a capped 100. For a repo where the full symbol set fits inside that budget, coverage is complete. The database isn't a sample; it's everything the budget can hold, sorted by relevance.
The dependency graph and class hierarchy tools have no hard size ceiling.
get_dependency_graph performs a real BFS over the import graph: all reachable nodes and edges within depth 1–3, with no truncation. get_class_hierarchy traverses all ancestors and descendants with no depth limit whatsoever. External bases not found in the index are explicitly noted as (external) rather than silently dropped. These aren't summaries of the structure; they're the full structure.
Where the critique does land.
The Architecture prose is written from a deliberately bounded prompt slice: top 20 symbols, 3 dependency summaries, 2000 chars of context bundle. That's a real design trade-off. Claude is writing an overview narrative, not an exhaustive audit. For a 1000-file monorepo, that prose will reflect the most central parts of the codebase, not every corner. That's the honest limitation, and it's a synthesis limitation, not a data limitation.
Separately, jcodemunch-mcp exposes capabilities this project doesn't yet fully exploit: get_file_outline supports batching across any number of files in a single call and returns the complete hierarchical symbol tree for each; get_context_bundle accepts a list of symbol IDs with no hard payload cap and returns full source and imports for all of them; find_references, find_importers, and get_blast_radius enable cross-file call graph and impact analysis that goes well beyond what any static README approach can offer. The tool's ceiling is considerably higher than what Phase 1 currently reaches for.
The bottom line.
"It summarizes through caps and truncation" is an accurate description of the Architecture page. It is not an accurate description of the API Reference, which is populated comprehensively within a generous token budget. The distinction matters: the workspace intentionally provides one page of curated prose and one database of structured, filterable, near-complete symbol coverage. Conflating the two undersells what the database actually contains...