Skip to main content
Glama
deenesjakoruzh
surendranb

papers-mcp

by surendranb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Scientific Research Papers MCP Server 📄

AI 에이전트를 위한 과학 문헌 기반 MCP 서버: arXiv, PubMed, OpenAlex, CrossRef, Semantic Scholar에서 250M+ 학술 논문을 통합 검색합니다.

CI PyPI version npm version OpenSSF Scorecard License: MIT

🌐 라이브 문서 및 웹 포털: https://papers.builditwithai.xyz

⚡ 빠른 시작

# 1-Line Universal Installer (Auto-configures Claude Desktop, Cursor, Claude Code, Antigravity, VS Code, Zed, Windsurf)
curl -fsSL "https://papers.builditwithai.xyz/install" | bash

# Or run directly via your preferred runtime:
uvx find-research-papers-mcp
npx -y find-research-papers-mcp

Related MCP server: Academic Paper MCP HTTP/SSE Server

🤖 클라이언트 설정

A. Claude Code (CLI)

claude mcp add papers -- uvx find-research-papers-mcp

B. Cursor & Google Antigravity (mcp.json)

{
  "mcpServers": {
    "papers": {
      "command": "uvx",
      "args": ["find-research-papers-mcp"]
    }
  }
}

C. Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "papers": {
      "command": "uvx",
      "args": ["find-research-papers-mcp"]
    }
  }
}

D. VS Code (Cline / Roo Code / Continue)

{
  "mcpServers": {
    "papers": {
      "command": "npx",
      "args": ["-y", "find-research-papers-mcp"]
    }
  }
}

🛠️ 도구 및 기능

도구 이름

매개변수

설명

반환 유형

search_papers

query (string), sources (list), limit (int)

arXiv, PubMed, OpenAlex, CrossRef, Semantic Scholar에 걸친 통합 다중 인덱스 검색.

JSON / Markdown

get_paper

doi (string) or id (string)

논문 메타데이터, 초록, 저자, 발행일, 오픈 액세스 PDF 링크를 검색합니다.

JSON

get_references

doi (string)

CrossRef를 통해 전체 참고문헌과 참조 논문을 가져옵니다.

JSON

get_citations

doi (string)

OpenAlex를 통해 인용 논문과 인용 그래프를 가져옵니다.

JSON

verify_paper

doi (string)

HEAD 요청으로 랜딩 페이지 접근성을 확인하고 철회 데이터베이스를 교차 검증합니다.

JSON

list_sources

(없음)

5개 학술 인덱스 모두의 실시간 상태 및 지연 시간 메트릭을 반환합니다.

JSON

skill_read

skill_name (string)

GitHub에서 연구 방법론 스킬을 동적으로 로드합니다.

Markdown

skills_list

(없음)

사용 가능한 모든 과학 연구 스킬을 나열합니다.

JSON

🔒 텔레메트리 및 개인정보 보호

이 패키지는 도구 안정성을 개선하기 위해 익명의 비-PII 진단 텔레메트리(명령 실행, 지연 시간, 오류 코드)를 수집합니다. 연구 쿼리, 논문 결과, 개인 데이터, 소스 코드 또는 환경 변수는 절대 수집되거나 저장되지 않습니다.

언제든지 다음 환경 변수 중 하나를 설정하여 옵트아웃할 수 있습니다:

export DO_NOT_TRACK=1
# or
export MCP_TELEMETRY_OPT_OUT=1

📄 라이선스

MIT 라이선스. 자세한 내용은 LICENSE를 참조하세요.

Available Tools

3 tools
get_paperGet paper details, references and citationsA

Resolve one paper by identifier and return its metadata plus references (papers it cites) and citations (papers citing it) — works even for paywalled papers

ParametersJSON Schema
NameRequiredDescriptionDefault
id_typeNoauto
identifierYes
include_citationsNo
include_referencesNo

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions working for paywalled papers (useful) and the return contents, but does not disclose error behavior, rate limits, or authentication needs. It implies a read-only operation but does not state side effects.

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 a single well-structured sentence that is front-loaded with the core purpose and includes a useful qualifier (paywalled). No wasted words.

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

Completeness3/5

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

While the description clarifies the main return values and a notable capability, the tool has 4 parameters with no schema descriptions and no output schema. Missing details about id_type, how citations/references are formatted, and error handling make the description incomplete for fully understanding the tool's behavior.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It mentions 'references' and 'citations' but does not map them to the include_references and include_citations parameters, nor does it explain the id_type parameter or identifier formats. The schema has titles and defaults, but the description adds little meaning beyond hinting at the main identifier.

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 clearly states the verb 'Resolve' and the resource 'one paper by identifier', listing the return contents (metadata, references, citations). This distinguishes it from siblings like search_papers (which discovers papers) and list_sources (which lists sources).

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 implies usage when you have a specific paper identifier and need its details and citation network. It highlights that it works for paywalled papers, which is a practical consideration, but it does not explicitly contrast with search_papers or list_sources.

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

