This server enables multi-source academic literature retrieval and analysis via the MCP protocol, aggregating data from Europe PMC, PubMed, arXiv, CrossRef, OpenAlex, and EasyScholar.
Search Literature: Search for academic papers using keywords with four strategies:
comprehensive – all available sources
fast – major sources only (Europe PMC, PubMed)
precise – authoritative sources with result intersection
preprint – arXiv preprints
Returns metadata (title, authors, abstract, PMCID, DOI, etc.) with 24-hour caching.
Retrieve Full Text: Fetch full-text articles by PMCID (single or batch, up to 20). Supports multiple formats (Markdown, XML, plain text) and selective section extraction (e.g., methods, results, discussion).
Retrieve References: Get the reference list of an article identified by DOI, PMID, or PMCID, with smart deduplication and optional detailed metadata, across multiple data sources.
Analyze Literature Relations: Explore citation relationships between articles—including cited references, similar articles, and citing papers—via single, batch, or network analysis modes with configurable depth.
Assess Journal Quality: Evaluate journals using:
EasyScholar metrics: impact factor, SCI quartile (Q1–Q4), JCI index, CAS zone
OpenAlex metrics: h-index, citation rate, total citations, i10-index
Supports batch queries and gracefully falls back to OpenAlex if EasyScholar is unavailable.
Server Info & Cache Management: Access server version, status, supported sources, available tools, and view cache statistics for searches and journal quality data.
Configuration: Supports environment variables for API keys (e.g., EASYSCHOLAR_SECRET_KEY) and language settings (English or Chinese tool descriptions).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@article-mcp find recent papers on CRISPR gene editing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
基于 Model Context Protocol (MCP) 的学术文献检索服务器。帮助 LLM 搜索、获取和分析多数据源学术文献。
主要用途：面向学术文献与科研论文检索分析，尤其适合医学、生命科学和跨学科科研场景；同时支持 arXiv 等通用科研预印本来源。
适用于需要 LLM 进行以下操作的场景：
学术写作辅助 — 查找最新研究文献作为引用来源
文献综述 — 跨多个学术数据库检索和分析文献
期刊质量评估 — 评估目标期刊的学术影响力（影响因子、分区等）
文献关系分析 — 构建引用网络、发现相似文献
支持 6 个学术数据源：Europe PMC、PubMed、arXiv、CrossRef、OpenAlex、Semantic Scholar。
注意: 本工具返回文献元数据（标题、作者、摘要、PMCID、DOI 等）。全文获取需通过
get_article_details工具，且仅限 PMC 开放获取文章。
Related MCP server: paper-search
系统要求: Node.js 18+
# 直接运行（推荐，自动获取最新版本）
npx article-mcp@latest
# 或全局安装
npm install -g article-mcp
article-mcp{
"mcpServers": {
"article-mcp": {
"command": "npx",
"args": ["article-mcp@latest"],
"env": {
"OPENALEX_API_KEY": "your_openalex_key_here",
"EASYSCHOLAR_SECRET_KEY": "your_easyscholar_key_here"
}
}
}
}在 .vscode/mcp.json 中添加：
{
"servers": {
"article-mcp": {
"type": "stdio",
"command": "npx",
"args": ["article-mcp@latest"],
"env": {
"OPENALEX_API_KEY": "your_openalex_key_here",
"EASYSCHOLAR_SECRET_KEY": "your_easyscholar_key_here"
}
}
}
}Windows 用户: 如果遇到
npx无法识别的问题，将"command"改为"cmd"，"args"改为["/c", "npx", "article-mcp@latest"]。
功能 | 工具 | 说明 |
🔍 多源文献搜索 |
| 跨 5 个数据源并行搜索，支持 4 种搜索策略，自动去重排序 |
📄 文献全文获取 |
| 通过 PMCID 获取 PMC 全文（Markdown/XML/Text），支持批量 20 篇 |
📚 参考文献获取 |
| 多源获取参考文献列表，智能 DOI/标题去重，源优先级排序 |
🔗 文献关系分析 |
| 引用网络、施引文献、相似文献，支持可选 Semantic Scholar 施引上下文 |
📊 期刊质量评估 |
| 影响因子、JCR 分区、JCI、中科院分区、h 指数等，双数据源互补 |
search_literature — 文献搜索查找文献并获取 PMCID（不含全文）。如需全文，用返回的 PMCID 调用 get_article_details。
参数 | 类型 | 默认值 | 说明 |
| string | 必填 | 搜索关键词 |
| enum |
| 搜索策略： |
| string[] | 按策略选择 | 数据源： |
| integer |
| 每个源的最大结果数，范围 1-100 |
| boolean |
| 是否使用 24 小时文件缓存 |
get_article_details — 文献全文通过 PMCID 获取全文内容。仅支持 PMC 开放获取文章。
返回说明：fulltext.content 返回所选格式的完整正文；fulltext.preview 是用于快速浏览的 1200 字符预览；fulltext.preview_truncated 标识预览是否被截断；fulltext.content_length 标识完整正文长度。
参数 | 类型 | 默认值 | 说明 |
| string | string[] | 必填 | PMCID 标识符，批量最多 20 个 |
| enum |
| 全文格式： |
| string | string[] | null |
|
|
get_references — 参考文献获取某文献引用的参考文献列表。
参数 | 类型 | 默认值 | 说明 |
| string | 必填 | DOI、PMID 或 PMCID |
| enum |
| 标识符类型： |
| integer |
| 最大参考文献数量，范围 1-100 |
| string[] |
| 数据源 |
| boolean |
| 是否包含详细元数据 |
get_literature_relations — 文献关系分析分析文献间的引用关系、施引文献和相似文献。
施引说明：citing 默认同时尝试 OpenAlex 与 Europe PMC；如果显式传入 sources，则只使用其中支持施引的 openalex/europe_pmc/semantic_scholar。OpenAlex 路径需要 OPENALEX_API_KEY；Semantic Scholar 依赖 PMID，配置 SEMANTIC_SCHOLAR_API_KEY 后更稳定。
参数 | 类型 | 默认值 | 说明 |
| string | string[] |
| DOI、PMID 或 PMCID |
| enum |
| 标识符类型 |
| enum[] |
| 关系类型 |
| integer |
| 每种关系最大结果数，范围 1-100 |
| enum |
|
|
| integer |
| 网络分析展开深度，范围 1-3 |
get_journal_quality — 期刊质量评估集成 EasyScholar + OpenAlex 双数据源。
失败说明：当 EasyScholar 与 OpenAlex 都无法返回任何可用指标时，工具会返回 isError: true 和明确错误信息，而不是成功返回空指标。
参数 | 类型 | 默认值 | 说明 |
| string | string[] | 必填 | 期刊名称 |
| string | string[] | null |
| 返回指标： |
| enum | null |
| 排序字段（批量查询）： |
| enum |
|
|
| boolean |
| 是否使用 24 小时文件缓存 |
变量 | 必需 | 获取地址/配置作用 | 缺失后果 |
| OpenAlex 相关能力需要 | OpenAlex account，用于 OpenAlex 搜索、施引和期刊指标 | OpenAlex 源失败；施引仍可通过 Europe PMC 或显式 Semantic Scholar 降级 |
| 期刊影响因子/分区需要 | 期刊质量只尝试 OpenAlex 指标，影响因子/分区可能为空 | |
| 推荐 | NCBI E-utilities 联系邮箱 | 仍可请求，但不利于 NCBI 联系和合规使用 |
| 可选 | PubMed/PMC 速率按 3 req/s 保守限制 | |
| 推荐 | Crossref Polite Pool 联系邮箱 | 仍可请求，但不会进入 Polite Pool |
| 推荐 | 施引上下文请求更容易受限 | |
| 可选 | OpenAlex 请求间隔覆盖值，默认 100ms | 使用默认限流 |
| 可选 | Crossref 请求间隔覆盖值，默认 100ms | 使用默认限流 |
| 可选 | Semantic Scholar 请求间隔覆盖值，默认 1000ms | 使用默认限流 |
| 可选 | arXiv 请求间隔覆盖值，默认 3000ms | 使用默认限流 |
| 可选 | Europe PMC 请求间隔覆盖值，默认 1000ms | 使用默认限流 |
| 可选 | NCBI 请求间隔覆盖值；未设置时有 key 默认 100ms，无 key 默认 333ms | 使用自动限流 |
| 可选 | 工具说明语言： | 使用中文工具说明 |
用户: 搜索 CRISPR 基因编辑的最新文献
LLM: 调用 search_literature(keyword="CRISPR gene editing", search_type="fast")
→ 返回 10 条结果的元数据（标题、作者、PMCID、摘要等）
用户: 获取第一篇文献的全文
LLM: 调用 get_article_details(pmcid="PMC1234567")
→ 返回全文内容（Markdown 格式）用户: 查看 Nature 的影响因子
LLM: 调用 get_journal_quality(journal_name="Nature")
→ 返回 impact_factor、quartile、jci 等指标用户: 比较 Nature、Science、Cell 的质量指标
LLM: 调用 get_journal_quality(
journal_name=["Nature", "Science", "Cell"],
sort_by="impact_factor"
)
→ 按影响因子降序返回三本期刊的指标数据源 | 搜索 | 详情 | 全文 | 参考文献 | 施引文献 | 相似文献 |
Europe PMC | ✅ | ✅ | — | ✅ | ✅ | — |
PubMed | ✅ | ✅ | ✅ | ✅ | — | ✅ |
arXiv | ✅ | — | — | — | — | — |
Crossref | ✅ | ✅ | — | ✅ | — | — |
OpenAlex | ✅ | ✅ | — | — | ✅ | — |
Semantic Scholar | — | — | — | — | ✅ | — |
Semantic Scholar 仅作为施引来源暴露，可通过
get_literature_relations的sources: ["semantic_scholar"]显式启用。
structuredContent 使用统一的 { success, data, meta, warnings, error } 结构
content 首段为可读摘要和关键摘录，次段为同一结构化结果的 JSON 备份 以兼容旧 MCP 客户端
服务器只注册 Tools，不注册 Resources 或 Prompts，确保最大客户端兼容性
使用 MCP Inspector 检查和调试工具调用：
# 启动 Inspector
npx @modelcontextprotocol/inspector node dist/index.js日志输出到 stderr（不污染 stdout 协议通道）。在客户端日志中查看请求耗时和状态。
npm install # 安装依赖
npm run dev # 开发模式（tsx 热重载）
npm run build # 生产构建
npm test # 运行 Vitest 测试
npm run test:mcp # MCP 合规检查（目标: 100/100）
npm run test:all # 完整门禁：version-check → typecheck → lint → build → test → test:mcpMIT © fangfuzha
获取文献全文工具。
前置条件：需要 PMCID 标识符
如果您有 PMCID（如 PMC1234567），直接使用此工具
如果您只有关键词或标题，请先使用"文献搜索"工具查找并获取 PMCID
主要参数：
pmcid: PMCID 标识符（必填）：单个或列表[PMC1234567, PMC2345678, ...] 批量模式最多支持20个 PMCID
sections: 全文章节控制（可选，默认None获取全部章节） None → 获取全部章节（全文） ["conclusion", "discussion"] → 只获取指定章节
format: 全文格式（可选，默认"markdown"） "markdown" → Markdown格式（推荐，适合AI处理） "xml" → 原始XML格式 "text" → 纯文本格式
数据源：Europe PMC + PMC 全文数据库 返回数据包含标题、作者、摘要、期刊、发表日期和全文内容
全文功能：
按需获取指定格式（默认Markdown）
支持按章节提取（如方法、讨论、结论等）
优化性能，只转换请求的格式
批量返回结构： { "total": 10, # 总请求数 "successful": 8, # 成功获取数 "failed": 2, # 失败数 "articles": [...], # 成功的文章列表（含全文） "fulltext_stats": { # 全文统计 "has_pmcid": 8, # 有 PMCID 数量 "fulltext_fetched": 8 # 成功获取全文数量 } }
支持的章节名称：
methods（方法）: methods, methodology, materials and methods
introduction（引言）: introduction, intro, background
results（结果）: results, findings
discussion（讨论）: discussion
conclusion（结论）: conclusion, conclusions
abstract（摘要）: abstract, summary
references（参考文献）: references, bibliography
| Name | Required | Description | Default |
|---|---|---|---|
| pmcid | Yes | ||
| sections | No | ||
| format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively covers behavioral aspects: data source (Europe PMC + PMC), return fields, batch structure with stats, format conversion, and section extraction. Annotations indicate readOnlyHint=true, and the description confirms read-only behavior, with no contradictions.
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 (prerequisites, parameters, data source, return structure, supported sections) and front-loaded purpose. Though verbose, every part serves a purpose; a slight reduction in redundancy could improve conciseness.
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 no output schema and limited schema descriptions, the description provides complete context: prerequisites, parameter semantics, return structure example, supported sections, and batch statistics. It also references the sibling search_literature tool for alternative scenarios.
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 explaining each parameter in detail: pmcid (required, can be list, max 20), sections (acceptable values and mapping), format (options with recommendations). It adds meaning well beyond the schema.
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 it is a tool for retrieving full text of literature using PMCID. It distinguishes itself from sibling tools by specifying that if only keywords or title are available, the search_literature tool should be used first.
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 explicitly provides usage guidance: use when you have a PMCID, otherwise use the search_literature tool. It also details batch mode limits and parameter behavior (e.g., sections defaulting to None for full text).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
期刊质量评估工具。评估期刊的学术质量和影响力指标，集成 EasyScholar + OpenAlex 双数据源。
支持的指标： EasyScholar 提供：impact_factor（影响因子）、quartile（SCI分区 Q1-Q4）、jci（JCI指数）、cas_zone（中科院分区）、cas_zone_top（TOP期刊标识） OpenAlex 提供：h_index（h指数）、citation_rate（2年引用率）、cited_by_count（总引用数）、works_count（总文章数）、i10_index（i10指数）
主要参数：
journal_name: 期刊名称（单个或列表）
include_metrics: 返回的指标列表（默认["impact_factor", "quartile", "jci"]）
use_cache: 是否使用24小时缓存（默认true）
sort_by: 排序字段，仅批量查询有效（默认null）：impact_factor/quartile/jci
sort_order: 排序顺序，仅批量查询有效（默认desc）：desc降序/asc升序
使用示例：单个期刊查询、批量期刊查询、批量查询并排序、指定返回指标
| Name | Required | Description | Default |
|---|---|---|---|
| journal_name | Yes | ||
| include_metrics | No | ||
| use_cache | No | ||
| sort_by | No | ||
| sort_order | No | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: integration of EasyScholar and OpenAlex data sources, 24-hour cache via 'use_cache', and sorting constraints ('仅批量查询有效'). These details add value beyond annotations that already indicate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with bullet points for metrics and parameters, front-loaded with purpose. It is slightly verbose with repeated '仅批量查询有效' but each section earns its place.
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 multi-source, multi-parameter tool with no output schema, the description covers data sources, metrics, parameters, and usage examples. Missing details on error handling or data source fallback, but overall sufficient for effective use.
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 compensates fully by explaining each parameter: 'journal_name' supports single/list, 'include_metrics' lists default metrics, 'sort_by'/'sort_order' note batch-only validity. It provides defaults and constraints not in the schema.
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 '评估期刊的学术质量和影响力指标' (evaluates journal academic quality and impact metrics), specifying it uses dual data sources. It distinguishes itself from sibling tools like 'get_article_details' by focusing exclusively on journal-level metrics.
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 usage examples (single/batch queries) and parameter guidance but lacks explicit when-to-use or comparison with alternatives. It does not explain when to prefer this tool over siblings like 'search_literature'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文献关系分析工具。分析文献间的引用关系、相似文献和引用网络。
关系类型：
references: 该文献引用的参考文献
similar: 相似文献
citing: 引用该文献的文献
主要参数：
identifiers: 文献标识符（单个或列表）：DOI、PMID、PMCID
id_type: 标识符类型（默认auto）：auto/doi/pmid/pmcid
relation_types: 关系类型列表（默认全部）：["references", "similar", "citing"]
max_results: 每种关系类型最大结果数（默认20）
analysis_type: 分析类型（默认basic）：basic/comprehensive/network
max_depth: 分析深度（默认1）
分析模式：
单个文献：传入单个标识符
批量分析：传入标识符列表 + analysis_type="basic"
网络分析：传入标识符列表 + analysis_type="network"
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | No | ||
| identifiers | No | ||
| id_type | No | auto | |
| relation_types | No | ||
| max_results | No | ||
| sources | No | ||
| analysis_type | No | basic | |
| max_depth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details relation types and analysis modes, adding behavioral context beyond the readOnlyHint annotation. However, it does not mention potential rate limits or data volume implications for network analysis.
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 (purpose, relation types, parameters, analysis modes). While it is somewhat long, it is front-loaded with essential information. A few sentences could be tightened, but overall it is efficient.
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 complexity (8 parameters, no output schema), the description covers most aspects but misses the return format or examples of output. The analysis modes and parameter details are good, but the missing 'sources' parameter and lack of output documentation leave gaps.
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 explains most parameters (identifiers, id_type, relation_types, max_results, analysis_type, max_depth) but omits 'sources' and does not clarify the dual 'identifier'/'identifiers' fields. The parameter explanations are helpful but incomplete.
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 it analyzes citation relationships, referencing, similar, and citing papers. It uses specific verbs ('分析') and resources ('文献关系'), and distinguishes itself from siblings like 'get_references' by offering multiple relation types and analysis modes.
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 usage guidance through analysis modes (single, batch, network) and parameter combinations, but does not explicitly compare with sibling tools or state when not to use it. The three analysis modes help the agent decide based on input cardinality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取参考文献工具。通过文献标识符获取其引用的参考文献列表，支持智能去重。
主要参数：
identifier: 文献标识符（必填）：DOI、PMID、PMCID
id_type: 标识符类型（默认doi）：auto/doi/pmid/pmcid
sources: 数据源列表（默认["europe_pmc", "crossref"]）
max_results: 最大参考文献数量（默认20，建议20-100）
include_metadata: 是否包含详细元数据（默认true）
支持的数据源：Europe PMC、CrossRef、PubMed 去重规则：优先按DOI去重，其次按标题去重；按数据源优先级排序
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | ||
| id_type | No | doi | |
| sources | No | ||
| max_results | No | ||
| include_metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds dedup rules and data source priorities beyond annotations (readOnlyHint=true). Discloses behavioral traits like '智能去重' (smart dedup) but doesn't cover all behaviors (e.g., pagination).
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?
Concise yet comprehensive: one sentence for purpose, bulleted parameter list, and notes on data sources and dedup. No filler, every sentence adds value.
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?
Covers parameters and behavioral rules well, but lacks description of return format or example. For a reference-listing tool without output schema, a brief note on output structure would improve completeness.
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 explains each parameter: identifier types, id_type enum, sources defaults, max_results range, include_metadata purpose. Adds meaning beyond the plain schema.
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 '获取参考文献工具' (get references tool) and specifies it retrieves references for a given identifier with dedup. It is distinct from siblings like get_article_details or search_literature.
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?
Implied usage through parameter descriptions, but no explicit when-to-use or when-not-to-use compared to siblings. The dedup rules and data sources provide context but not direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
多源文献搜索工具。用于查找文献并获取 PMCID。
⚠️ 此工具只返回元数据（标题、作者、摘要、PMCID等），不包含全文内容。 如需获取全文，请使用返回结果中的 pmcid 调用"文献全文"工具。
搜索策略：
comprehensive: 全面搜索，使用所有可用数据源（并集）
fast: 快速搜索，只使用主要数据源（Europe PMC、PubMed）
precise: 精确搜索，只使用权威数据源（PubMed、Europe PMC，交集）
preprint: 预印本搜索（arXiv）
主要参数：
keyword: 搜索关键词（必填）
sources: 数据源列表（可选，默认根据搜索策略自动选择）
max_results: 每个源的最大结果数（默认10）
search_type: 搜索策略（默认comprehensive）
use_cache: 是否使用24小时缓存（默认true）
返回数据包含：标题、作者、期刊、摘要、PMCID、DOI等元数据（不含全文）
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| sources | No | ||
| max_results | No | ||
| search_type | No | comprehensive | |
| use_cache | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description reinforces that this tool is read-only and returns only metadata (no full text). It also discloses caching behavior (24-hour cache via use_cache parameter). There is no contradiction between description and annotations.
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-organized with bullet points and sections. The first sentence states the primary purpose, followed by a warning, search strategies, and parameter details. Every sentence is informative, with no redundancy or filler.
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?
The tool has 5 parameters (1 required) and no output schema, but the description covers all aspects: input parameters with defaults, return values (titles, authors, abstract, PMCID, DOI, etc.), and behavioral notes (caching, metadata-only). This is complete for an agent to use correctly.
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, the description thoroughly explains each parameter: keyword (required), sources (optional, auto-selected), max_results (default 10), search_type (with enum values and explanations), and use_cache (default true). This adds significant meaning beyond the schema.
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's purpose: '多源文献搜索工具。用于查找文献并获取 PMCID.' It specifies the resource (literature) and action (search), and distinguishes from siblings like get_article_details by focusing on searching and returning metadata.
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 explicit guidance on when to use this tool vs alternatives: it returns only metadata; for full text, users should use the '文献全文' tool with the returned pmcid. It also details search strategies (comprehensive, fast, precise, preprint) with explanations, helping the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: search finds literature, get_article_details retrieves full text, get_references and get_literature_relations both deal with citations but the latter is broader (includes citing and similar). Some potential overlap between get_references and get_literature_relations with relation_type='references', but descriptions clarify different scopes.
Most tools follow 'get_noun' pattern (get_article_details, get_journal_quality, get_literature_relations, get_references) with consistent snake_case. One tool deviates with 'search_literature' (verb 'search' instead of 'get'), but the pattern is still verb_noun and readable. Minor inconsistency.
With 5 tools, the set covers core research tasks (search, full text, references, relations, journal quality). It is not overly large or minimal; fits the domain well. A few more tools like a dedicated metadata fetcher or citation tool could be added, but current count is appropriate.
The tools cover searching, full text retrieval, reference lists, citation relations, and journal metrics. Notable gaps: no tool to get article metadata without full text (search returns metadata but only in search context), no direct citation count tool, and batch support is inconsistent across tools. Missing update/delete operations (not applicable) but lacks some lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fangfuzha/article-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
