从 Claude、Cursor 或任何支持 MCP 的 AI 工具中搜索科学论文。
BGPT 是一个远程 Model Context Protocol (MCP) 服务器，它使 AI 助手能够访问基于全文研究构建的科学论文数据库。与返回标题和摘要的典型搜索工具不同，BGPT 提取的是原始实验数据——包括方法、结果、结论、质量评分、样本量、局限性以及每篇论文 25 个以上的元数据字段。
将 BGPT 添加到您的 MCP 客户端中——免费层级无需 API 密钥（提供 50 条免费结果）。
大多数现代 MCP 客户端都支持直接远程连接。BGPT 提供两种传输方式：
传输方式 | 端点 |
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 — 相同配置：
{
"mcpServers": {
"bgpt": {
"url": "https://bgpt.pro/mcp/sse"
}
}
}提示： 如果您的客户端支持 Streamable HTTP，您可以使用
https://bgpt.pro/mcp/stream代替。
{
"mcpServers": {
"bgpt": {
"command": "npx",
"args": ["-y", "bgpt-mcp"]
}
}
}npm install -g bgpt-mcp然后添加到您的 MCP 配置中：
{
"mcpServers": {
"bgpt": {
"command": "bgpt-mcp"
}
}
}连接到任一端点：
SSE: https://bgpt.pro/mcp/sse
Streamable HTTP: https://bgpt.pro/mcp/stream就是这样。无需 Docker，无需构建步骤。
Related MCP server: mcp-spacefrontiers
BGPT 提供一个工具：search_papers
参数 | 类型 | 必需 | 描述 |
| string | 是 | 搜索词（例如 "CRISPR gene editing efficiency"） |
| integer | 否 | 返回的结果数量（1–100，默认 10） |
| integer | 否 | 仅返回过去 N 天内发表的论文 |
| string | 否 | 用于付费访问的 Stripe 订阅 ID |
每篇论文结果包含从全文中提取的 25 个以上字段：
标题和 DOI — 标准标识符
方法 — 实验设计、所用技术
结果 — 原始发现、测量数据、统计结果
结论 — 作者的结论
质量评分 — 方法论严谨性评估
样本量 — 参与者/样本数量
局限性 — 已知的弱点
更多 — 资助情况、利益冲突、研究类型等
询问您的 AI 助手：
"Search for recent papers on CAR-T cell therapy response rates"
BGPT 返回结构化的实验数据，供您的 AI 进行推理，而不仅仅是标题列表。
层级 | 费用 | 详情 |
免费 | $0 | 50 条免费结果，无需 API 密钥 |
按量付费 | $0.02/结果 | 按返回的结果计费。在 bgpt.pro/mcp 获取 API 密钥 |
Your AI Assistant (Claude, Cursor, etc.)
│
│ MCP Protocol (SSE or Streamable HTTP)
▼
BGPT MCP Server
https://bgpt.pro/mcp/sse
https://bgpt.pro/mcp/stream
│
│ search_papers(query, ...)
▼
BGPT Paper Database
(full-text extracted data)
│
▼
Structured Results
(methods, results, quality scores, 25+ fields)BGPT 是一个托管的远程服务器——您的 MCP 客户端通过 SSE 或 Streamable HTTP 连接。无需本地安装。
文献综述 — 让您的 AI 使用真实的实验数据调研主题
证据综合 — 将 AI 的回答建立在实际研究发现的基础上
研究辅助 — 按方法论、结果或时效性查找论文
事实核查 — 根据已发表的实验结果验证声明
基金申请 — 快速收集提案的支持证据
字段 | 值 |
协议 | MCP (Model Context Protocol) |
传输方式 | SSE (Server-Sent Events) 或 Streamable HTTP |
SSE 端点 |
|
Streamable HTTP 端点 |
|
身份验证 | 无需（免费层级）/ Stripe API 密钥（付费） |
{
"mcpServers": {
"bgpt": {
"url": "https://bgpt.pro/mcp/sse"
}
}
}完整文档、常见问题解答和设置指南：bgpt.pro/mcp
电子邮件： contact@bgpt.pro
问题反馈： GitHub Issues
API 密钥 / 账单： bgpt.pro/mcp
请参阅 CONTRIBUTING.md 以了解有关报告错误、请求功能和贡献的指南。
本仓库（文档、示例和配置文件）采用 MIT 许可证授权。
BGPT MCP API 服务本身由 BGPT 运营，并受其自身的 服务条款 约束。
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
