---
id: gh-firecrawl-research-index
name: "firecrawl-research-index"
url: https://skills.yangsir.net/skill/gh-firecrawl-research-index
author: firecrawl
domain: science
tags: ["research", "literature-review", "semantic-search", "academic-papers", "information-retrieval"]
install_count: 24000
rating: 4.60 (120 reviews)
github: https://github.com/firecrawl/skills/tree/main/skills/firecrawl-research-index
---

# firecrawl-research-index

> 此技能利用 Firecrawl Research 进行语义搜索、结构化扩展和体内验证，高效查找回答研究查询的学术论文。无论是单篇论文查找还是多篇文献集检索，该 Skill 都能帮助用户快速定位相关研究，大幅提升文献调研效率和准确性。

**Stats**: 24,000 installs · 4.6/5 (120 reviews)

## Before / After 对比

### 文献调研效率

**Before**:

用户在没有此技能之前，需要手动在多个学术数据库中进行关键词搜索，耗费大量时间筛选不相关结果，并可能遗漏重要文献，导致调研周期长且不全面。

**After**:

该 Skill 通过语义搜索和结构化扩展，能够快速定位最相关的学术论文，并提供相关文献集，将文献调研时间从数小时缩短至数十分钟，显著提升效率和覆盖面。

| Metric | Before | After | Change |
|---|---|---|---|
| 文献调研时长 | 240分钟 | 30分钟 | -87.5% |

## Readme

# Firecrawl Research Index

Find the research papers that answer a research query. Some questions have a single answer; many have several — and when in doubt, lean toward returning the fuller relevant set (most relevant first) rather than narrowing to one. A reader is better served seeing the neighboring methods and papers than having them silently dropped.

There is **no fixed recipe**. Read the query, decide what kind it is, and choose the approach below. Some queries need a single search; others need heavy sturctural/semantic expansion. Don't run machinery a query doesn't call for.

## The tools, and what each is uniquely good at

- MCP: **`firecrawl_research_search_papers(query, k?)`**
  CLI: **`firecrawl research search-papers <query> [--k <number>]`**
  Semantic (HyDE) search over **abstracts**. The natural first move for almost any query.
  If results look thin or all-alike, re-run with a different framing (sibling domain, rival method, dataset/benchmark name) rather than giving up.

- MCP: **`firecrawl_research_related_papers(seed_ids, intent, mode?, k?)`**
  CLI: **`firecrawl research related-papers <seedIds...> --intent <intent> [--mode <similar|citers|references>] [--k <number>]`**
  Semantic and structural expansion, ranked to your `intent`.
  This reaches papers semantic search *cannot*, and it's how you turn one good hit into the rest of a set.
  `mode=similar` → niche siblings; `citers` → who uses/builds on the seeds; `references` → what they build on / compare against.

- MCP: **`firecrawl_research_inspect_paper(id)`**
  CLI: **`firecrawl research inspect-paper <id>`**
  Canonical metadata for **one** paper: title, abstract, authors, categories, source ids, and dates.
  Use it after `search_papers` or `related_papers` when you need the complete citation/metadata for a candidate, or when you have an id from elsewhere and need to confirm what paper it resolves to.
  This does **not** read the paper body; use `read_paper` for specific full-text questions.

- MCP: **`firecrawl_research_read_paper(id, question)`**
  CLI: **`firecrawl research read-paper <id> --question <question>`**
  In-body passages of **one** paper, to verify a load-bearing constraint (a method actually used, a score actually reported, an affiliation, what a paper compares to).
  Use it to settle a specific doubt, not on everything.

- MCP: **`firecrawl_search(query)` / `firecrawl_scrape(url)`**
  CLI: **`firecrawl search <query>` / `firecrawl scrape <url>`**
  General **web** search and page fetch, for facts that don't live in paper abstracts: benchmark **leaderboards**, rankings, "who scores best / is largest / is most used."
  Find the ranking on the web, then map the top entries back to papers with `search_papers`.
  Reach for these only when the corpus can't answer the question on its own.

## Match the approach to the query

- **Single *named* paper** ("the Qwen3 report") → one `search_papers`, done. This is the only case that truly wants exactly one paper.
- **Paper by description / by method or technique** ("the paper that introduced X", "training-free N-gram detection of AI text") → find the best match, then assume there's a *family*: expand with `related_papers` and **include the closely-related methods/papers too**. Even when one paper is the exact literal match, surface and keep its neighbors — don't narrow to the single best hit and reason the rest out. Only treat it as one-answer if the query names a specific paper.
- **Enumeration / method-family** ("papers that do X", "alternatives to Adam", "benchmarks for Y") → the answer is a *set*, and this is where `related_papers` earns its keep: expand several strong anchors with `mode=similar`, re-seed from new strong hits. One search is never enough here.
- **Exhibiting** ("papers that *use* / exhibit property P") → the relevant papers apply P but their abstracts may not describe it. Go from P's defining paper outward via `citers`/`references`, and use `read_paper` to confirm a candidate actually uses P.
- **Superlative / leaderboard** ("best on benchmark X", "largest", "most popular") → the ranking lives on **leaderboards / the web**, not in any single abstract. Use `firecrawl_search` / `firecrawl_scrape` to find the benchmark's leaderboard or rankings, read off the top models/papers, then `search_papers` each to get its paper. As a fallback, search the benchmark and `read_paper` candidates for reported numbers. The hardest kind — cast wide.
- **Org / author filtered** ("from \<org\>", "by \<author\>") → topical match isn't enough; verify the affiliation/authorship (metadata or `read_paper`) before keeping a paper.
- **Compare-against** ("what does paper X benchmark against / build on") → the answer is *inside* paper X: `read_paper(X, ...)` or `related_papers([X], ..., mode="references")`.

## Principles

- **When in doubt, include.** For any topic / method / comparison question, return the relevant *family*, not just the single best match — err toward keeping a plausibly-relevant paper rather than dropping it. The neighboring methods are part of a good answer; don't reason close work out just because one paper is the most exact match.
- **Follow the literature, and keep what you find.** The seminal source, the competing methods, the close neighbors are usually a hop away — use `related_papers`, and *include* them, not just the first hit. Stopping at one good result is the most common way to leave the reader with half an answer.
- **Verify to exclude, not to gatekeep.** Use `read_paper` to rule a paper *out* when a hard constraint clearly fails (wrong org/author, doesn't actually report the score). When a paper is plausibly relevant, lean toward keeping it rather than demanding proof.
- **Only drop the clearly off-topic.** Don't pad with papers you're confident are unrelated — but that's a high bar; most plausibly-relevant work should make the cut.


---
*Source: https://skills.yangsir.net/skill/gh-firecrawl-research-index*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-firecrawl-research-index/markdown*