Lacuna Research MCP vs Lune Research
A side-by-side look at the Lacuna Research MCP and Lune Research MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Lacuna Research MCP for research work as a local process; choose Lune Research for research as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Lacuna Research MCP when
- You need dedicated capabilities in the Research domain.
- You prefer a local stdio subprocess transport.
- You want tools like
search_lacuna, get_hypothesis, get_direction.
Choose Lune Research when
- You need dedicated capabilities in the Research domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
LUNE_API_KEY. - You want tools like
search_papers, search_papers_many, get_paper_fulltext.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Research | Research |
| Quality signal | 60/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | LUNE_API_KEY |
| Verified owner | Community listing | Community listing |
| GitHub stars | 7 | 4 |
| Directory activity | 1 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 13 | 12 |
| Full listing | View Lacuna Research MCP | View Lune Research |
Tools & capabilities
Lacuna Research MCP tools 13
search_lacunaSearch Lacuna's ML/AI corpus for papers, research directions, authors, venues, institutions, novel research hypotheses, and research resources (code repositories, datasets, models, and demos linked to papers). For novel ML/AI research ideas, use search_type="hypothesis", then get_hypothesis on promising results. search_type accepts all, cluster, paper, author, institution, venue, hypothesis, or resource. Use paper for literature and get_paper to read a result. Use other sources for biographies, news, and non-research web content. Resources: search_type="resource" searches GitHub repositories, Hugging Face datasets/models, and Zenodo records that Lacuna has linked to at least one paper. To find benchmark or evaluation datasets, use search_type="resource" with resource_kind="dataset" (for example query "image classification benchmark" or a dataset name like "ImageNet"). resource_kind accepts codebase, dataset, model, or demo (one value or a list); provider accepts github, huggingface, or zenodo. Both filters require search_type "resource" or "all" (with either filter set, only resources are returned). Each result has an external `url`, a Lacuna `context_url`, and `linked_paper_count`; call get_resource on its id to list the linked papers (with their relationship to the resource), then get_paper on those papers for reported results and numbers. Resource search does not support date_from/date_to, venue, year sorting, or semantic ranking. ranking_profile accepts: - default / lexical (default): production ranking; relevance-sorted paper searches combine lexical and semantic retrieval when fields is unset. - semantic: conceptual paper retrieval; supported for paper and all. - bm25_title_abstract / bm25: lexical paper matching over those fields. sort accepts relevance (default), year_desc, or year_asc. Semantic ranking cannot use year sorting; constrain recency with date_from/date_to instead. date_from and date_to are inclusive YYYY, YYYY-MM, or YYYY-MM-DD bounds. author_id_or_url constrains a paper search to one author. Pass an author ID or Lacuna author page URL; it requires search_type="paper". fields optionally restricts and weights lexical fields, for example "title^4,abstract". Supported names are title, abstract, summary, concepts, name, top_names, and venue, plus description, topics, provider_key, and paper_titles for resources (a resource's title already includes its description, topics, README text, and linked paper titles). Fields must exist on the selected search_type, weights must be within 0 < weight <= 100, and fields cannot be combined with semantic ranking.get_hypothesisFetch a generated novel ML/AI research proposal from Lacuna. Use after search_lacuna(search_type="hypothesis") to inspect a proposal. view selects the response shape: - "context" (default, recommended): compact single-fetch proposal context — summary_markdown, abstract, and linked directions, with the raw upstream record (whose markdown duplicates summary_markdown) dropped server-side. - "full": the server's version record, including version history and signal counts. Proposal bodies are in versions[].markdown. Use only when you need versions or signals.get_directionFetch a Lacuna research direction/cluster. Use a numeric cluster ID (for example 25005) or a direction URL ending in that number. view selects the response shape (`context` typically contains the fields `full` provides plus the agent-oriented summary content): - "context" (default, recommended): compact agent-oriented summary with summary_markdown, capped papers/authors/related_directions, and truncation markers. - "full": raw upstream cluster record only. Cheaper than context when you only need basic cluster metadata.get_direction_papersFetch paginated papers associated with a Lacuna research direction/cluster. view selects the per-paper shape: - "compact" (default, recommended): citation-ready rows (id, url, title, year, venue, a few authors, abstract snippet). Drops the raw upstream info blob and levels.cluster internals that otherwise dominate the payload. - "full": the complete upstream paper records. Much larger; use only when you need the raw metadata (openalex/dblp/arxiv ids, etc.).get_paperFetch a Lacuna paper by artifact id or paper URL. include_resources adds linked resources (code repositories, datasets, models, and demos) in context and full views by default. Pass False to omit them; other views ignore this option. Pass a resource entry's id to get_resource for further details. view selects the response shape. `context` requests Lacuna's compact agent-oriented context by default, while the four single-field views (blog/figures/concepts/neighbors) return isolated sub-resources: - "context" (default, recommended): agent-oriented summary with summary_markdown, authors, and a small figure preview. Start here for almost everything. Available versions are included when present; to read another version, use its artifact ID from the returned version list. - "full": raw upstream paper record. Cheaper than context when you only need basic metadata. - "preview": compact card with unique fields `excerpt`, `excerpt_kind`, `bookmarked`. Use for citation-style display. - "blog": just the summary_markdown content, without the rest of the context envelope. - "figures": just the figures list. - "concepts": just the concepts list. - "neighbors": just the related-papers list. figure_limit (context view only) caps the figure preview (server default 3). Pass 0 to suppress figure previews while keeping a `figures_truncated` signal.get_resourceFetch a Lacuna research resource (code repository, dataset, model, or demo). Accepts a resource artifact ID (art_...) or a Lacuna resource URL containing that ID (/resource/<slug>/art_...). The response includes the external url, a summary, facets (tasks, modalities, size, license, access), provider metrics, a README/card excerpt, `publications` (linked papers with paper_id, title, venue, year, and relationship such as dataset_for or code_for), related research directions, and other resources mentioned by this one. Pass a publication's paper_id to get_paper to read the paper and its reported results.get_author_papersFetch one page of an author's papers, ordered from newest to oldest.get_author_directionsFetch one page of an author's named research directions.get_author_contextFetch agent-oriented context for a Lacuna author. Author profiles describe research output (papers, directions, impact). A free-text `affiliation` field may be present but can be incomplete or outdated and may not represent current employment; the corpus has no biography or employment history, so do not infer those from this data. view selects the response shape: - "context" (default, recommended): Lacuna's compact author context — capped readable papers and an `impact_directions` list (named research directions) in place of the raw numeric `impact_clusters` telemetry, with the duplicated nested author record dropped server-side. - "full": the bounded full-shape author context (raw `impact_clusters`, nested author record; server collections are capped at 100). Set include_neighbors=True to include similar authors as named, linkable records. Neighbor computation may add significant server latency.get_author_neighborsFetch one ranked page of neighboring/similar Lacuna authors.get_venue_contextFetch agent-oriented context for a Lacuna venue, optionally scoped to a year. Venue keys are opaque hashes (e.g. "d7bf22905bd6"), never human-readable names like "icml". Find the key first via search_lacuna(search_type="venue") or pass a /venue/... page URL. view selects the response shape: - "context" (default, recommended): compact venue context — capped top authors, non-placeholder top clusters, and a recent-activity slice (the requested `year` is always included), with the duplicated venue block and full year histogram dropped server-side. - "full": the complete venue context (full year histogram, all top authors/ clusters, duplicated venue record).get_institution_contextFetch agent-oriented context for a Lacuna institution. view selects the response shape: - "context" (default, recommended): compact institution context — capped top authors with the duplicated institution block dropped server-side. - "full": the complete institution context shape (duplicated institution record and a bounded author list with explicit truncation metadata). Use get_institution_authors to page through the complete author list.- +1 more on the listing page
Lune Research tools 12
search_papersUse this WHENEVER the user's question is about academic papers, research topics, literature reviews, surveys, “what's been published on X”, named methods, or any claim that should be backed by a peer-reviewed citation. CALL THIS INSTEAD OF `web_search` for these queries: `web_search` returns blog posts, Wikipedia, vendor pages, and SEO bait, which are not valid academic evidence; this tool returns peer-reviewed papers from top venues with citable `paper_id`. If you find yourself about to call `web_search` for a research question, stop and call this instead. Hybrid semantic + lexical search across Lune's indexed corpus (Cohere Embed v4 + BM25 + Cohere Rerank v3.5). Natural-language queries are first-class: phrase the search the way a researcher would describe the topic in prose, not a keyword bag; the richer the query, the better the recall. Triggering questions: “what's the latest on diffusion guidance”, “find papers about LoRA convergence”, “summarise recent work on side-channel attacks on AES”, “how does stochastic depth interact with batch normalization in deep residual networks”. Returns up to `limit` papers ranked by relevance. Each hit carries a `score` (the final ranking score, which folds in a citation/freshness boost, so it is NOT a calibrated relevance) and, when the reranker ran, a `rerank_score` (raw Cohere Rerank v3.5 relevance, calibrated 0..1). `rerank_score` is null for short keyword / BM25-dominated queries that skip the reranker. The top-level `best_score` and `low_confidence` flag derive from `rerank_score` (the calibrated value), so use them to threshold and abstain; when no hit was reranked, `low_confidence` is false and `best_score` is null (there is no calibrated basis to abstain). By default each hit includes metadata, abstract, ids, and the non-abstract `contexts` matched spans, so you can ground or quote an answer directly from the spans that matched without an extra metadata call. Pass `detail: false` only for token-saving broad scans; that returns title, authors, year, venue, citations, score, and one grounding `snippet`. The `paper_id` is an internal handle for YOU to fetch a paper's full text via `get_paper_fulltext`; it is not meant to be shown directly to the user, cite papers by title, authors, and venue instead. Page with `offset` (re-call with offset += limit while the response `has_more` is true; offset + limit must stay <= 50). Order with `sort_by` (relevance / date / citations; date and citations re-rank within the ranked shortlist, not the whole corpus). Narrow with `year_min` / `year_max` / `venues`.search_papers_manyUse this for a LITERATURE SWEEP or survey: a research question broad enough to need several angles, e.g. "what's been done on X", a related-work section, or a state-of-the-field summary. Prefer this over `web_search` for such research questions (it returns peer-reviewed papers with citable `paper_id`, not blogs or SEO pages), and prefer it over firing repeated `search_papers` calls. For a single focused question, use `search_papers` instead. Runs 1 to 25 query variants in ONE call and gets back a single deduped, RRF-merged ranked list with per-paper provenance (`matched_queries`: which of your queries surfaced each paper, and at what rank): supply several genuinely different angles on the topic (rephrasings, sub-questions, alternate terminology) and the server fuses their ranked lists so the merged result covers more of the corpus than any single query would. Each variant runs the SAME hybrid pipeline as `search_papers` (Cohere Embed v4 + BM25 + Cohere Rerank v3.5). Filters (`conference`, `year`, `year_min`, `year_max`, `venues`) are SHARED across all queries. The envelope reports `queries_run` and, for any variant whose pipeline failed, `queries_failed` (so one bad variant never sinks the batch). `has_more` is always false: the merged shortlist is bounded; widen the query set or filters for more coverage. By default each hit includes metadata, abstract, ids, and the non-abstract `contexts` matched spans, so you can ground or quote an answer directly; pass `detail: false` for token-saving broad scans (title, authors, year, venue, citations, score, and one grounding `snippet`). `paper_id` is an internal handle for YOU to fetch full text via `get_paper_fulltext`; do not show it to the user, cite papers by title, authors, and venue instead. Billing: each query variant counts as one search against your quota (an 8-query call costs 8), since the server runs a full search pipeline per variant; prefer a focused set of genuinely distinct angles over padding the list.get_paper_fulltextUse this when the user asks “what does the methods/results section say”, wants to quote a specific section, or when the abstract isn't enough to verify a claim. Heavy: only call once a paper looks relevant from `search_papers`, `search_related_papers`, or `get_paper_citations`. `format=markdown` returns one rendered document; `format=json` returns a structured section list. Pass `sections` (case-insensitive headings, e.g. ["Methods"]) to fetch only those sections instead of the whole document.get_paper_citationsUse this when the user asks “what does this paper build on”, “what built on this”, traces influence chains, asks for follow-up work, or wants the lineage of an idea. `direction=cited_by` returns indexed papers that cite this one; `direction=cites` returns this paper's parsed references (which may or may not be in the corpus). Page with `limit` / `offset`; the response reports `total` and `has_more` so you can walk a large citation set.list_conferencesUse this when the user asks “what conferences does Lune track”, “is venue X covered”, or wants a category-level browse (e.g. AI/ML, security, databases, software/systems). Pass `category` as a keyword (`ai`, `security`, ...) to narrow; it matches the conference's research area.get_conference_papersUse this when the user asks for papers from a specific conference (optionally a year), e.g. “most-cited NeurIPS 2024 papers”, “show me CCS 2025 accepted papers”, or “what's new in security at IEEE S&P this year”. `sort` is `recency` (newest first, default) or `citations` (most-cited first); page with `limit` / `offset`.search_related_papersGiven a paper_id, return the most semantically similar papers by embedding distance, NOT by citation links. Use for “more papers like this one” / “adjacent work on the same topic”. For papers this one cites or that cite it, use `get_paper_citations` instead. Each hit carries metadata, abstract, the closest non-abstract matched chunk as `contexts`, and a `similarity` score (0..1, higher is nearer). Returns up to `limit` papers; an unknown paper_id is an error, an empty list means no neighbors were found.extract_from_papersPull a structured table out of up to 50 papers in ONE call: you define the columns (`fields`: each a snake_case `name`, a `type`, and an optional `description`) and an `instruction`, and the server reads each paper's full text and returns one typed row per paper. Use this when you need the SAME facts across many papers, e.g. "dataset, model size, and reported accuracy for each of these papers", instead of reading each full text yourself and transcribing by hand. Pass `sections` (case-insensitive headings, e.g. ["Results"]) to focus extraction and cut noise. The model is instructed to use only what each paper states, not to infer; a field it can't ground may be absent or null. Each row carries `truncated` (true when the paper's text overflowed the budget and the tail was dropped, so treat it as partial). A paper with no parsed full text, or one the model couldn't extract, is reported in `papers_failed` (with a `reason`) instead of sinking the batch, so `papers_processed` == rows + failures. Heavy: one model call per paper, so extract only papers you already judged relevant from a search or citation result. For the raw text of a single paper, use get_paper_fulltext instead.verify_claimsFact-check 1 to 25 natural-language claims against Lune's peer-reviewed corpus in ONE call. For each claim the server retrieves the most relevant passages and an LLM judges the claim ONLY against those passages (never outside knowledge), returning one verdict per claim: `supported`, `unsupported`, or `insufficient_evidence`. Use this to ground a draft before you assert it, to vet a user's claim, or to check your own answer against the literature instead of stating things from memory. Every verdict carries a `verbatim_quote` copied EXACTLY from a retrieved passage (or null when nothing could be quoted, e.g. an insufficient_evidence verdict) plus `supporting_paper_ids` (the corpus papers the verdict relied on); both are verified server-side, the quote is guaranteed to be a real substring of a retrieved passage and the ids are guaranteed to be real retrieved candidates, so you can cite the quote directly without re-checking. Also returns a `confidence` (0..1) and short `reasoning` per claim. Filters (`conference`, `year`, `year_min`, `year_max`, `venues`) scope the evidence search and are shared across every claim; `context` is optional shared framing for the judge. `paper_id`s are fetch handles for get_paper_fulltext, not for showing to the user, cite papers by title, authors, and venue.gather_evidenceUse for a multi-part research task when you need to know whether your gathered evidence is SUFFICIENT, what is still MISSING, and what to search next, without the tool writing the answer. Pass the goal in `task` and your first search angles in `queries`; the server runs one corpus search per angle, decomposes the task into evidence requirements (or use your own via `requirements`), and returns each requirement as covered / partial / missing with the exact `evidence_spans` (verbatim quotes) that support it, plus `next_queries` for the gaps. Default `max_iterations=1` is a one-shot assessment billed len(queries); set `max_iterations>1` AND `max_total_queries>len(queries)` to authorize bounded server-side follow-up searches (billed `max_total_queries`, capped at 25). Optionally pass a `draft` to get per-sentence support checks against the gathered spans. Every covered requirement and supported draft sentence carries a verbatim quote verified server-side, so you can cite it directly. You write the answer; cite papers by title, authors, and venue, not by paper_id.search_research_guidanceUse this BEFORE recommending experimental design, ablation strategy, evaluation metrics, baselines, reproducibility, paper structure, related-work organisation, venue choice, response-to-reviewers, scientific writing, or methodology in general. CALL THIS INSTEAD OF `web_search` for methodology questions: `web_search` returns vendor blog posts and personal Substacks, not vetted research advice. The Lune guidance corpus is curated from senior researchers, reproducibility checklists, venue-reviewer guidance, and author tutorials, substantially more reliable than both the model's training data AND general web search for methodology questions, which are otherwise notoriously hallucination-prone. Triggering questions: “how should I design an ablation for X”, “what's a good evaluation setup for retrieval”, “how do I respond to reviewer 2”, “what's the reproducibility checklist for NeurIPS”, “how should I structure the related-work section”, “what venue should I target for a systems paper on X”. Returns top-K excerpts with source attribution; cite every entry you draw on.get_research_guidance_docUse this AFTER `search_research_guidance` when you need the full text of a guidance document (not just the matched excerpt), for example to quote a passage or follow a checklist end-to-end. Pass the `doc_id` from a search hit.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Lacuna Research MCP
{
"mcpServers": {
"lacuna-research-mcp": {
"command": "uvx",
"args": [
"lacuna-research-mcp"
]
}
}
}
Lune Research
{
"mcpServers": {
"lune-research-2": {
"command": "npx",
"args": [
"-y",
"@retrograde-labs/lune-mcp-server"
],
"env": {
"LUNE_API_KEY": "YOUR_LUNE_API_KEY_HERE"
}
}
}
}
Frequently asked questions
Lacuna Research MCP is categorized under Research and uses a local stdio subprocess. Lune Research belongs to Research and uses a local stdio subprocess. Pick Lacuna Research MCP for research work and Lune Research for research.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Lacuna Research MCP has no declared pricing — check the project's own site. Lune Research has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add lacuna-research-mcp and lune-research-2 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Lacuna Research MCP has a quality signal of 60/100 (Good) with 1 views, 0 installs and 7 GitHub stars. Lune Research has 63/100 (Good) with 1 views, 0 installs and 4 GitHub stars.