list_sourcesList paper sourcesA

List every scholarly source the server can search, with coverage, key requirements, and rate limits

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions that the output includes coverage, key requirements, and rate limits, which gives the agent useful context about limitations and prerequisites. It does not contradict any annotations since none exist.

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 a single, front-loaded sentence that states the action and key output details. Every word contributes value, with no filler or repetition.

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?

For a zero-parameter listing tool with an output schema present, the description is complete. It clearly indicates what the tool returns (sources with coverage, requirements, and rate limits) and differentiates from sibling tools. No additional context is necessary for a task of this simplicity.

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

Parameters4/5

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

The tool has zero parameters, so the schema is trivially complete. Per the rubric, zero params warrant a baseline score of 4. The description adds no parameter-specific meaning, but none is needed.

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 clearly states the tool's purpose with a specific verb ('List'), resource ('scholarly sources'), and scope ('the server can search'). It also specifies the included details (coverage, key requirements, rate limits), which distinguishes it from sibling tools like search_papers and get_paper.

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 provides clear context for when to use the tool: to discover the scholarly sources available for searching. It implies usage before searching or to understand source capabilities. It doesn't explicitly name alternatives or exclusions, but the listing nature is self-evident and distinguishable from the search and get siblings.

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

search_papersSearch research papersC

Search scholarly literature across multiple sources (arXiv, OpenAlex, Crossref, Semantic Scholar, PubMed)

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNorelevance
limitNo
queryYes
sourcesNo
year_toNo
year_fromNo
open_access_onlyNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must carry the behavioral disclosure burden, but it only states that the tool searches across multiple sources. It does not reveal rate limits, authentication needs, result aggregation behavior, or whether it is read-only.

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

Conciseness4/5

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

The description is a single, efficient sentence with no wasted words. It lists specific sources, making it moderately informative while staying concise, though it could have spent more space on parameter semantics.

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

Completeness2/5

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

Given the tool's complexity (7 parameters, no output schema, no annotations), the description is insufficient. It provides no information about return format, query syntax, filtering behavior, or how to effectively use the tool.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain any parameters beyond the vague hint of 'multiple sources.' No details are given for sort, limit, year_from, year_to, open_access_only, or how the sources parameter works.

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 uses a specific verb ('Search') and resource ('scholarly literature') and names five concrete sources (arXiv, OpenAlex, Crossref, Semantic Scholar, PubMed), clearly distinguishing this search tool from sibling tools like get_paper and list_sources.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, scenarios, or prerequisites, leaving the agent to infer appropriate usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget_paper
    • First observedlist_sources
    • First observedsearch_papers
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search_papers discovers papers, get_paper retrieves a specific paper's details by identifier, and list_sources provides source configuration. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase snake_case: search_papers, get_paper, list_sources. The pattern is uniform and predictable.

Tool Count5/5

Three tools is exactly appropriate for a focused scholarly search server. It covers the core operations (search, retrieval) plus a useful supporting tool (list_sources) without unnecessary bloat.

Completeness5/5

The tool set provides a complete lifecycle for scholarly paper discovery: search across sources, retrieve detailed metadata with references/citations, and discover what sources are available. There are no obvious missing operations for the stated purpose.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Academic Paper MCP HTTP/SSE

    pastchais
    A
    license
    Not graded
    quality
    D
    maintenance
    A MCP server for academic literature retrieval, aggregating multiple data sources like arXiv, Crossref, OpenAlex, PubMed, and Semantic Scholar to provide search, details, citations, trends, and recommendations.
    4
    MIT

  • scholar-mcp

    pvliesdonk
    A
    license
    A
    quality
    A
    maintenance
    A FastMCP server for the scholarly citation landscape that enables LLMs to search, cross-reference, and retrieve prior art across papers, patents, books, and standards via multiple APIs.
    21
    114 PyPI
    2
    MIT

  • Scholar MCP Server

    mlintangmz2765
    A
    license
    A
    quality
    C
    maintenance
    Unified MCP server for scientific literature search and extraction, integrating databases like Scopus, OpenAlex, Semantic Scholar, and Unpaywall to enable AI agents to discover papers, track citations, and analyze content.
    27
    MIT