Literature Review Tools

Literature Review Tools — Select & Run

A curated, use-case-organized catalog of the strongest open-source AI tools for literature review — plus a launcher that actually installs and runs the top ones. Covers: end-to-end research agents, deep-research / auto-survey generators, autonomous "idea→paper" systems, citation-backed RAG over PDFs, PRISMA screening, MCP servers, Zotero/Obsidian integrations, PDF→structured extraction, citation graphs, and paper-writing / peer-review assistants.

Full source of truth (README, always current star counts): https://github.com/brycewang-stanford/lit-review-agent-tools

Three modes

• Look up — user wants the literature itself: "find papers on X", "get me the PDF for this DOI", "does this citation exist", "what does PubMed have since 2022". Answer it directly — no install, no key. Start with reference/apis/README.md for one-off lookups, or run the bundled papers-fetch / oa-resolve scripts for anything corpus-sized.
• Recommend — user asks "what should I use to …". Route with the tables below; cite the catalog for details.
• Run — user asks to install / run / use a specific tool ("turn this PDF into Markdown with MinerU", "ask PaperQA2 about these papers", "set up the arXiv MCP server"). Drive scripts/litrun.py via Bash — do not hand the user raw pip commands to copy.

Mode 1 is the cheap default. Do not send someone to install PyTorch when they asked for five papers and a PDF.

Look up mode — search without installing anything

Two bundled scripts, both standard-library only: no venv, no pip, no API key. Run them straight (python3 scripts/fetch_papers.py …) or through the launcher.

# 1. search six indexes at once, deduplicated by DOI
python3 scripts/fetch_papers.py --query "active learning for screening" \
    --sources openalex,crossref,semanticscholar,pubmed,europepmc,arxiv \
    --max 15 --dedup-titles --outdir ./corpus

# 2. turn those DOIs into full text you may legally read
python3 scripts/resolve_oa.py --from-json ./corpus/results.json --outdir ./corpus

fetch_papers.py writes results.json (normalised records, per-source counts, and the errors of any source that failed) plus one .txt per paper. resolve_oa.py walks Unpaywall → OpenAlex → Europe PMC → arXiv → CORE and writes oa_report.json recording how every DOI resolved — including the ones that stayed closed, and separating those from DOIs Crossref has never registered (usually an invented citation). On a 47-paper corpus with zero keys it recovered 33 full texts; nothing in it bypasses a paywall, and you should not offer to.

For a single lookup — one DOI, one author, one citation check — skip the scripts and call the API directly (WebFetch/curl). reference/apis/ has a routing table, the identifier formats, and one page per API with the endpoints and the failure modes that waste time (Crossref's select 400, OpenAlex's inverted abstracts, Semantic Scholar's exhausted keyless pool, PubMed's multi-part AbstractText).

Report which indexes you queried and which came back empty. "OpenAlex had no match" is a fact; "that paper doesn't exist" is a much bigger claim than one API can support.

Run mode — how to drive scripts/litrun.py

The launcher installs each supported tool into its own venv under ~/.lit-review-tools/ (uses uv if present, else python -m venv) and reads API keys from one shared ~/.lit-review-tools/.env. Machine-readable recipes: recipes/recipes.json.

Typical flow when the user wants to use a tool:

1. python3 scripts/litrun.py doctor — check toolchain + which API keys are already set.
2. python3 scripts/litrun.py info <id> — confirm what the tool needs (entry, required env).
3. If a required key is missing, ask the user for it, then litrun.py env --set KEY=VALUE (never echo the value back in full).
4. python3 scripts/litrun.py run <id> -- <tool args> — installs on first use, then runs. For PDF tools pass the real file path; e.g. run mineru -- -p paper.pdf -o ./out -b pipeline.
5. For MCP servers, don't "run" them — litrun.py mcp <id> prints the client config block to register in Claude Code / Cursor.

Commands: list [--category C] [--kind K] · info <id> · doctor · env [--set K=V] · install <id> · run <id> -- <args> · mcp <id> [--storage PATH] [--client claude|cursor] · ui <id>.

Runnable ids by kind:

• python-cli (auto install+run): mineru, marker, docling (PDF→Markdown) · paper-qa (cited Q&A) · asreview (PRISMA screening UI)
• python-script, zero install (stdlib only): papers-fetch (6-source deduplicated search) · oa-resolve (DOI → open-access full text)
• python-script (bundled, auto install+run): arxiv-fetch (arXiv PDFs) · openalex-fetch (OpenAlex; PDF or abstract .txt) · pubmed-fetch (PubMed abstracts) — all keyless for light use. papers-fetch supersedes all three when you want coverage rather than one index.
• python-lib (install + run example): gpt-researcher, storm (deep research; need API keys) · scholarly, pyalex (API clients)
• mcp-server (install + mcp config): arxiv-mcp-server, paper-search-mcp, zotero-mcp

