Claude, Cursor 또는 모든 MCP 호환 AI 도구에서 과학 논문을 검색하세요.
BGPT는 원격 Model Context Protocol (MCP) 서버로, AI 어시스턴트가 전체 텍스트 연구를 기반으로 구축된 과학 논문 데이터베이스에 액세스할 수 있도록 합니다. 제목과 초록만 반환하는 일반적인 검색 도구와 달리, BGPT는 원시 실험 데이터(방법, 결과, 결론, 품질 점수, 표본 크기, 한계 및 논문당 25개 이상의 메타데이터 필드)를 추출합니다.
MCP 클라이언트에 BGPT를 추가하세요. 무료 티어(50개 무료 결과)는 API 키가 필요하지 않습니다.
대부분의 최신 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 어시스턴트에게 다음과 같이 질문하세요:
"CAR-T 세포 치료 반응률에 관한 최근 논문을 검색해 줘"
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"
}
}
}전체 문서, 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
