Search arXiv for recent papers, retrieve metadata, and download and extract text from arXiv PDFs for reading and analysis.
Search Semantic Scholar for citation-aware paper discovery, retrieve detailed metadata, and align records across sources.
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., "@paper-search-mcp build literature digest on reinforcement learning safety"
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.
paper-search-mcp is an MCP server for agents that need to search papers, read arXiv PDFs, align records across sources, and produce structured literature-analysis inputs.
The server currently integrates two paper sources:
Semantic Scholar for citation-aware discovery and metadata lookup
arXiv for recent papers, metadata lookup, and PDF text extraction
It also includes higher-level utilities for cross-source alignment, BibTeX export, and compact literature digests.
Chinese documentation is available in README-zh.md.
search_semantic_scholarSearch Semantic Scholar and return normalized paper metadata sorted by citation count.
Parameters:
query: Search query
max_results: Maximum number of results, default 10
get_semantic_scholar_paperFetch detailed metadata for a Semantic Scholar paper by paper_id.
search_arxivSearch arXiv and return normalized metadata.
Parameters:
query: Search query
max_results: Maximum number of results, default 10
sort_by: relevance, lastUpdatedDate, or submittedDate
sort_order: ascending or descending
get_arxiv_paperFetch metadata for one arXiv paper using an arXiv ID, abstract URL, or PDF URL.
read_arxiv_paperDownload an arXiv PDF, cache it locally, extract text from the first pages, and return a structured reading pack.
Parameters:
arxiv_id_or_url: arXiv ID, abstract URL, or PDF URL
max_pages: Maximum number of pages to extract, default 8
max_characters: Maximum number of extracted characters, default 20000
export_bibtexExport a paper as BibTeX.
Parameters:
source: semantic_scholar or arxiv
identifier: Semantic Scholar paper_id or arXiv ID/URL
align_paper_by_titleSearch Semantic Scholar and arXiv by title and return exact normalized title matches across both sources.
Parameters:
title: Paper title used for exact title alignment
semantic_scholar_max_results: Search limit for Semantic Scholar, default 10
arxiv_max_results: Search limit for arXiv, default 10
build_literature_digestSearch across Semantic Scholar and arXiv, deduplicate overlapping papers, and return a compact literature-analysis bundle.
This is useful for downstream agent tasks such as:
finding classic work versus recent work
grouping methods into families
comparing datasets, metrics, and limitations
Related MCP server: Research Paper Ingestion MCP Server
This project is designed to use uv for environment and dependency management.
uv syncThis creates .venv in the project directory and installs the project dependencies.
To include development dependencies as well:
uv sync --group devIf you have a Semantic Scholar API key:
export S2_API_KEY=your_key_hereOptional environment variables:
S2_API_KEY: Semantic Scholar API key
PAPER_MCP_HTTP_TIMEOUT: HTTP timeout in seconds, default 30
PAPER_MCP_USER_AGENT: Custom user agent string
PAPER_MCP_CACHE_DIR: Override the on-disk cache directory for downloaded PDFs
For local development or direct Python-based deployment:
pip install .To install directly from a Git repository:
pip install https://github.com/xiaoxiaoxiaotao/paper-search-mcp.gitStart the server directly:
uv run paper-search-mcpExample MCP client configuration:
{
"servers": {
"paper-search": {
"type": "stdio",
"command": "uv",
"args": [
"run",
"--no-sync",
"paper-search-mcp"
],
"cwd": "/home/tao/code/projects/paper-search-mcp",
"env": {
"S2_API_KEY": "${env:S2_API_KEY}"
}
}
},
"inputs": []
}If you prefer not to use input prompts, configure envFile instead of env and place S2_API_KEY=your_key_here in that file.
Semantic Scholar is better for established, citation-rich papers.
arXiv is better for recent work and full-text PDF reading.
build_literature_digest reduces prompt assembly work for downstream agents.
read_arxiv_paper returns text and analysis prompts instead of hard-coded conclusions.
PDF downloads are cached on disk to avoid repeated arXiv fetches.
An npm package is possible as a thin wrapper, but the primary runtime is still Python or Docker.
DOI / PMID / ACL Anthology / OpenAlex support
citation graph and related-paper retrieval
richer section-aware PDF chunking
persistent metadata caching beyond PDFs
Find exact title matches across Semantic Scholar and arXiv and return aligned cross-source pairs.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| arxiv_max_results | No | ||
| semantic_scholar_max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the core action but does not disclose whether the tool mutates data, requires authentication, or handles edge cases like no matches. The read-only nature is inferred from sibling tools but not explicitly confirmed.
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 is front-loaded with the tool's purpose. Every word is necessary, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and an output schema, but the description does not specify the output format or behavior for edge cases. While the output schema exists, the description lacks guidance on usage expectations and integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not provide any meaning for 'title', 'arxiv_max_results', or 'semantic_scholar_max_results' beyond what the schema already conveys. The agent must infer that max_results limits the number of results per source.
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 verb 'Find exact title matches', identifies the two resources (Semantic Scholar and arXiv), and specifies the outcome (aligned cross-source pairs). This distinguishes it from sibling tools like search_arxiv and search_semantic_scholar that perform general searches without alignment.
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 using this tool when you have a specific title and want cross-source alignment. It does not explicitly state when not to use or mention alternatives, but the context of siblings makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across sources, deduplicate overlapping papers, and return a compact literature review digest.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| include_arxiv | No | ||
| max_results_per_source | No | ||
| include_semantic_scholar | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 that the tool searches, deduplicates, and returns a digest, which are key behaviors. However, it does not mention whether it is read-only, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 14 words, with front-loaded action. Every word 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?
With 4 parameters and no annotations, the description is incomplete. It lacks parameter explanations and fails to specify return details, though output schema exists. Missing context for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It fails to add meaning for `query`, `include_arxiv`, `max_results_per_source`, or `include_semantic_scholar`. The description should compensate but does not.
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 verb 'build' with the resource 'literature digest', and explains it involves searching, deduplicating, and returning a compact digest. It distinguishes from siblings like individual search tools by combining multiple sources.
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 the tool is for aggregating from multiple sources, but does not explicitly state when to use it versus alternatives like searching individually. No when-not or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an arXiv PDF to a specified absolute file or directory path.
| Name | Required | Description | Default |
|---|---|---|---|
| save_path | Yes | ||
| arxiv_id_or_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions the download action, omitting details on overwrite behavior, error handling, or return format.
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 of 9 words, no waste. Front-loaded with the action.
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?
Output schema exists but description doesn't detail return values. For a simple download tool, basic info is present, but missing error handling and overwrite behavior.
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 0%, so the description adds some meaning: save_path must be absolute and can be a file or directory. However, it doesn't specify how directory paths are handled (e.g., filename generation).
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 verb (Download), resource (arXiv PDF), and target (absolute file or directory path). It distinguishes from siblings like download_semantic_scholar_pdf and get_arxiv_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?
No guidance on when to use this tool vs. alternatives like download_semantic_scholar_pdf. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a Semantic Scholar PDF (Open Access or arXiv linked) to a specified absolute path.
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | ||
| save_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only mentions saving to a path, omitting side effects like overwriting, network usage, or conditions for failure (e.g., non-Open Access papers).
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 13-word sentence, concise and front-loaded with essential 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?
Despite having an output schema (not shown), the description lacks information on return values, error handling, or when downloads might fail, which is critical for a download tool.
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 0%, so the description must compensate. It adds minimal meaning: 'save_path' is clarified as a path, but no format, examples, or valid values for either parameter are given.
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 specifies the verb 'download', the resource 'Semantic Scholar PDF', and constraints 'Open Access or arXiv linked' and destination 'specified absolute path'. It distinguishes from sibling 'download_arxiv_pdf' by its scope.
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 usage for downloading Semantic Scholar PDFs but does not explicitly state when to choose this over siblings like 'download_arxiv_pdf' or 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.
Export a paper as BibTeX using either a Semantic Scholar paper ID or an arXiv identifier/URL.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details. It only states the outcome (export as BibTeX) but does not mention error handling, rate limits, or whether the operation is read-only. The purpose is clear but behavioral context is minimal.
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, front-loaded sentence of 20 words. Every word is necessary. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values. It explains the input options but lacks explicit parameter mapping. Overall, it is nearly complete for a relatively simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Semantic Scholar paper ID' and 'arXiv identifier/URL' but does not map these to the parameters 'source' and 'identifier', nor explain what values 'source' can take. It adds some meaning but insufficient detail.
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 states the verb 'Export' and the resource 'a paper as BibTeX', and specifies two input options: Semantic Scholar paper ID or arXiv identifier/URL. This clearly distinguishes it from sibling tools that focus on downloading PDFs or reading papers.
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 usage when needing BibTeX citations from a paper, and contrasts with sibling tools. However, it does not explicitly state when not to use it or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch normalized metadata for a specific arXiv paper using an arXiv ID, abs URL, or PDF URL.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id_or_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only says 'Fetch normalized metadata' without mentioning any behavioral traits such as network dependency, rate limits, or idempotency. The output schema covers return format, but other aspects like execution behavior are opaque.
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 one sentence that efficiently conveys the tool's purpose and input formats without any redundant words 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?
For a simple tool with one parameter and an output schema, the description provides the essential information. However, it could mention that metadata is normalized or hint at the output structure. Missing behavioral details like caching or network calls, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by specifying that the single parameter can be an arXiv ID, abs URL, or PDF URL, which clarifies the accepted formats beyond the schema's generic 'Arxiv Id Or Url' title.
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 verb 'Fetch' and the resource 'normalized metadata for a specific arXiv paper'. It specifies three input formats (arXiv ID, abs URL, PDF URL), which distinguishes it from sibling tools like download_arxiv_pdf or read_arxiv_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 implies usage when you have an arXiv identifier or URL and need metadata, but it does not explicitly state when to use this tool over siblings like search_arxiv or get_semantic_scholar_paper. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch detailed metadata for a Semantic Scholar paper by paper ID.
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It fails to disclose details such as authentication, rate limits, or what 'detailed metadata' includes, leaving the agent uninformed about side effects or constraints.
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 with no fluff. It could be slightly improved by front-loading the key action, 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 presence of an output schema, the description does not need to detail return values. However, it omits context like how to obtain a paper ID and what 'detailed metadata' covers, making it marginally adequate for a simple tool.
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 should compensate by explaining the 'paper_id' parameter format or source, but it only restates the purpose. The schema merely repeats the parameter name, so the description adds minimal value.
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 action ('Fetch'), the resource ('detailed metadata for a Semantic Scholar paper'), and the method ('by paper ID'). It effectively distinguishes from sibling tools like 'search_semantic_scholar' (search) and 'get_arxiv_paper' (arXiv-specific).
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 (e.g., 'search_semantic_scholar'), prerequisites, or limitations. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an arXiv PDF, extract text from the first pages, and return a reading pack for analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pages | No | ||
| max_characters | No | ||
| arxiv_id_or_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully explain behavior. It mentions downloading and extracting text but does not clarify scope of 'first pages' or potential costs like rate limits, caching, or authentication needs.
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 front-loads the key actions. It is concise but could benefit from bullet points or structure for easier parsing.
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 three parameters and existence of an output schema, the description covers the overall purpose but omits parameter details and usage context relative to siblings. It is minimally complete for a read action with simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no parameter-specific details. The mention of 'first pages' hints at max_pages but does not explain any parameter's syntax or constraints, failing to compensate for the missing schema descriptions.
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 actions: download PDF, extract text from first pages, and return a reading pack. It distinguishes from sibling tools like download_arxiv_pdf (which only downloads) and get_arxiv_paper (which likely returns 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?
No guidance on when to use this tool versus alternatives like download_arxiv_pdf or search_arxiv. Lacks prerequisites or exclusions, leaving the agent to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arXiv and return normalized metadata for matching papers.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sort_by | No | relevance | |
| sort_order | No | descending | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the basic function with no disclosure of behavioral traits such as rate limits, authentication requirements, pagination, or limitations.
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 short (6 words) but this brevity sacrifices necessary details. It is not appropriately sized for a tool with 4 parameters and no annotations, resulting in under-specification.
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 having an output schema, the description is too minimal for a search tool. It fails to cover key context (e.g., what constitutes a match, how to use parameters) and relies entirely on the schema, which has no descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters (query, sort_by, sort_order, max_results). The agent gets no help beyond the bare 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 verb 'Search' and the resource 'arXiv', and specifies the output as 'normalized metadata'. It implicitly distinguishes from sibling tools like search_semantic_scholar by naming the source, but does not explicitly differentiate.
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 versus alternatives like get_arxiv_paper or search_semantic_scholar. The description lacks any use-case context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Semantic Scholar for papers and return normalized metadata sorted by citation count.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the burden. It discloses sort order and that metadata is normalized, but lacks details on rate limits, authentication, or what 'normalized' entails. It is adequate but not comprehensive.
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, concise and front-loaded with the key action. It could be slightly more structured, but it efficiently conveys the core functionality.
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 description covers the basic purpose and sort order. The existence of an output schema compensates for missing return value details. However, it does not address the breadth of possible queries or limitations, leaving some gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explicitly describe the query or max_results parameters, though the tool's purpose implies query is a search string. The mention of citation count sort gives some context, but parameter meaning is largely missing.
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 Semantic Scholar for papers and returns normalized metadata sorted by citation count. This distinguishes it from sibling tools like search_arxiv (different source) and get_semantic_scholar_paper (specific 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 versus alternatives. It does not mention prerequisites, limitations, or contexts where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a specific action (search, get, download, align, digest, export) or a specific source (arXiv vs Semantic Scholar), with no overlap in purpose. For example, search_arxiv and search_semantic_scholar clearly differ by source.
All tool names follow a consistent verb_noun pattern using snake_case, with clear action and target (e.g., search_arxiv, get_arxiv_paper, download_arxiv_pdf). The naming is predictable and uniform.
With 10 tools, the surface is well-scoped for a paper search and retrieval domain. Each tool serves a distinct need without being excessive or insufficient.
The tools cover the full workflow: searching both sources, fetching metadata, downloading PDFs, aligning cross-source papers, building digests, and exporting citations. No obvious gaps exist for the stated purpose.
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.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
Search arXiv and ACL Anthology, retrieve citations and references, and browse web sources to accel…
Search arXiv, fetch paper metadata, and read full-text content.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaoxiaoxiaotao/paper-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server