Europe PMC Literature Search MCP Server

by gqy20

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes (e.g., batch_enrich_references_by_dois for bulk DOI enrichment, search_europe_pmc for searching, get_similar_articles for similarity), but there is some overlap between get_article_details and batch_enrich_references_by_dois, as both can retrieve article details via DOI/PMID, which might cause confusion. However, descriptions clarify that batch_enrich_references_by_dois is optimized for bulk processing, while get_article_details is for single PMIDs with caching.
Naming Consistency3/5
Naming is mixed with no clear pattern: some use snake_case (batch_enrich_references_by_dois, get_article_details), others use camelCase (evaluate_articles_quality), and some are inconsistent (get_references_by_doi vs. get_citing_articles). While all names are descriptive, the lack of a uniform convention (e.g., all snake_case or all camelCase) reduces predictability.
Tool Count5/5
With 9 tools, the count is well-scoped for a literature search server covering Europe PMC, arXiv, and quality assessment. Each tool serves a specific function (searching, enrichment, quality evaluation, citation analysis), and none seem redundant or excessive for the domain.
Completeness4/5
The toolset covers core literature search and analysis tasks well: searching (Europe PMC, arXiv), article details retrieval, reference/citation handling, quality assessment, and similarity finding. A minor gap is the lack of tools for user-specific operations like saving searches or managing collections, but this is not essential for the stated purpose.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the processing flow (PubMed elink+efetch, fallback to Europe PMC) and return structure, which adds behavioral context beyond basic function. However, it lacks details on permissions, rate limits, error handling specifics, or performance characteristics. The description adds some value but is incomplete for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with a clear purpose statement and numbered process steps. However, the process details are somewhat technical and could be simplified for an AI agent. It's front-loaded with the purpose, but the structure includes unnecessary implementation details that don't aid tool selection.
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?
Given no annotations, 0% schema coverage, and an output schema present, the description is partially complete. It explains the processing flow and return structure, which helps, but lacks parameter explanations and usage context. The output schema reduces the need to describe return values, but gaps in behavioral and parameter details remain.
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 'PMID' implicitly in the process but doesn't explain the three parameters (pmid, email, max_results) or their roles. The description adds no meaningful semantics beyond what the schema's property names suggest, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: '获取引用该文献的文献信息' (Get information about articles citing this literature). It specifies the resource (articles citing a given literature) and the action (get information), though it doesn't explicitly differentiate from siblings like 'get_similar_articles' or 'get_references_by_doi'. The purpose is clear but lacks sibling distinction.
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 mentions a fallback mechanism (PubMed to Europe PMC) but doesn't specify use cases, prerequisites, or comparisons with siblings like 'search_europe_pmc' or 'get_similar_articles'. There's no explicit when/when-not or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it mentions automatic retry/error recovery, pagination support for large results, and being based on the arXiv official API. It also notes the email parameter improves API service. However, it doesn't specify rate limits, authentication requirements, or potential costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (功能说明, 参数说明, etc.), but is quite lengthy with redundant information. The '返回值说明' section duplicates what the output schema would provide, and some technical details could be more concise. However, information is reasonably front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, search functionality) and the presence of an output schema, the description provides good context. It covers parameters thoroughly, explains behavioral characteristics, and lists use cases. The main gap is lack of explicit guidance on when to use this versus sibling tools, but overall it's quite complete for a search tool.
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?
Schema description coverage is 0%, so the description must compensate. The '参数说明' section provides meaningful details for all 5 parameters: clarifies required vs optional status, explains keyword supports complex query syntax, specifies date formats, and documents default values and limits for max_results. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches arXiv's preprint database using the official API, specifying the resource (arXiv papers) and action (search). It distinguishes from siblings like 'search_europe_pmc' by focusing on arXiv, but doesn't explicitly contrast with other arXiv-related tools like 'get_article_details' or 'get_similar_articles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '使用场景' section lists general use cases like preprint literature search and tracking research trends, which provides implied guidance. However, it doesn't explicitly state when to choose this tool over alternatives like 'search_europe_pmc' or 'get_similar_articles', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effectively describes key traits: '异步方式' (asynchronous method), '支持并发处理' (supports concurrent processing), '集成缓存机制' (integrated caching mechanism), '自动重试和错误恢复' (automatic retry and error recovery), and performance metrics ('比同步版本快20-40%' - 20-40% faster than synchronous version). This covers operational behavior well, though it doesn't detail error types or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (功能说明, 参数说明, etc.), but it's verbose with redundant details. For example, '高性能优化版本' (high-performance optimized version) is repeated in performance sections, and some points like '支持并发处理' (supports concurrent processing) and '性能更优' (better performance) overlap. It could be more concise by eliminating repetition while maintaining clarity.
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?
Given the tool's complexity (performance-optimized with caching/retry), no annotations, and an output schema present, the description is highly complete. It explains the tool's purpose, usage, parameters, return values (including extra fields like processing_time), and behavioral traits. The output schema means return values don't need description, and the description covers all other aspects thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates fully under '参数说明' (parameter explanation). It specifies 'pmid: 必需，PubMed ID（如："37769091"）' (pmid: required, PubMed ID, e.g., "37769091"), adding meaning beyond the schema's basic string type by clarifying it's a PubMed ID with an example. This is excellent coverage for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: '获取特定文献的详细信息' (get detailed information for specific literature) with the verb '获取' (get) and resource '文献' (literature). It distinguishes from siblings by specifying it's for '特定文献' (specific literature) using PMID, unlike search or batch tools. However, it doesn't explicitly name sibling alternatives for differentiation, keeping it at 4 instead of 5.
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 usage context under '使用场景' (usage scenarios): '需要高性能的文献详情获取' (when high-performance literature detail retrieval is needed), '批量文献详情查询' (batch literature detail queries), and '大规模数据处理' (large-scale data processing). It implies this tool is for performance-critical cases but doesn't explicitly state when NOT to use it or name specific alternatives, so it scores 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains performance characteristics ('比传统方法快10-15倍' - 10-15x faster than traditional methods), technical implementation ('使用OR操作符将多个DOI合并为单个查询' - using OR operator to combine multiple DOIs into a single query), and operational benefits ('减少API请求次数、降低网络延迟影响' - reduces API request count, lowers network latency impact). The only minor gap is it doesn't explicitly mention error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (功能说明, 参数说明, 返回值说明, 使用场景, 性能特点, 技术原理), but it's quite verbose with repetitive information about batch optimization and performance benefits. Sentences like '相比传统方法可实现10倍以上的性能提升' and '比传统方法快10-15倍' convey similar points. While informative, it could be more concise by eliminating redundancy while maintaining clarity.
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?
Given the tool's complexity (batch optimization, performance characteristics), no annotations, 0% schema coverage, but with an output schema present, the description is remarkably complete. It covers purpose, usage guidelines, behavioral transparency, parameter semantics, return value details ('返回值说明' section), performance characteristics, and technical implementation. The presence of an output schema means the description doesn't need to exhaustively explain return values, and it provides comprehensive context beyond what structured fields would offer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description provides parameter information: '参数说明：- doi: 必需，数字对象标识符（如："10.1126/science.adf6218"）' (Parameter explanation: - doi: required, digital object identifier). This adds meaning by specifying it's required and providing an example format. However, with only 1 parameter total, the baseline would be 4 if no param info was provided; since it does provide some info but doesn't fully compensate for the 0% schema coverage (e.g., doesn't explain if multiple DOIs can be passed or format constraints), a 3 is appropriate.
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: '通过DOI获取参考文献列表（批量优化版本 - 基于Europe PMC批量查询能力）' which translates to 'Get reference list by DOI (batch optimized version - based on Europe PMC batch query capability)'. It specifies the verb ('获取' - get), resource ('参考文献列表' - reference list), and distinguishes from siblings by emphasizing batch optimization and Europe PMC integration, unlike other tools like get_article_details or search_europe_pmc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage scenarios: '使用场景：大规模参考文献获取、高性能批量数据处理、时间关键的研究任务、文献数据库构建' (Usage scenarios: large-scale reference acquisition, high-performance batch data processing, time-critical research tasks, literature database construction). It also distinguishes when to use this tool by mentioning it's '特别适用于大量参考文献的快速获取' (especially suitable for rapid acquisition of large numbers of references) and '最适合处理大量参考文献的场景' (most suitable for scenarios handling large numbers of references), guiding users away from alternatives for small-scale tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly explains the two-stage behavior: first checking local cache (journal_info.json), then optionally calling the EasyScholar API if a secret key is provided. It also describes the fallback mechanism when data isn't available locally. However, it doesn't mention potential rate limits, error handling beyond the error field, or authentication requirements for the API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (功能说明, 参数说明, 返回值说明, 使用场景), but contains some redundancy. The initial statement '获取期刊质量评估信息（影响因子、分区等）' is partially repeated in the functional description. The return value section is quite detailed but could be more concise given that an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, caching+API behavior), no annotations, but with an output schema, the description provides good completeness. It explains the dual data source approach, parameter purposes, and usage scenarios. The main gap is lack of information about error conditions beyond the error field, and no mention of what happens when neither local cache nor API provides data.
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?
With 0% schema description coverage, the description must compensate. It provides excellent parameter semantics: 'journal_name: 必需，期刊名称' (required, journal name) and 'secret_key: 可选，EasyScholar API密钥（可从环境变量EASYSCHOLAR_SECRET_KEY获取）' (optional, EasyScholar API key - can be obtained from environment variable EASYSCHOLAR_SECRET_KEY). This adds crucial meaning beyond the bare schema, explaining purpose, requirements, and even environment variable sourcing.
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 as '获取期刊质量评估信息（影响因子、分区等）' (get journal quality assessment information - impact factor, quartile, etc.), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'evaluate_articles_quality' (which evaluates articles) and 'get_article_details' (which gets article details) by focusing specifically on journal-level quality metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage scenarios in the '使用场景' section: '评估期刊质量' (evaluate journal quality), '选择投稿期刊' (select journals for submission), and '文献质量评估' (literature quality assessment). These give clear guidance on when to use this tool versus alternatives like article-focused tools or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effectively describes key behavioral traits: performance characteristics ('超高性能版本', '10-15倍速度提升'), constraints ('最多支持20个DOI同时处理' - supports up to 20 DOIs), data handling ('自动去重和信息完整性检查' - automatic deduplication and integrity checks), and API usage ('使用Europe PMC的批量查询API'). It doesn't mention error handling or rate limits, but covers most essential aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (功能说明, 参数说明, 返回值说明, 使用场景, 性能特点), but it's verbose. Some sentences could be more concise (e.g., the performance metrics section is detailed but repetitive). It's front-loaded with the core purpose, but the length slightly reduces efficiency.
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?
Given the tool's complexity (batch processing, performance optimization) and the presence of an output schema (which covers return values), the description is highly complete. It explains the tool's purpose, usage guidelines, parameters, behavioral traits, performance advantages, and use cases. With no annotations, it provides all necessary context for effective tool selection and invocation.
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?
With 0% schema description coverage, the description must compensate. It provides clear parameter semantics: 'dois: 必需，DOI列表，最多支持20个DOI同时处理' (required, DOI list, supports up to 20 DOIs) with an example, and 'email: 可选，联系邮箱，用于获得更高的API访问限制' (optional, contact email for higher API access limits). This adds substantial meaning beyond the bare schema, though it doesn't detail format constraints beyond the example.
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: '批量补全多个DOI的参考文献信息' (batch enrich multiple DOI references). It specifies the verb ('补全' - enrich/complement), resource ('参考文献信息' - reference information), and scope ('多个DOI' - multiple DOIs). It distinguishes from siblings like 'get_references_by_doi' by emphasizing batch processing and performance advantages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: '适合大规模文献数据处理' (suitable for large-scale literature data processing), '比逐个查询快10-15倍' (10-15 times faster than individual queries), and provides specific use cases like '大规模文献数据分析' (large-scale literature data analysis) and '批量文献信息补全' (batch literature information completion). It implicitly contrasts with sibling tools like 'get_references_by_doi' for individual queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: it uses NCBI eLink service, automatically filters for recent 5-year articles, batches retrieval of detailed information, and includes complete error handling. It also mentions that the 'email' parameter can provide higher API access limits. However, it does not specify rate limits, authentication requirements beyond the optional email, or potential costs/quotas.
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 well-structured with clear sections (功能说明, 参数说明, 返回值说明, 使用场景, 技术特点), making it easy to scan. It is appropriately sized for a tool with 3 parameters and detailed output. However, some redundancy exists (e.g., '批量获取详细信息' appears in both 功能说明 and 技术特点), and the 返回值说明 section is lengthy but necessary given the output schema's existence.
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?
Given the tool's complexity (algorithm-based similarity search), no annotations, and an output schema (which covers return values), the description is complete. It explains the purpose, parameters, usage scenarios, technical characteristics, and behavioral aspects. The output schema handles return value details, so the description appropriately focuses on operational context without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. The '参数说明' (Parameter explanation) section provides detailed semantics for all three parameters: 'doi' is required and defined as a Digital Object Identifier with an example; 'email' is optional and explained as providing higher API access limits; 'max_results' is optional with a default of 20. This adds comprehensive meaning beyond the bare schema.
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: '根据DOI获取相似文章（基于PubMed相关文章算法）' (Get similar articles based on DOI using PubMed's related articles algorithm). It specifies the verb ('获取' - get/fetch), resource ('相似文章' - similar articles), and method ('基于PubMed相关文章算法' - based on PubMed's related articles algorithm), distinguishing it from siblings like 'get_article_details' or 'search_europe_pmc' which serve different functions.
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 '使用场景' (Usage scenarios) section lists four specific contexts: literature review research, finding related studies, academic investigation, and related work analysis. This provides clear guidance on when to use the tool. However, it does not explicitly mention when NOT to use it or name alternatives among sibling tools, such as 'search_europe_pmc' for broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing important behavioral traits: the two-stage lookup process (local cache then API), the optional secret_key parameter with environment variable fallback, and the return structure. It doesn't mention rate limits, authentication requirements beyond the key, or error handling specifics, keeping it from a perfect score.
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?
Well-structured with clear sections (功能说明, 参数说明, 返回值说明, 使用场景) and front-loaded purpose. Some redundancy exists between the initial summary and functional description, but each sentence adds value. The Chinese formatting is efficient for the content covered.
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?
Given the tool's moderate complexity, no annotations, 0% schema coverage, but presence of output schema, the description is complete enough. It covers purpose, parameters, return values, usage scenarios, and behavioral workflow. The output schema handles return value details, so the description appropriately focuses on context rather than repeating structured data.
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?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'articles' as required literature list from search results, and 'secret_key' as optional API key with environment variable alternative. It doesn't specify the exact structure of article objects or key format details, but provides meaningful context beyond the bare schema.
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 specific action ('批量评估文献的期刊质量' - batch evaluate journal quality of articles) and resource ('文献列表中的每篇文献' - each article in a list). It distinguishes from siblings like 'get_journal_quality' by emphasizing batch processing and integration with search results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '使用场景' section explicitly lists three usage scenarios: batch evaluation of search results, literature quality filtering, and academic research quality assessment. This provides clear context for when to use this tool versus alternatives like 'get_journal_quality' which appears to be a single-article version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: async processing, concurrent request handling, caching mechanism, rate limits, automatic retry mechanism, and performance characteristics (30-50% faster than sync version). It doesn't mention authentication requirements or destructive operations, but covers most behavioral aspects well.
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?
Well-structured with clear sections (功能说明, 参数说明, 返回值说明, 使用场景, 性能特点), but could be more front-loaded. The first sentence establishes purpose, but some sections contain slightly redundant information. Overall efficient but not perfectly concise.
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?
Given the tool's complexity (5 parameters, no annotations) and the presence of an output schema, the description is remarkably complete. It covers purpose, parameters, return values, usage scenarios, and performance characteristics. The output schema existence means the description doesn't need to explain return values in detail, yet it still provides a helpful overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 providing detailed parameter explanations including required/optional status, format specifications (YYYY-MM-DD for dates), default values (max_results defaults to 10), range constraints (max_results up to 100), and examples of search syntax. This adds substantial meaning beyond what the bare schema provides.
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 searches the Europe PMC literature database, specifies it's a high-performance optimized version, and distinguishes it from siblings by mentioning it's an async version with performance improvements. The verb '搜索' (search) is specific and the resource 'Europe PMC 文献数据库' is clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides '使用场景' (usage scenarios) including bulk literature retrieval, high-performance search tasks, complex search queries, and frequent repeated queries. This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![article-mcp MCP server](https://glama.ai/mcp/servers/gqy20/article-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gqy20/article-mcp)

Score Badge

Copy to your README.md:

[![article-mcp MCP server](https://glama.ai/mcp/servers/gqy20/article-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gqy20/article-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gqy20/article-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server