本地学术论文工具 MCP 服务器 —— 9源搜索、多源下载、AI 辅助分析、引文图谱、基于代码的论文推荐。
pip install scholar-mcp-server[all]
scholar-mcp-install --all安装完成。重启你的 IDE 即可开始使用。
Related MCP server: Paper Distill MCP Server
工具 | 描述 |
| 9源并发搜索并进行相关性评分（Semantic Scholar, OpenAlex, Crossref, PubMed, arXiv, CORE, Europe PMC, DOAJ, dblp） |
| 多源 PDF 下载：Unpaywall → 出版商 OA → arXiv → Sci-Hub → scidownl |
| 通过 DOI 列表批量下载多篇论文 |
| AI 分析 —— 下载 PDF，提取全文（最多 20 页 / 1.2 万字符），发送至任何兼容 OpenAI 的 API |
| 扫描你的工作区代码 → 多查询自动推荐相关论文 |
| 生成 Mermaid 引文/参考文献网络可视化图 |
| 检查下载源可用性 |
搜索结果通过 4 因子综合评分进行排序：
因子 | 权重 | 描述 |
查询相关性 | 0–40 | 标题 + 摘要词汇匹配 |
引文影响力 | 0–30 | 对数缩放的引文计数 |
来源质量 | 0–10 | 数据源可靠性加权 |
年份时效性 | 0–15 | 近期发表论文加分 |
去重过程在所有 9 个源中使用 DOI 匹配 + Jaccard 标题相似度（阈值 ≥0.7）。每个源连接器都内置了带指数退避的重试机制。
paper_ai_analyze 适用于任何兼容 OpenAI 的 API。设置 AI_API_BASE、AI_API_KEY 和 AI_MODEL 以指向你偏好的提供商。
git clone https://github.com/45645678a/Scholar-mcp.git
cd Scholar-mcp
pip install -r requirements.txt
python install.py --all变量 | 描述 | 必需 |
| AI 分析的 API 密钥 |
|
| API 基础 URL（任何兼容 OpenAI 的端点） | 可选（默认： |
| 模型名称 | 可选（默认： |
| Unpaywall API 的邮箱 | 可选 |
Antigravity (Gemini)
Cursor
Windsurf
Claude Code / Claude Desktop
VS Code (Copilot)
全部免费，无需 API 密钥：
来源 | 覆盖范围 |
Semantic Scholar | 广泛学术（主要） |
OpenAlex | 2.5 亿+ 文献，全球 |
Crossref | DOI 元数据 |
PubMed | 生物医学 |
arXiv | 物理、计算机、数学 |
CORE | 开放获取聚合器 |
Europe PMC | 欧洲生物医学 |
DOAJ | 开放获取期刊 |
dblp | 计算机科学 |
pip install .[all] pytest
pytest tests/ -v包含 40 个测试用例，涵盖搜索去重、下载链、关键词提取和连接器模拟。
本工具包含可选的 Sci-Hub 集成，仅供个人学术使用。在某些司法管辖区，Sci-Hub 可能属于非法。用户需自行负责确保符合当地法律和机构政策。 作者不认可任何侵犯版权的行为。如果你处于合规敏感环境（大学、公司、实验室），请在使用 Sci-Hub 下载源之前咨询你所在机构的政策。
MIT
使用 AI 分析论文，返回核心贡献、研究方法、关键发现等。
支持任意 OpenAI 兼容 API（通过 AI_API_BASE / AI_API_KEY / AI_MODEL 环境变量配置）。 如果能下载到 PDF，会提取全文进行深度分析；否则退回到 abstract 分析。
Args: doi: 论文的 DOI，例如 "10.1109/tim.2021.3106677"
Returns: AI 分析结果 JSON
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses critical behavioral traits: external API dependency (via env vars), the conditional PDF download attempt with abstract fallback, and JSON output format. However, it omits other behavioral details like timeout behavior, API cost implications, or caching policies.
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 well-structured with clear sections (functionality, environment setup, fallback logic, Args/Returns). The Args/Returns sections are necessary given the schema's lack of descriptions, though they echo structural fields. Every sentence conveys essential information without redundancy.
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 has an output schema (covering return structure) and only one input parameter, the description is sufficiently complete for its complexity level. It covers the essential external dependency setup and conditional behavior (PDF fallback) needed for an agent to understand operational requirements.
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?
With 0% schema description coverage, the description fully compensates by documenting the single parameter: it explains 'doi' represents the paper's DOI and provides a concrete example ('10.1109/tim.2021.3106677'), which aids the LLM in generating correct invocations.
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 tool uses AI to analyze papers and specific outputs expected (core contributions, methods, findings). It implicitly distinguishes from siblings like `paper_download` (which merely fetches files) and `paper_search` (which finds papers) by emphasizing AI-driven content analysis, though it could explicitly contrast with these alternatives.
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?
The description provides implicit guidance by noting it requires OpenAI-compatible API environment variables and explaining the fallback behavior (PDF full-text vs abstract). However, it lacks explicit guidance on when to choose this over `paper_download` or whether users should prefer manual download for large batches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量下载多篇论文 PDF。
Args: dois: DOI 列表，例如 ["10.1109/tim.2021.3106677", "10.1109/tie.2020.3032868"] output_dir: 保存 PDF 的目录路径，默认为当前目录
Returns: 批量下载结果的 JSON 字符串，包含每篇的状态和汇总统计
| Name | Required | Description | Default |
|---|---|---|---|
| dois | Yes | ||
| output_dir | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the return format (JSON string with status and statistics) and file output behavior (PDF), but omits critical safety information like whether existing files are overwritten or error handling behavior.
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?
Uses a clear docstring structure (Args/Returns) that frontloads the purpose statement and organizes supplementary information efficiently. The Chinese text is appropriately concise with zero redundant sentences.
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 2-parameter tool with simple primitives, the description adequately covers inputs and acknowledges the output schema (JSON result). It appropriately delegates detailed return structure documentation to the output schema itself.
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?
Given 0% schema description coverage, the description compensates effectively: it explains 'dois' is a list with concrete examples, and clarifies 'output_dir' is a directory path with default value (current directory). It could improve by detailing DOI format validation.
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 opens with a specific action verb (批量下载/batch download) and clear resource (多篇论文 PDF/multiple paper PDFs), immediately distinguishing it from the singular 'paper_download' sibling tool through the emphasis on batch processing.
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?
While the Args section implies usage through the plural 'dois' parameter and_examples, there is no explicit guidance on when to choose this over 'paper_download' (singular) or prerequisites like valid DOI format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成论文引用图谱（Mermaid 可视化 + 结构化数据）。
通过 Semantic Scholar API 获取论文的引用(citations)和参考文献(references)， 输出 Mermaid 图谱代码（可直接在 Markdown 中渲染）和结构化 JSON。
Args: doi: 论文的 DOI，例如 "10.1109/tim.2021.3106677" depth: 递归深度 (1=直接引用/参考, 2=二层引用)，默认 1 max_per_level: 每层最多获取的论文数，默认 10
Returns: 引用图谱 JSON，包含 mermaid (图谱代码), nodes, edges, statistics 等
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | ||
| depth | No | ||
| max_per_level | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses data source (Semantic Scholar API), recursive fetching behavior (depth levels explained), output format (Mermaid + JSON), and rate-limiting hints via max_per_level. Missing explicit error behavior or auth requirements.
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?
Clear Args/Returns structure with logical flow. Chinese text is appropriately concise; no redundant sentences. Minor deduction for Returns section listing output fields that may duplicate output schema details, though helpful given context.
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 complex graph-generation tool with zero schema coverage, description adequately covers inputs, data source, and output structure (nodes/edges/statistics). Sufficient since output schema exists to handle return value specifics.
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?
With 0% schema description coverage, the description fully compensates by documenting all 3 parameters: doi with example syntax, depth with semantic meanings (1=direct, 2=secondary), and max_per_level with clear quantity semantics.
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 uses specific verb '生成' (generates) + resource '论文引用图谱' (paper citation graph) and explicitly distinguishes from siblings via the Mermaid visualization and Semantic Scholar API sourcing—unique traits not shared with paper_search or paper_download.
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?
Implies usage through functional description (use when needing citation visualization), but lacks explicit 'when to use vs alternatives' guidance comparing to siblings like paper_ai_analyze or paper_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过 DOI 下载一篇论文 PDF（本地多源下载：Unpaywall → arXiv → Sci-Hub）。
Args: doi: 论文的 DOI，例如 "10.1109/tim.2021.3106677" output_dir: 保存 PDF 的目录路径，默认为当前目录
Returns: 下载结果的 JSON 字符串，包含 success, doi, path, size_mb, source 等字段
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | ||
| output_dir | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries significant burden by disclosing the source priority chain (Unpaywall → arXiv → Sci-Hub) and return JSON structure (success, path, size_mb, source). However, it omits rate limiting behavior, network failure handling, and explicit confirmation that files are written to disk (though implied by '保存 PDF').
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 Args/Returns structure is logical and scannable. The essential information (action + source chain) appears in the first sentence. Minor deduction for including return field documentation when an output schema exists, though this redundancy aids readability given the tool's critical file-I/O nature.
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 moderate complexity (2 parameters, file I/O) and absence of annotations, the description adequately covers inputs, outputs, and sourcing behavior. The presence of an output schema reduces the burden to describe return values, yet it provides this detail anyway.
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?
Despite 0% schema description coverage (schema only contains titles), the description fully compensates by providing semantic meaning for both parameters: doi includes a concrete example ('10.1109/tim.2021.3106677'), and output_dir explains the purpose ('保存 PDF 的目录路径') and default behavior.
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 specific action (download PDF via DOI), resource type (academic paper), and unique mechanism (multi-source fallback chain: Unpaywall → arXiv → Sci-Hub). This specificity naturally distinguishes it from siblings like paper_batch_download (single vs. multiple) and paper_search (retrieval vs. discovery).
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?
While the description implies single-paper usage through the singular '一篇论文' (a paper) and specific DOI parameter, it lacks explicit guidance on when to prefer paper_batch_download for multiple papers or prerequisites like needing a valid DOI upfront. Usage is inferred but not expressly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查论文下载服务各数据源的可用性（Unpaywall、arXiv、Sci-Hub 镜像）。
Returns: 各数据源健康状态的 JSON 字符串
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It specifies the return value format ('JSON string of health status') and the external dependencies checked, but omits behavioral traits like whether results are cached, if the check makes live HTTP requests, rate limiting, or safety properties (read-only nature).
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 appropriately sized with two distinct sections: the purpose statement naming specific data sources, and a clear 'Returns' declaration. Every sentence earns its place with zero redundancy or tautology.
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 zero-parameter simplicity and existence of an output schema (per context signals), the description is reasonably complete: it identifies the scope (which specific sources are checked) and return format. Minor gaps remain regarding error handling semantics and cache duration, but sufficient for a utility health endpoint.
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 tool has zero parameters and schema coverage is 100% (trivially). Per the rubric, zero parameters warrants a baseline score of 4. The description correctly focuses on behavior rather than inventing parameter documentation.
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 uses a specific verb ('检查/check') with specific resources ('论文下载服务各数据源的可用性/availability of paper download service data sources'), explicitly listing the monitored sources (Unpaywall, arXiv, Sci-Hub mirrors). This clearly distinguishes it from sibling tools like paper_download or paper_search which perform operations on papers rather than checking service health.
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?
While the purpose is clear, there is no explicit guidance on when to use this tool versus alternatives (e.g., 'call before batch downloads to verify availability'). The usage is implied by the health-check nature, but lacks explicit when/when-not recommendations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析工作区代码，自动推荐相关学术论文。
扫描指定目录下的源文件（.py, .tex, .md 等），提取 import 库名、算法术语、 LaTeX 标题等特征，映射到学术领域关键词后搜索论文推荐。
Args: workspace_path: 工作区根目录路径，例如 "E:/半导体实验" top_n: 返回推荐论文数量，默认 8
Returns: 推荐结果 JSON，包含检测到的库/术语、搜索查询和推荐论文列表
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_path | Yes | ||
| top_n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It successfully explains the internal pipeline (file scanning → feature extraction → keyword mapping → search) and output structure (JSON with detected libraries/terms, queries, paper list). It lacks explicit read-only confirmation or side-effect warnings, though 'analyze' and 'scan' imply non-destructive behavior.
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?
Excellent structure with three distinct sections: main purpose (2 sentences), Args documentation, and Returns documentation. No redundancy; every sentence contributes to understanding the tool's function, parameters, or output format.
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 complexity (multi-stage feature extraction across file types) and 0% schema coverage, the description provides sufficient context: it explains the extraction targets (import libraries, algorithm terms, LaTeX titles), documents both parameters, and summarizes the output JSON structure without needing to repeat the full 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 description coverage is 0%, so the description fully compensates. The Args section documents workspace_path with a concrete example ('E:/半导体实验') and top_n with its default value (8), providing complete semantic meaning for both parameters that the schema lacks.
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 tool '分析工作区代码，自动推荐相关学术论文' (analyzes workspace code, automatically recommends academic papers) with specific mechanism details (scanning .py/.tex/.md, extracting imports/terms). It distinguishes from siblings like paper_search (manual query) and paper_download (specific paper retrieval) by emphasizing the code-driven feature extraction workflow.
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?
The implicit usage context is clear from the detailed mechanism description—use this when you have a codebase to analyze for paper recommendations. However, it lacks explicit when-not-to-use guidance or direct comparison statements like 'use paper_search instead for manual keyword queries'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索论文 (Crossref + Semantic Scholar 双源合并去重)。
支持关键词搜索或直接输入 DOI 查询详情。
Args: query: 搜索关键词或 DOI，例如 "gradient magnetic field coil" 或 "10.1109/tim.2021.3106677" rows: 返回结果数量，默认 8
Returns: 搜索结果 JSON，包含 title, authors, journal, year, doi, cited_by, abstract 等
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| rows | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
披露了两源合并去重的行为特性，并详细说明了返回JSON的结构（包含title, authors, journal等字段）。由于无注解，描述承担了完整的行为说明责任，但未提及错误处理、认证需求或速率限制。
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?
采用标准docstring结构，分行为说明（双源搜索）、参数(Args)和返回值(Returns)三部分，中文表述简洁，每句都提供有价值信息，无冗余。
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?
鉴于无注解且Schema描述覆盖率0%，描述已相当完整：涵盖两个参数语义、双源去重行为、返回JSON结构。但因未提及错误处理情形、速率限制或与兄弟工具的明确区分，略有不足。
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描述覆盖率为0%，但描述通过Args部分完美补偿：详细说明query参数接受关键词或DOI并提供具体示例（'gradient magnetic field coil'或'10.1109/tim...'），rows参数说明为返回结果数量且默认值为8。
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?
描述明确说明'搜索论文'并使用Crossref + Semantic Scholar双源合并去重，提供了具体动词和资源。但并未明确区分与paper_recommend等兄弟工具的差异。
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?
说明了支持关键词搜索或DOI查询两种模式（支持...或...），但未提供何时使用此工具而非paper_recommend或paper_citation_graph的指导，也未说明使用限制或前置条件。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0paper_ai_analyzepaper_batch_downloadpaper_citation_graphpaper_downloadpaper_healthpaper_recommendpaper_searchScored across 7 tools
Most tools have distinct purposes with clear boundaries: paper_ai_analyze focuses on AI analysis, paper_citation_graph on citation visualization, paper_recommend on workspace-based recommendations, and paper_health on service monitoring. However, paper_download and paper_batch_download overlap significantly in functionality, with the batch version essentially being a multi-DOI extension of the single download tool, which could cause confusion about when to use each.
All tools follow a consistent 'paper_' prefix with descriptive snake_case naming that clearly indicates their function. The pattern is uniform across all seven tools, making them predictable and easy to understand at a glance. No mixing of naming conventions or inconsistent verb styles is present.
With 7 tools, this server is well-scoped for academic paper management and analysis. Each tool serves a distinct role in the workflow: searching, downloading, analyzing, visualizing citations, checking service health, and generating recommendations. The count is appropriate for the domain without being overwhelming or insufficient.
The toolset covers most core academic paper workflows comprehensively: search, download (single and batch), analysis, citation visualization, and recommendation. A minor gap exists in update/management operations (e.g., organizing downloaded papers, managing collections, or tracking reading status), but agents can work effectively with the provided tools for typical research tasks.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