For gpt-researcher and storm, litrun.py ui <id> clones the repo and launches the full web UI (GPT Researcher → FastAPI at :8000; STORM → Streamlit at :8501). These are long-running servers — launch them with a background Bash call and tell the user the URL. gpt-researcher's UI needs OPENAI_API_KEY + TAVILY_API_KEY set first (litrun writes them into the repo's .env); STORM takes its keys in the app sidebar.

Chained pipelines

For multi-tool tasks, prefer a named workflow over hand-wiring steps: litrun.py workflow list then litrun.py workflow run <id> [--input PATH] [--query "..."] [--question "..."] [--max N]. Built-ins:

• pdf-to-markdown — a PDF/folder → clean Markdown (MinerU)
• pdf-corpus-qa — a folder of PDFs → citation-backed answer (PaperQA2)
• pdf-md-then-qa — convert to Markdown and answer a question over the corpus
• topic-to-pdfs — arXiv query → download top-N PDFs (arxiv-fetch, no key)
• topic-to-review — arXiv query → download PDFs → citation-backed answer (PaperQA2). The end-to-end "retrieve then review" pipeline; no MCP client needed. Needs OPENAI_API_KEY for the QA step.
• topic-to-review-multi — retrieve from arXiv + OpenAlex into one corpus → citation-backed answer. Broader coverage; resilient if one source is rate-limited.
• topic-to-related-work — retrieve (arXiv + OpenAlex) → PaperQA2 drafts a cited related-work paragraph synthesizing themes/methods/gaps. Needs OPENAI_API_KEY.
• topic-to-corpus — six-source search → deduplicated corpus. Keyless, no install — the default first step for any review.
• topic-to-fulltext — six-source search → open-access full text for every DOI it can legally get. Keyless.
• topic-to-fulltext-review — the strongest path: search → dedup → full text → PaperQA2 answers over full texts, not abstracts. OPENAI_API_KEY for the last step only.

Prefer the topic-to-fulltext* workflows over topic-to-review-multi: same idea, six sources instead of two, DOI-level deduplication, and it retrieves the papers rather than the abstracts. Biomedical topics need no special casing — PubMed and Europe PMC are already in the source set.

Add --dry-run first to show the exact resolved step commands without executing — good for confirming paths with the user before a heavy run. Workflows fail fast if a required API key is missing.

Guardrails: installs and downloads happen under the user's home and hit the network — for a heavy first install (marker/docling pull in PyTorch) say so before running. Never fabricate API keys. If a run fails, show the real error rather than claiming success. Paths in this file (scripts/…, recipes/…) are relative to this skill's directory.

Recommend mode — how to route

1. Identify which stage of the lit-review workflow the user is on (search → read → extract → synthesize → screen → cite-check → write/review).
2. Match it to a category below and recommend the ⭐ editor's pick first, then 1–2 alternatives.
3. For anything beyond the top pick — full star counts, every project in a category, or a category not summarized here — read reference/catalog.md. Do not guess project names or URLs; pull them from the catalog.
4. Give a one-line "why this one" tied to the user's constraint (Claude Code vs. standalone, open vs. commercial, privacy/local, medical, etc.). If the pick is a runnable id above, offer to install/run it.

⚡ 30-second picker

Just need the papers themselves (topic / DOI / OA PDF) ──▶ Look up mode — no install ⭐
Use Claude Code, want end-to-end research→paper ──────────▶ academic-research-skills ⭐
Want AI to research a topic → cited report ───────────────▶ GPT Researcher / STORM
Want fully autonomous "idea → submittable paper" ────────▶ AI-Scientist-v2 / AutoResearchClaw
Citation-backed Q&A over a pile of PDFs ──────────────────▶ PaperQA2
Rigorous PRISMA review (thousands of abstracts) ─────────▶ ASReview / prismAId
Clean Markdown from PDFs to feed an LLM ─────────────────▶ MinerU / Docling / marker
Lit capabilities inside Claude / Cursor (MCP) ───────────▶ paper-search-mcp / zotero-mcp
Chat with your library inside Zotero ────────────────────▶ zotero-gpt / PapersGPT
Pre-submission AI peer review ───────────────────────────▶ open_reviewer / ai-peer-review

Categories (top pick per category)

Decision table (map need → recommendation)

Notes & caveats

• Open-source is prioritized. Commercial/closed tools (Elicit, Consensus, Scite, SciSpace, Research Rabbit, Connected Papers) are listed for reference only — see the catalog's commercial section.
• Star counts drift. The catalog's numbers are periodic GitHub-API snapshots — treat as rough popularity signals, not exact. For live numbers, point the user at the repo.
• Match the constraint, not just the task. Privacy/local → local-deep-research; medical → medsci-skills / paperai; Codex instead of Claude → academic-research-skills-codex.

Full catalog with every project, star count, and one-line description: reference/catalog.md.