BGPT Scientific Data

Search scientific evidence

search_papers

Read-onlyIdempotent

Search claim-level evidence extracted from full-text scientific papers.

Args: query: Search terms (e.g. "CRISPR gene editing efficiency"). SHORT, concise queries are best. English language only. Use days_back, num_results, min_citations, and study_type instead of adding years or filters to the query. num_results: Number of results to return (1-100, default 16). First 50 results are free, then metered per result for paid users. days_back: Only return papers published within the last N days. min_citations: Only return papers with at least this many references cited. study_type: Only return papers of this study type. One of: primary study | systematic review | meta-analysis | narrative review | protocol | dataset | commentary | other. output_format: "evidence" for compact claim-level evidence (default), "legacy" for original paper metadata, or "full" for both.

Returns: An envelope whose results list contains papers with claims, experiments, exact results, demonstrated scope, limitations, and provenance.

Input Schema

TableJSON Schema

Name	Required	Default
`query`	Yes
`days_back`	No
`study_type`	No
`num_results`	No
`min_citations`	No
`output_format`	No	evidence

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedAug 27, 2026

addedInput schema / properties / min_citations

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / study_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed5 schema fields changedJul 16, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / days_back / description

Removed value: -"Only return papers published within the last N days."

removedInput schema / properties / num_results / description

Removed value: -"Number of results to return (1-100, default 16). First 50 results are free, then billed at $0.01/result for paid users."

addedInput schema / properties / output_format

Added value: +{
+  "default": "evidence",
+  "type": "string"
+}

removedInput schema / properties / query / description

Removed value: -"Search terms (e.g. \"CRISPR gene editing efficiency\") Short, concise queries are best. English language only. Don't include years or filters — use the days_back and num_results params instead."

Changed4 schema fields changedJun 30, 2026

removedInput schema / properties / api_key

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

addedInput schema / properties / days_back / description

Added value: +"Only return papers published within the last N days."

addedInput schema / properties / num_results / description

Added value: +"Number of results to return (1-100, default 16). First 50 results are free, then billed at $0.01/result for paid users."

addedInput schema / properties / query / description

Added value: +"Search terms (e.g. \"CRISPR gene editing efficiency\") Short, concise queries are best. English language only. Don't include years or filters — use the days_back and num_results params instead."

First observedMar 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description's job is lighter, but it still adds valuable behavioral context: the first 50 results are free then metered for paid users, the output can be evidence/legacy/full, and the return envelope contains claims, experiments, exact results, scope, limitations, and provenance. This goes well beyond the annotations.

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

Conciseness5/5

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

The description is organized into Args and Returns sections with no filler. Each sentence adds operational value, and the most important usage constraints are front-loaded in the query guidance.

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

Completeness5/5

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

The description is fully sufficient for a six-parameter tool with no schema descriptions. It covers all parameter semantics, output format choices, pricing/metering behavior, language constraints, and return structure. Nothing an agent needs to call this tool correctly is missing.

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

Parameters5/5

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

With schema description coverage at 0%, the description carries the full burden and succeeds. Every parameter is explained with ranges, defaults, allowed values, and behavioral meaning — e.g., num_results '(1-100, default 16)', study_type lists all valid options, and output_format explains each option.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Search claim-level evidence extracted from full-text scientific papers.' This clearly states what the tool does and distinguishes it from the sibling lookup_paper, which implies retrieving a single known paper rather than searching across evidence.

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

Usage Guidelines4/5

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

The description gives clear usage context, including 'SHORT, concise queries are best,' 'English language only,' and guidance to use days_back, num_results, min_citations, and study_type instead of embedding filters in the query. However, it does not explicitly explain when to choose this tool over the sibling lookup_paper.

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

All BGPT Scientific Data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

The two tools are clearly distinct: one retrieves a specific paper by DOI, the other searches for papers based on a query. There is no overlap or ambiguity in their purposes.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (lookup_paper, search_papers), with a minor pluralization difference that does not affect consistency. The naming style is uniform and predictable.

Tool Count3/5

With only two tools, the server feels borderline thin for a scientific data domain. However, both tools are substantial and cover the core functions of searching and retrieving papers, so it is not overly limiting.

Completeness4/5

The two tools cover the primary workflow of searching and retrieving papers by DOI. Minor gaps exist (e.g., no advanced filtering or sorting), but there are no obvious dead ends for the stated purpose of accessing claim-level evidence.

Resources

Need Help?