Lune Research

Searches full-text, peer-reviewed papers from top-tier venues. Use for questions 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. Returns each paper's metadata and the passages that matched. Hybrid semantic + lexical search over titles, abstracts, and full text. Phrase the query the way a researcher would describe the topic in prose, not a keyword bag. Triggering questions: “what's the latest on diffusion guidance”, “which papers compare against SimPO” (requirements beyond the topic are checked per paper: `conditions`, evidence first in `contexts`). `paper_id` is a handle for YOU to fetch full text via `get_paper_fulltext`; never show it to the user: cite papers by title, authors, and venue. `rerank_score` is the calibrated Cohere Rerank v3.5 relevance (0..1), null when the reranker did not run (a lone term, or a failure); `score` is uncalibrated: keep the hits' order. The top-level `best_score` and `low_confidence` derive from `rerank_score`: `low_confidence` marks weaker matches, so rephrase for stronger ones and still cite a hit that fits; with no reranked hit, `best_score` is null and `low_confidence` false, so judge each hit yourself. Each hit carries metadata, abstract, ids, and `contexts` spans to ground or quote from; `detail: false` returns concise hits with one `snippet`. Page with `offset` (re-call with offset += limit while `has_more` is true and `conditions` match page 1's; offset + limit <= 50). Order with `sort_by` (relevance / date / citations, within the ranked shortlist, not the corpus). Narrow with `year_min` / `year_max` / `venues`.

Use 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. One call returns one merged, ranked list of the papers the angles found, with the passages that matched. 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, by index into the echoed `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 retrieval as `search_papers` (Cohere Embed v4 + BM25 + Cohere Rerank v3.5) without its server-side rewrites, because your variants are the expansion: spell out abbreviations and synonyms in the variants themselves. 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. Each hit carries metadata, abstract, ids, and the matched `contexts` spans to ground or quote from; `detail: false` returns concise hits with one `snippet`. `paper_id` is a handle for YOU to fetch full text via `get_paper_fulltext`; cite papers by title, authors, and venue, never by id. 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.

Use 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.

Use 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). Each edge carries `contexts`, the citing sentences with their section, which show HOW a work is used (baseline, method borrowed, result disputed). Page with `limit` / `offset`; the response reports `total` and `has_more` so you can walk a large citation set.

Use 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.

Use 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`.

Given 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.

Pull 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": one call reads every paper and returns the table. 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.

Fact-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. 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.

Use 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.

Use 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. Searches the Lune guidance corpus, curated from senior researchers, reproducibility checklists, venue-reviewer guidance, and author tutorials, so methodology advice can cite vetted sources. 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.

Use 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.

Sends the user's feedback about Lune to the Lune team. Use it when the user says something about Lune itself (papers it missed, results that did not fit, an error, something that helped, an idea): offer to pass it on, show the user the message you would send, and call this only after they agree. Set `allow_training` only if they also agreed that Lune may train models on it, after telling them they can withdraw that at any time in their Lune account settings. Write the message from what the user said about Lune, leaving out unrelated conversation and personal details.