Proposal: MCP server for AI-native local search over paperlists

[hhh2210]

Hi @jingyangcarl,

Long time no see — I'm the contributor of #7 (the Streamlit local
search tool). Two quick threads of context before the proposal:

1. Thank you again for the back-and-forth we had during my junior
   research days. That conversation shaped how I think about open
   data infra.
2. Since then I've lead ~2–3 research projects of my own, and
   this dataset has been the single most useful conference-paper
   resource I keep coming back to. The cross-venue, multi-year,
   review-score coverage is genuinely hard to find elsewhere.

Why I'm opening this issue

In the last year the "interface to data" has shifted from
human-facing UIs to AI-agent-facing tool calls. Spinning up a
localhost Streamlit each time is now strictly worse UX than letting
my coding agent (Claude Code / Cursor / Codex) query the corpus
directly. I think it's time paperlists gets a first-class
AI-native entry point — and as a bonus, this further offloads work
from papercopilot.com's web search (the same motivation behind #7).

Proposal: a small MCP server living under tools/mcp/

MCP (Model Context Protocol) is the emerging standard for exposing
local tools/data to LLM agents — supported by Claude Code, Claude
Desktop, Cursor, Codex, and others with one config line. A single
MCP server gives every AI tool the same access, without anyone
running a Streamlit instance.

Initial tool surface (built on top of the existing extract.py
logic, so no duplicated semantics):

• search_papers(query, conferences?, years?, fields?, mode, …)
• get_paper(id, conference) / top_papers(conf, year, by=…)
• filter_by_score(conf, year, min_rating_avg?, status_in?)
• conference_stats(conf, year) / affiliation_stats(...)
• cross_venue_trend(query, conferences[], year_range)
• author_papers(name, year_range?)
• list_data_coverage()

Implementation sketch:

• Python, mcp[cli] + orjson + stdlib sqlite3 — no heavy deps.
• First-run builds a sqlite FTS5 index in ~/.cache/paperlists-mcp/
  from the JSON files; mtime-based incremental refresh after that.
• Lives in tools/mcp/ with its own pyproject.toml, runnable as
  uvx paperlists-mcp. Zero changes to the top-level data layout.
• I'd also add a small tools/skill/paperlists.md so Claude Code
  users get auto-invocation; same MCP underneath.

What I'm asking

Before I open a PR, I'd love your read on:

1. Is tools/mcp/ the right location, or would you prefer a
   separate repo under the papercopilot org?
2. Any naming preference? (paperlists-mcp vs papercopilot-mcp)
3. Any tools above you'd add/drop, or schema fields I'm
   underweighting? (e.g., the OpenReview reviewer-score fields are
   a goldmine I want to expose well.)

Happy to scope this however you'd like — minimal v1 then iterate,
or full surface from day one. I'm targeting ~1–2 weeks of evening
work for v1.

Thanks again,
— hhh2210