Firecrawl MCP Server

Firecrawl research paper search

firecrawl_research_search_papers

Read-only

Search scientific literature with natural-language queries and filter by author, category, or date. Returns ranked papers with IDs, titles, authors, and abstracts.

Instructions

Search paper metadata and abstracts with a natural-language query across the indexed corpus, which spans biomedical, life-science, and clinical literature (PubMed, bioRxiv, medRxiv) alongside arXiv and other scientific sources. Optional author, category, and date filters constrain results.

Several distinct framings of the same question surface different papers than a single query does.

Returns ranked papers with canonical IDs, titles, authors, and abstracts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "firecrawl_research_search_papers"
  }
}

Input Schema

Name	Required	Description
`k`	No	Number of ranked papers to return (default 40).
`to`	No	Inclusive upper bound on created/updated date (`YYYY-MM-DD`).
`from`	No	Inclusive lower bound on created/updated date (`YYYY-MM-DD`).
`query`	Yes	Natural-language research topic or question, including methods, systems, conditions, populations, interventions, or outcomes when relevant.
`authors`	No	Author substring filter(s); ALL must match (case-insensitive).
`categories`	No	Paper category filter(s) (e.g. `cs.LG`); ALL provided values must match.

Output Schema

Name	Required	Description	Default
`results`	Yes	Ranked papers, in the order the text block lists them.
`agent_hints`	No	Optional response guidance from the Firecrawl API.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.28.2Nov 4, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered; the description adds the non-obvious behavioral facts that results are ranked and that query phrasing materially changes the result set. It omits cost, rate limits, and result-count behavior for large k, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the corpus scope front-loaded and the return shape last. The middle sentence on query framings is useful but slightly interrupts the corpus-to-return flow; nothing is redundant enough to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter search tool with a full output schema, the description covers corpus scope, filter behavior, query strategy, and return shape. The remaining gaps (cost, behavior at k near the 500 cap, ranking basis) are minor and partly mitigated by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining the retrieval effect of query phrasing and by noting that author, category, and date filters 'constrain' results, framing the filters as narrowing rather than re-ranking. It still adds no syntax or format detail beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search paper metadata and abstracts') plus the exact corpus it covers (PubMed, bioRxiv, medRxiv, arXiv), which lets an agent distinguish it from firecrawl_research_read_paper or firecrawl_research_inspect_paper. It never names a sibling explicitly, so the differentiation is inferential rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers genuine query-strategy guidance ('several distinct framings of the same question surface different papers'), which tells the agent how to use the tool well. However, it gives no explicit when-to-use/when-not versus firecrawl_search or the other research_* siblings, and no prerequisites or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.