Claude、Cursor、またはその他のMCP互換AIツールから科学論文を検索します。
BGPTは、AIアシスタントがフルテキスト研究から構築された科学論文データベースにアクセスできるようにするリモートModel Context Protocol (MCP) サーバーです。タイトルや要約を返す一般的な検索ツールとは異なり、BGPTは生の実験データ（手法、結果、結論、品質スコア、サンプルサイズ、制限事項、および論文あたり25以上のメタデータフィールド）を抽出します。
MCPクライアントにBGPTを追加します。無料枠（50件の無料検索結果）ではAPIキーは不要です。
ほとんどの最新のMCPクライアントは、直接のリモート接続をサポートしています。BGPTは2つのトランスポートを提供しています：
トランスポート | エンドポイント |
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は1つのツールを提供します：search_papers
パラメータ | 型 | 必須 | 説明 |
| string | はい | 検索語（例：「CRISPR gene editing efficiency」） |
| integer | いいえ | 返す結果の数（1〜100、デフォルトは10） |
| integer | いいえ | 過去N日以内に公開された論文のみを返す |
| string | いいえ | 有料アクセス用のStripeサブスクリプションID |
各論文の結果には、フルテキストから抽出された25以上のフィールドが含まれます：
タイトルとDOI — 標準識別子
手法 — 実験デザイン、使用された技術
結果 — 生の知見、測定値、統計的結果
結論 — 著者が決定したこと
品質スコア — 方法論的厳密さの評価
サンプルサイズ — 参加者/標本数
制限事項 — 認められた弱点
その他 — 資金提供、利益相反、研究タイプなど
AIアシスタントに尋ねてください：
「CAR-T細胞療法の反応率に関する最近の論文を検索して」
BGPTは、単なるタイトルのリストではなく、AIが推論できる構造化された実験データを返します。
ティア | 費用 | 詳細 |
無料 | $0 | 50件の無料結果、APIキー不要 |
従量課金 | $0.02/結果 | 結果ごとに課金。APIキーはbgpt.pro/mcpで取得 |
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"
}
}
}完全なドキュメント、FAQ、セットアップガイド：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
