BGPT allows AI assistants to search a database of scientific papers and retrieve structured experimental data extracted from full-text studies.
Search scientific papers using keyword queries (e.g. "CRISPR gene editing efficiency") via the search_papers tool
Retrieve 25+ metadata fields per paper, including methods, results, conclusions, quality/rigor scores, sample sizes, limitations, funding, conflicts of interest, and study type
Control result count with num_results (1–100 papers per query, default: 16)
Filter by recency using days_back to limit results to recently published papers
Free tier: first 50 results require no API key; paid access ($0.01/result) available via a Stripe subscription ID
Connect via MCP (SSE or Streamable HTTP) to Claude, Cursor, or any MCP-compatible AI tool
Use cases: literature reviews, evidence synthesis, research assistance, fact-checking, and grant writing
Provides Digital Object Identifiers (DOIs) for each scientific paper result, ensuring unique and persistent identification of experimental studies within the search output.
Search scientific papers from Claude, Cursor, any MCP-compatible AI tool, or plain Python.
BGPT is a remote Model Context Protocol (MCP) server and traditional JSON/HTTP API that gives AI assistants and Python apps access to a database of scientific papers built from full-text studies. Unlike typical search tools that return titles and abstracts, BGPT extracts raw experimental data — methods, results, conclusions, quality scores, sample sizes, limitations, and 25+ metadata fields per paper.
If you want to see why BGPT is different from ordinary paper search, start here:
EVIDENCE_DEMO.md — a claim-interrogation demo for GLP-1 alcohol craving
examples/bgpt_plotly_evidence_dashboard.py — generate a Plotly HTML dashboard with study methods, samples, limitations, conflicts, data availability, blind spots, and falsifiability prompts
PROMPT_GALLERY.md — prompts for scientific RAG, literature review agents, and evidence dashboards
The core idea: BGPT helps an AI agent ask what would weaken this scientific claim? before it summarizes the literature.
Related MCP server: mcp-spacefrontiers
Use BGPT from Python, REST, or an MCP client — no API key required for the free tier (50 free results).
Call the HTTP API directly from any Python script or notebook:
import requests
def search_bgpt(query, num_results=10, days_back=None, api_key=None):
payload = {"query": query, "num_results": num_results}
if days_back is not None:
payload["days_back"] = days_back
if api_key:
payload["api_key"] = api_key
response = requests.post(
"https://bgpt.pro/api/mcp-search",
json=payload,
timeout=30,
)
response.raise_for_status()
return response.json()["results"]
papers = search_bgpt("CRISPR delivery neurons", num_results=5)
print(papers[0]["title"])Most modern MCP clients support direct remote connections. BGPT offers two transports:
Transport | Endpoint |
SSE |
|
Streamable HTTP |
|
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"bgpt": {
"url": "https://bgpt.pro/mcp/sse"
}
}
}Cursor (.cursor/mcp.json):
{
"mcpServers": {
"bgpt": {
"url": "https://bgpt.pro/mcp/sse"
}
}
}Claude Code (CLI):
claude mcp add bgpt --transport sse https://bgpt.pro/mcp/sseCline / Roo Code / Windsurf — same config:
{
"mcpServers": {
"bgpt": {
"url": "https://bgpt.pro/mcp/sse"
}
}
}Tip: If your client supports Streamable HTTP, you can use
https://bgpt.pro/mcp/streaminstead.
{
"mcpServers": {
"bgpt": {
"command": "npx",
"args": ["-y", "bgpt-mcp"]
}
}
}npm install -g bgpt-mcpThen add to your MCP config:
{
"mcpServers": {
"bgpt": {
"command": "bgpt-mcp"
}
}
}Connect to either endpoint:
SSE: https://bgpt.pro/mcp/sse
Streamable HTTP: https://bgpt.pro/mcp/streamThat's it. No Docker, no build step.
BGPT exposes the same scientific-paper search through an MCP tool and a REST endpoint.
POST https://bgpt.pro/api/mcp-search
JSON field | Type | Required | Description |
| string | Yes | Search terms (e.g. "CRISPR gene editing efficiency") |
| integer | No | Number of results to return (1-100, default 10) |
| integer | No | Only return papers published within the last N days |
| string | No | Your Stripe subscription ID for paid access |
search_papers
Parameter | Type | Required | Description |
| string | Yes | Search terms (e.g. "CRISPR gene editing efficiency") |
| integer | No | Number of results to return (1-100, default 10) |
| integer | No | Only return papers published within the last N days |
| string | No | Your Stripe subscription ID for paid access |
Each paper result includes 25+ fields, extracted from the full text:
Title & DOI — standard identifiers
Methods — experimental design, techniques used
Results — raw findings, measurements, statistical outcomes
Conclusions — what the authors determined
Quality scores — methodological rigor assessment
Sample sizes — participant/specimen counts
Limitations — acknowledged weaknesses
And more — funding, conflicts of interest, study type, etc.
Ask your AI assistant:
"Search for recent papers on CAR-T cell therapy response rates"
BGPT returns structured experimental data your AI can reason over — not just a list of titles.
Tier | Cost | Details |
Free | $0 | 50 free results, no API key needed |
Pay-as-you-go | $0.02/result | Billed per result returned. Get an API key at bgpt.pro/mcp |
Your AI Assistant (Claude, Cursor, etc.)
│
│ MCP Protocol (SSE or Streamable HTTP)
▼
BGPT MCP / REST API
https://bgpt.pro/mcp/sse
https://bgpt.pro/mcp/stream
https://bgpt.pro/api/mcp-search
│
│ search_papers(query, ...)
▼
BGPT Paper Database
(full-text extracted data)
│
▼
Structured Results
(methods, results, quality scores, 25+ fields)BGPT is a hosted remote service — your MCP client connects via SSE or Streamable HTTP, or your app calls the REST endpoint directly. No Docker, scraping, or local index required.
Literature reviews — Ask your AI to survey a topic with real experimental data
Python notebooks — Pull recent paper evidence into analysis workflows with one HTTP call
Evidence synthesis — Ground AI responses in actual study findings
Research assistance — Find papers by methodology, outcome, or recency
Fact-checking — Verify claims against published experimental results
Grant writing — Quickly gather supporting evidence for proposals
Field | Value |
Protocol | MCP (Model Context Protocol) |
Transport | SSE (Server-Sent Events) or Streamable HTTP |
SSE Endpoint |
|
Streamable HTTP Endpoint |
|
REST Endpoint |
|
Authentication | None required (free tier) / Stripe API key (paid) |
{
"mcpServers": {
"bgpt": {
"url": "https://bgpt.pro/mcp/sse"
}
}
}From the same author — news/markets bias scoring on one side, structured scientific evidence on the other:
Helium MCP — 37-dimensional news bias scoring, market data, ML options pricing (demo)
helium-mcp-cookbook — runnable Python recipes for Helium's REST surface
BGPT is indexed on several API and MCP directories (helps discovery; links are dofollow where noted):
bio.tools — life-science software registry (biotools:bgpt)
CLIRank — API quality score
Glama MCP — MCP server directory
Postman API Network — runnable collection
Smithery — MCP registry
cursor.directory — Cursor MCP listing
Full documentation, FAQ, and setup guides: bgpt.pro/mcp
OpenAPI spec for the REST endpoint: openapi.yaml
Additional REST discovery assets:
apis.json — machine-readable API discovery metadata
llms.txt — AI-crawler and agent-friendly product context
AGENTS.md — integration guidance for AI agents
USE_CASES.md — RAG, systematic review, notebook, and dashboard use cases
PROMPT_GALLERY.md — ready-to-use prompts for scientific RAG, agents, integrity checks, and visual demos
CITATION.cff and codemeta.json — research-software metadata
examples/bgpt_rest_python.py — Python requests example
examples/bgpt_rest_javascript.mjs — JavaScript fetch example
examples/bgpt_rest_curl.sh — cURL example
examples/bgpt_plotly_evidence_dashboard.py — Plotly evidence dashboard demo
examples/postman_collection.json — importable Postman collection
Email: contact@bgpt.pro
Issues: GitHub Issues
API Key / Billing: bgpt.pro/mcp
See CONTRIBUTING.md for guidelines on reporting bugs, requesting features, and contributing.
This repository (documentation, examples, and configuration files) is licensed under the MIT License.
The BGPT MCP API service itself is operated by BGPT and subject to its own terms of service and Privacy Policy.
Look up a single paper by its DOI.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | The DOI of the paper (e.g. "10.1038/s41586-024-07386-0"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating a safe, idempotent operation. The description adds no extra behavioral context (e.g., response format, authentication) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description fully covers the functionality. The output schema eliminates the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'doi' parameter, including an example. The description ('by its DOI') adds no additional meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('look up') and the resource ('a single paper') using a specific identifier ('DOI'). This directly distinguishes it from the sibling tool 'search_papers', which would be used for broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling tool 'search_papers' is listed, but the description does not contrast or provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BGPT's database of scientific papers by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 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. | |
| days_back | No | Only return papers published within the last N days. | |
| num_results | No | Number of results to return (1-100, default 16). First 50 results are free, then billed at $0.01/result for paid users. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds no behavioral context beyond 'search by keyword,' such as rate limits, pagination behavior, or billing details (which are in param descriptions but not the main description). Minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it is very brief and could be structured to front-load key information like what the tool does, but it does so adequately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, parameter richness, and presence of output schema, the description is sufficiently complete. It covers the core function and leaves return value details to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100%). The description adds valuable usage hints beyond schema: 'Short, concise queries are best. English language only. Don't include years or filters...' This aids correct parameter use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Search), resource (BGPT's database of scientific papers), and method (by keyword). It distinguishes from sibling lookup_paper which is likely a direct lookup by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus lookup_paper. The description implies use for keyword search, but does not state when not to use it or provide alternatives. Usage is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have entirely distinct purposes: lookup_paper retrieves a specific paper by DOI, while search_papers finds papers by keyword. There is no overlap or ambiguity.
Both tool names follow a consistent verb_noun snake_case pattern (lookup_paper, search_papers), making them predictable and readable.
With only two tools, the server feels minimal but not unreasonable for a focused paper retrieval service. However, it's on the thin side for a database named BGPT.
The server provides basic search and retrieval by DOI, covering core read operations. Missing features like author-based search, citation info, or export are notable but not critical for simple use.
Search 8.5M scientific papers with LLM TLDRs, citations, linked entities, figures, and full text.
Science MCP — free science data APIs
Biomedical data: compounds, drug info, and molecular targets
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/connerlambden/bgpt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
