Allows searching and fetching metadata of academic papers from arXiv.
Allows searching and fetching metadata of academic papers from Google Scholar.
Allows searching and fetching metadata of academic papers from PubMed.
Allows searching and fetching metadata of academic papers from Semantic Scholar.
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., "@aigroup-paper-mcp search for papers about large language models"
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.
Academic paper search and retrieval MCP server integrating multiple scholarly platforms into a unified interface.
aigroup-paper-mcp provides a unified MCP interface for searching, retrieving, and organizing academic paper metadata across major scholarly sources.
It is designed for:
cross-platform academic paper search
paper metadata retrieval and browsing
literature review assistance
research gap analysis and comparison workflows
integration with Claude Desktop and other MCP-compatible clients
Related MCP server: scholar-toolkit-mcp
12+ academic platforms integrated behind one MCP interface
6 advanced tools for search, fetch, discovery, and trend analysis
3 resource patterns for direct metadata and category access
3 prompt templates for literature-review-style workflows
structured responses, caching, and parallel search support
The server currently supports sources such as:
arXiv
OpenAlex
PubMed Central (PMC)
Europe PMC
bioRxiv
medRxiv
CORE
Semantic Scholar
Crossref
PubMed
Google Scholar
IACR
Node.js >= 18
npm
git clone https://github.com/jackdark425/aigroup-paper-mcp.git
cd aigroup-paper-mcp
npm install
npm run build
npm startnpx aigroup-paper-mcp --help
npx aigroup-paper-mcp search "machine learning"
npx aigroup-paper-mcp fetch "2301.00001" --source arxiv{
"mcpServers": {
"aigroup-paper-mcp": {
"command": "npx",
"args": ["aigroup-paper-mcp"]
}
}
}search_papersCross-platform paper search with smart source selection and query optimization.
fetch_paperFetches detailed metadata for a paper by source and identifier.
fetch_latestGets the latest papers from a selected source/category.
list_categoriesLists supported categories for a given platform.
advanced_searchSupports more complex boolean-style academic search queries.
trend_analysisAnalyzes topic evolution and publication trends over time.
paper://{source}/{id}
category://{source}/{category}
search://{query}
literature_review
research_gap_analysis
paper_comparison
Create a .env file if needed:
LOG_LEVEL=info
CACHE_ENABLED=true
CACHE_TTL=3600
MAX_SEARCH_LIMIT=100aigroup-paper-mcp/
├── src/
├── docs/
├── scripts/
├── package.json
└── README.mdnpm run build
npm run test
npm run lintThis project is released under the MIT License.
You may use, copy, modify, merge, publish, distribute, sublicense, and sell copies of this software, including in academic, internal, and commercial contexts, provided that the original copyright notice and license text are preserved.
Please keep in mind:
the software is provided "AS IS", without warranty of any kind
you must retain the relevant copyright and permission notice in copies or substantial portions of the software
downstream usage remains subject to the terms, rate limits, metadata rules, and access restrictions of upstream academic data providers
See the full text in LICENSE.
Thanks to the academic and open metadata ecosystems that make federated retrieval possible, including arXiv, OpenAlex, PubMed, Crossref, Semantic Scholar, and related services.
Model Context Protocol SDK
Repository: https://github.com/modelcontextprotocol/servers
Role: MCP server integration and tool/resource/prompt model
具有布尔运算符（AND、OR、NOT）、模糊匹配和精确匹配功能的高级搜索。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 带有布尔运算符的搜索查询 | |
| sources | No | 要搜索的特定平台 | |
| field | No | 搜索字段 | |
| fuzzyMatch | No | 启用模糊匹配（默认：false） | |
| exactMatch | No | 启用精确匹配（默认：false） | |
| limit | No | 每个平台的最大结果数（默认：10） | |
| offset | No | 分页偏移量（默认：0） |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It only mentions features (Boolean, fuzzy, exact) but does not disclose side effects, performance implications, or other behavioral traits such as rate limits or data handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's key features. No unnecessary words or fluff.
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 (7 parameters, advanced features, output schema), the description is adequate but not comprehensive. It lacks details on query syntax, feature interactions, and return value structure, though the output schema may compensate for the latter.
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 coverage is 100% with individual parameter descriptions. The description adds minimal value by summarizing features (Boolean, fuzzy, exact) already implied by parameter names and descriptions. It does not explain parameter interactions or syntax 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 an 'advanced search' with Boolean operators, fuzzy matching, and exact matching, which distinguishes it from simpler search tools like 'search_papers'. However, it does not explicitly name the resource being searched (e.g., papers), though context implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description merely lists features without explaining when Boolean operators are beneficial or when to prefer 'search_papers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从特定类别的平台获取最新论文。具有智能缓存和摘要模式功能。
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 要获取的平台源 | |
| category | No | 要获取的类别/主题（可选） | |
| limit | No | 要获取的最大论文数（默认：10，最大：50） | |
| useCache | No | 是否使用缓存（默认：true） | |
| summaryOnly | No | 仅返回摘要信息 | |
| enableEnhancement | No | 启用结果增强（默认：true） |
| Name | Required | Description |
|---|---|---|
| papers | Yes | |
| total | Yes | |
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It mentions 'intelligent caching and summary mode', but does not explain what these entail, nor does it disclose side effects, auth needs, or rate limits. The description is too brief to be informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is efficient but could be more informative without becoming verbose.
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 (6 parameters, no annotations, an output schema exists), the description is too sparse. It does not explain how caching affects behavior, what summary mode returns, or how to combine parameters. The agent lacks sufficient context to use the tool optimally.
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?
All 6 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description mentions caching and summary mode, which aligns with parameters but adds no new meaning beyond the schema. No additional semantic detail is provided.
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 fetches the latest papers from a platform of a specific category, which is a specific verb-resource pair. However, it does not differentiate from sibling tools like 'fetch_paper' or 'advanced_search', which could be confused.
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?
There is no guidance on when to use this tool compared to alternatives such as 'fetch_paper' (for a specific paper) or 'search_papers' (for general search). The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从指定平台根据ID获取论文的详细信息。返回完整的元数据。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 平台特定格式的论文ID | |
| source | Yes | 论文所在平台源 |
| Name | Required | Description |
|---|---|---|
| paper | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only says it returns metadata but does not disclose if it's read-only, error behavior, authentication needs, rate limits, or what happens with invalid IDs. Incomplete for a fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks important details. It is not overly long, but could be better structured with key behavioral information.
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 fetches from 12 different sources, the description is too brief. It doesn't explain differences between sources, ID format requirements, or success/failure behavior. Output schema exists but description still insufficient.
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 coverage is 100% and parameter descriptions are clear. The tool description does not add additional meaning beyond the schema, so baseline score of 3 applies.
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 gets detailed paper information by ID from a specified platform and returns complete metadata. This verb+resource description distinguishes it from siblings like search_papers and fetch_latest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention conditions or context where fetch_paper should be preferred over search_papers or fetch_latest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出一个或所有平台的可用类别/主题。
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | 平台源（留空则列出所有平台的类别） |
| Name | Required | Description |
|---|---|---|
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not explicitly state that the tool is read-only or non-destructive, nor does it mention any side effects or prerequisites. The implied behavior is a simple list operation, but the lack of explicit transparency is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that conveys the tool's purpose without extraneous information. Perfect conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one optional parameter, and the presence of an output schema (inferred from context), the description provides adequate context. It could mention the return format but is not strictly necessary. Still, high completeness for the complexity level.
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 100% for the single parameter, and the description adds little beyond the schema's explanation that leaving source empty lists all platforms. Baseline of 3 is appropriate as the description reinforces but does not significantly extend parameter meaning.
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 lists categories/themes for one or all platforms. It uses a specific verb and resource, and distinguishes well from sibling tools focused on searching, fetching papers, or analyzing trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only mentions scope (one or all platforms), but does not provide context for selection among siblings or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
管理学术论文搜索的缓存系统，包括查看缓存内容、获取缓存项、清理缓存和获取统计信息。
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 缓存管理操作：列出键、获取项、清理缓存、获取统计信息 | |
| key | No | 要获取的缓存键（get操作时必需） | |
| pattern | No | 过滤缓存键的模式（支持通配符 *） | |
| namespace | No | 要操作的缓存命名空间 |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| message | Yes | |
| totalKeys | No | |
| filteredKeys | No | |
| keys | No | |
| data | No | |
| metadata | No | |
| totalDeleted | No | |
| remainingKeys | No | |
| totalSizeBytes | No | |
| totalSizeMB | No | |
| averageItemSize | No | |
| sourceDistribution | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose traits. It mentions clearing cache but does not state if it is destructive or what side effects occur. Read vs write behavior is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence covering all operations is concise, but could benefit from slight structuring (e.g., listing operations). No wasted words.
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 presence of an output schema and moderate complexity, the description is minimally adequate but lacks behavioral context and usage guidance.
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 coverage is 100%, so baseline is 3. The description adds no parameter details beyond what the schema already provides.
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 identifies the tool as managing the cache system for academic paper search, with specific actions (list, get, clear, stats) that distinguish it from search and fetch siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives or when to choose a specific action. The description lists operations without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
跨多个学术平台搜索论文（arXiv、OpenAlex等）。支持多字段搜索、过滤和排序。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索查询关键词。系统会自动优化和纠正拼写错误。 | |
| sources | No | 要搜索的特定平台。 | |
| field | No | 搜索字段：全部、标题、摘要、作者、关键词、全文。 | |
| categories | No | 按类别/主题过滤。 | |
| sortBy | No | 排序字段 | |
| sortOrder | No | 排序顺序 | |
| limit | No | 每个平台的最大结果数（默认：10，最大：100） | |
| offset | No | 分页偏移量（默认：0） |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| total | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool searches multiple platforms and supports various options. It does not mention rate limits, error handling, caching behavior, authorization requirements, or any side effects. Critical information like automatic query optimization is only in the parameter schema, not in the description.
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 extremely concise—a single sentence that immediately states the tool's purpose and key features. There is no fluff, and all information is front-loaded. Every word 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?
Despite an output schema existing (indicated) and rich parameter definitions, the description omits important contextual details such as pagination behavior, cross-platform result merging, data source differences, or any limitations. With 8 parameters and multiple enums, the description should provide more operational context to ensure correct usage.
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 coverage is 100%, so the baseline is 3. The description adds a high-level summary of capabilities (multi-field, filtering, sorting) but does not provide deeper insight into parameter interactions or constraints beyond what the schema already defines. No additional meaning is added for parameter usage.
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 function: searching papers across multiple academic platforms (arXiv, OpenAlex, etc.) with support for multi-field search, filtering, and sorting. It uses a specific verb ('search') and resource ('papers'), and the mention of platforms distinguishes it from sibling tools like advanced_search or fetch_paper.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios where this tool is preferred, or when not to use it. Sibling tools like advanced_search and smart_cache_search exist but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
基于语义相似度在缓存中查找相关文献数据，即使查询内容不完全相同也能找到相关结果。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索查询，系统会基于语义相似度查找相关缓存 | |
| similarityThreshold | No | 语义相似度阈值（0-1，默认0.7） | |
| maxResults | No | 最大返回结果数 | |
| includeExpired | No | 是否包含过期缓存（默认不包含） |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| query | Yes | |
| totalKeys | Yes | |
| validKeys | Yes | |
| matchedResults | Yes | |
| similarityThreshold | Yes | |
| results | Yes | |
| suggestions | Yes | |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the tool uses semantic similarity and operates on cache, which is basic. It does not mention side effects, authorization needs, or behavior when cache is empty, missing opportunities to add depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information. It is efficient and focused, though splitting into two sentences could improve readability slightly.
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?
An output schema exists, so return value details are unnecessary. However, the description lacks an explicit note that the tool only searches cached data, not the full database, which is critical context given sibling tools like search_papers. Overall adequate but could be more complete.
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?
Input schema coverage is 100% with all parameters described. The description adds no additional meaning beyond the schema, such as how to formulate queries or interpret thresholds. Baseline score of 3 is appropriate since schema already provides adequate 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 clearly states it searches for literature data in cache using semantic similarity, differentiating it from sibling tools like search_papers which may perform exact or database searches. The verb '查找' and resource '缓存中相关文献数据' are specific, and the mention of '语义相似度' distinguishes its fuzzy matching approach.
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 implies use for fuzzy searches in cache but does not explicitly specify when to use this tool over alternatives like advanced_search or search_papers. No guidance on prerequisites, exclusions, or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析特定主题随时间的变化趋势，包括增长率、高峰期和关键词分析。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 要分析趋势的主题 | |
| sources | No | 要分析的平台源 | |
| period | No | 分析时间段 | |
| granularity | No | 时间粒度 | |
| limit | No | 每个时间段要分析的最大论文数 |
| Name | Required | Description |
|---|---|---|
| trends | Yes | |
| topic | Yes | |
| totalPapers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only describes what the tool analyzes (growth rate, peaks, keywords) but does not state whether it is read-only, requires authentication, has rate limits, or any side effects. The lack of transparency about potential constraints or behaviors is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose efficiently. It is front-loaded and contains no filler. However, it could be slightly expanded to include usage guidance without becoming verbose.
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 that an output schema exists (as stated in context), the description does not need to explain return values. However, the description lacks explanations of how parameters like sources or granularity affect the output, and it offers no guidance on interpretation. This is adequate but not comprehensive.
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 100%, so each parameter's purpose is already documented in the input schema. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain how topic or sources influence the analysis). Baseline score of 3 is appropriate.
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 that the tool analyzes trends of a specific topic over time, including growth rate, peaks, and keyword analysis. It uses specific verbs and resources ('分析主题随时间的变化趋势') and distinguishes itself from sibling tools like search_papers and fetch_latest by focusing on trend analysis rather than paper retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description does not mention conditions, prerequisites, or situations where another sibling tool would be more appropriate. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All tools have clearly distinct purposes: advanced_search vs search_papers differ in syntax capabilities, smart_cache_search targets cache semantic search, and others are unique operations. No overlapping responsibilities.
All tool names follow a consistent snake_case pattern with imperative verbs (fetch, list, manage, search) or compound nouns, no mixing of conventions.
8 tools is appropriate for a paper MCP server, covering search, retrieval, cache management, and trend analysis without being too sparse or bloated.
Core functionalities like searching (basic, advanced, semantic), fetching, categories, and trends are covered. Minor gaps include lack of direct PDF retrieval or citation networking, but the surface is comprehensive for typical academic paper search.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Multi-engine scholarly research server for search, traversal, full text, and reading lists.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jackdark425/aigroup-paper-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
