Firecrawl MCP Server

Overview Schema Source Related Servers Discussions Admin

Firecrawl research paper search

firecrawl_research_search_papers

Read-only

Search scientific literature by natural-language query, returning ranked paper metadata and abstracts from PubMed, bioRxiv, medRxiv, arXiv, and other sources; filter by author, category, or date.

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, date, and sort options constrain or reorder 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.

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`).
`sort`	No	`relevance` (default) or `date_desc`, which returns the newest of the most relevant matches, newest first by created date. It does not list every paper in a date range; add `from` (and `to`) for that.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv3.36.1Nov 5, 2026

addedInput schema / properties / sort

Added value: +{
+  "description": "`relevance` (default) or `date_desc`, which returns the newest of the most relevant matches, newest first by created date. It does not list every paper in a date range; add `from` (and `to`) for that.",
+  "enum": [
+    "relevance",
+    "date_desc"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / results / items / properties / authors / description

Previous value: -"Authors, as a comma-joined string or as `{name, affiliation}` entries."New value: +"Authors, as a list of names or a comma-joined string."

changedOutput schema / properties / results / items / properties / createdDate / description

Previous value: -"Date the paper was first indexed or published."New value: +"Date the paper was first indexed or published (`YYYY-MM-DD`)."

changedOutput schema / properties / results / items / properties / updateDate / description

Previous value: -"Date the paper was last updated."New value: +"Date the paper was last updated (`YYYY-MM-DD`)."

Changed2 schema fields changedv1.0.2Oct 29, 2026

changedInput schema / $schema

Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "description": "Ranked papers with canonical IDs, titles, authors, and abstracts.",
+  "properties": {
+    "results": {
+      "description": "Ranked papers, in the order the text block lists them.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "abstract": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Paper abstract."
+          },
+          "authors": {
+            "description": "Authors, as a comma-joined string or as `{name, affiliation}` entries."
+          },
+          "categories": {
+            "anyOf": [
+              {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Paper categories, such as `cs.LG`."
+          },
+          "createdDate": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Date the paper was first indexed or published."
+          },
+          "ids": {
+            "description": "Source identifiers by namespace, such as `arxiv`, `doi`, or `pmid`."
+          },
+          "paperId": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Canonical paper identifier."
+          },
+          "primaryId": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Display identifier, ordered for citation and fetch use."
+          },
+          "title": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Paper title."
+          },
+          "updateDate": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Date the paper was last updated."
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}

First observedv1.0.1Jul 5, 2026

TDQS

A3.7/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 the safety profile is covered and the description is not obligated to restate it. It adds real behavioral context beyond that: the indexed corpus's domain coverage, the fact that results are relevance-ranked, and the non-obvious ranking insight that rephrasing a question changes which papers surface. The final sentence mostly restates the output schema, which is the only wasted signal.

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 sentences, front-loaded with corpus scope, then filtering, then returns — a sensible order with no filler. The only redundancy is the closing sentence about return fields, which an output schema already provides, though it is brief enough not to be costly.

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?

With 7 fully described parameters, an output schema and safety annotations, the description supplies the missing piece an agent needs — what corpus is being searched and how results are ranked. Minor gaps remain: no mention of result caps or pagination behavior across calls, and no explicit pointer to the companion research tools for reading or expanding a found paper.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (including k's default of 40, the from/to date format, and sort's semantics) is already fully documented in the schema. The description only summarizes that author, category, date and sort options 'constrain or reorder results', adding no syntax, format or default details beyond the structured fields. Baseline 3 applies where the schema carries the load.

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?

The description opens with a specific verb+resource ('Search paper metadata and abstracts') and immediately enumerates the corpus (PubMed, bioRxiv, medRxiv, arXiv, other scientific sources), which implicitly separates it from the generalist siblings firecrawl_search, firecrawl_developer_search and firecrawl_gov_search. It also states the result shape (ranked papers with canonical IDs, titles, authors, abstracts). It stops short of naming any sibling explicitly, so an agent must infer the routing.

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?

There is one genuinely useful usage cue — 'Several distinct framings of the same question surface different papers than a single query does' advises on query strategy — plus a note that filters 'constrain or reorder results'. But there is no explicit statement of when to choose this over firecrawl_search or when to follow up with firecrawl_research_read_paper / firecrawl_research_related_papers, so routing is left to inference.

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