Allows searching and retrieving papers from the arXiv preprint repository.
Allows searching and retrieving papers from Semantic Scholar, with optional API key for improved rate limits.
Allows exporting selected papers to a Zotero user or group library.
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., "@Open Source Literature MCP screen recent papers on single-cell multi-omics in cancer"
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.
An MCP server for automatic literature discovery and screening across OpenAlex, Semantic Scholar, and arXiv.
The server keeps intermediate raw results, normalized records, and deduped candidates internal. MCP clients receive only the final selected papers plus structured metadata.
auto_literature_screen: Searches selected sources, dedupes by DOI/arXiv ID/title, screens, ranks, and returns final papers.
discover_papers: Alias for auto_literature_screen.
expand_related_papers: Expands a Semantic Scholar seed paper with related recommendations, then screens and ranks.
export_to_zotero: Exports final selected papers to a Zotero user or group library.
generate_research_ideas: Generates evidence-backed research ideas from a topic and selected papers.
review_research_idea: Reviews one proposed idea against selected papers for novelty, feasibility, and evidence fit.
literature_mcp_health: Shows server metadata and whether a Semantic Scholar API key is configured.
Related MCP server: paper-search
npm install
npm run build
npm testOptional environment variables (PowerShell):
$env:SEMANTIC_SCHOLAR_API_KEY = "your_key"
$env:OPENALEX_MAILTO = "you@example.com"Or with bash:
export SEMANTIC_SCHOLAR_API_KEY=your_key
export OPENALEX_MAILTO=you@example.comSemantic Scholar works without a key, but a key usually improves rate limits.
OPENALEX_MAILTO opts into OpenAlex's faster "polite pool"; set it to a real contact email.
Use the built server:
{
"mcpServers": {
"opensource-literature": {
"command": "node",
"args": ["D:/demo/opensourse-mcp/dist/index.js"]
}
}
}Call export_to_zotero with the results array returned by auto_literature_screen.
{
"papers": [],
"zoteroApiKey": "your_zotero_key",
"zoteroUserId": "123456"
}Use zoteroGroupId instead of zoteroUserId for a group library.
These two tools are heuristic scaffolding, not a language-model judgment. Ideas come from keyword/term overlap and research-gap templates, and the scores are relative heuristics meant to triage, not to rank definitively. The method and gap vocabularies default to a biomedical bias; override them with candidateMethods and focusGaps for other fields.
Use the results array returned by auto_literature_screen as selected_papers.
{
"topic": "single-cell multi-omics integration cancer prognosis",
"selected_papers": [],
"count": 5
}Then review a specific idea:
{
"topic": "single-cell multi-omics integration cancer prognosis",
"idea": "Build a cell-type aware survival prediction benchmark for missing-modality single-cell multi-omics data.",
"selected_papers": []
}For development:
{
"mcpServers": {
"opensource-literature-dev": {
"command": "npm",
"args": ["run", "dev"],
"cwd": "D:/demo/opensourse-mcp"
}
}
}{
"topic": "single-cell multi-omics integration cancer prognosis",
"yearFrom": 2020,
"limit": 10,
"sources": ["openalex", "semantic_scholar", "arxiv"],
"includePreprints": true,
"screeningCriteria": {
"mustInclude": ["single-cell"],
"prefer": ["multi-omics", "cancer prognosis", "survival prediction"],
"exclude": ["review", "editorial", "protocol"],
"minCitations": 5
}
}Scoring combines:
query term overlap in title/abstract
required and preferred phrases
DOI/arXiv metadata quality
cross-source confirmation
citation counts
recency
Intermediate candidate tables are intentionally not exposed as a workflow step.
Search OpenAlex, Semantic Scholar, and arXiv, then internally merge, dedupe, screen, and rank papers. Returns only final selected papers.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Research topic or query. | |
| yearFrom | No | ||
| yearTo | No | ||
| limit | No | ||
| perSourceLimit | No | ||
| sources | No | ||
| includePreprints | No | ||
| screeningCriteria | No | ||
| semanticScholarApiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits fully. It mentions multi-source search and internal processing but omits details like rate limits, authorization needs (apart from an optional API key), whether it is read-only, or if it is potentially long-running. The description provides basic transparency but lacks 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 two sentences, each adding value. It front-loads the main action and efficiently conveys the pipeline without redundancy. No waste.
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 (9 parameters, nested objects, no output schema), the description lacks details on output format, screening criteria behavior, ranking method, and potential limitations. It does not address the return structure, which is critical for an agent to use the result.
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 only 11%, so the description should compensate by explaining parameter roles. However, the description does not clarify the purpose of parameters like yearFrom, yearTo, limit, perSourceLimit, screeningCriteria, or semanticScholarApiKey. Only 'topic' is vaguely implied. This leaves many parameters underdocumented.
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 searches three specific sources (OpenAlex, Semantic Scholar, arXiv) and performs internal merge, dedupe, screen, and rank operations. It specifically says it returns only final selected papers, distinguishing it from sibling tools like discover_papers which likely do not screen.
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 does not provide any guidance on when to use this tool versus alternatives like discover_papers or expand_related_papers. It neither states prerequisites nor when not to use it, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias for auto_literature_screen. It keeps raw and deduped candidates internal and returns final selected papers only.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Research topic or query. | |
| yearFrom | No | ||
| yearTo | No | ||
| limit | No | ||
| perSourceLimit | No | ||
| sources | No | ||
| includePreprints | No | ||
| screeningCriteria | No | ||
| semanticScholarApiKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions internal steps (keeping candidates) but omits side effects, permissions, rate limits, or return structure. For a 9-parameter tool, this is insufficient transparency.
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 concise at two sentences, front-loading the alias information. It is well-structured but sacrifices necessary depth for brevity.
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 (9 parameters, nested objects, no output schema, no annotations), the description is critically incomplete. It lacks return value description, parameter guidance, and usage prerequisites, making it inadequate for reliable agent invocation.
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 only 11% (only 'topic' described). The description adds no information about any parameters, failing to compensate for the low schema coverage. Parameters like 'screeningCriteria' need explanation but are entirely ignored.
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 alias for auto_literature_screen and explains it keeps raw/deduped candidates internal and returns final selected papers. This effectively distinguishes it from sibling tools like expand_related_papers by specifying the internal process and output.
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 only notes it is an alias for auto_literature_screen but provides no guidance on when to use this tool versus alternatives. It does not mention any conditions or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export selected final papers to a Zotero user or group library. Intended for results from auto_literature_screen.
| Name | Required | Description | Default |
|---|---|---|---|
| papers | Yes | ||
| zoteroApiKey | Yes | ||
| zoteroUserId | No | ||
| zoteroGroupId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explain behavioral traits beyond the basic function. It does not mention authentication needs, rate limits, or error handling, which are important for a tool that interacts with an external API.
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?
Two concise sentences with no unnecessary words. Front-loaded with key 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 4 parameters, a complex nested object (papers), and no output schema, the description provides no information about return values, prerequisites, or side effects. It is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no details about the parameters. It does not explain the purpose or format of any fields, leaving the agent to infer from names alone.
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 provides a clear verb ('Export'), resource ('selected final papers to a Zotero user or group library'), and explicitly distinguishes from siblings by noting it is intended for results from 'auto_literature_screen'.
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 clearly states that this tool is for use after 'auto_literature_screen', providing clear context. It does not explicitly list exclusions or alternatives, but the sibling list offers implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce heuristic, keyword-based research-idea scaffolding from a topic and selected papers. Ideas are derived from term overlap and research-gap templates, not from a language model, and scores are relative heuristics. Does not run experiments or execute code.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| selected_papers | Yes | ||
| count | No | ||
| candidateMethods | No | Optional method phrases to look for in the selected papers (override the biomedical defaults). | |
| focusGaps | No | Optional research-gap phrases to consider alongside the generic defaults. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It honestly states that ideas are derived from term overlap and gap templates, not a language model, and that scores are relative heuristics. It also clarifies that no experiments or code execution occur.
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 two sentences, covering purpose, method, and limitations with no wasted words. It is front-loaded with the core function.
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 absence of output schema and annotations, the description provides adequate context about input, method, and boundaries. It could be improved by briefly stating what the output contains (e.g., idea titles, scores) but is largely 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?
Schema description coverage is 40% (only candidateMethods and focusGaps have descriptions). The tool description does not explain the meaning or usage of parameters like topic or selected_papers beyond what the schema fields imply. It adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces heuristic, keyword-based research-idea scaffolding from a topic and papers. It distinguishes itself from siblings like auto_literature_screen or discover_papers by focusing on idea generation, not screening or 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?
The description implies when to use (for generating ideas based on papers) and clarifies limitations (not from LLM, no experiments). However, it does not explicitly state when not to use or mention specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return server metadata and configured optional API keys.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool returns data, implying a read-only, non-destructive operation, but does not explicitly disclose safety, permissions, or side effects. Basic transparency is present but not enhanced.
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, no wasted words, front-loaded with purpose. Perfectly concise.
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 zero-parameter tool with no output schema, the description is nearly complete. It could mention that the tool is for health checks or diagnostics, but the current text covers the core purpose. Slight lack of detail on response format is acceptable given simplicity.
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?
No parameters in schema, so schema coverage is 100%. Baseline 4 is appropriate as description adds no parameter info but is not required to. The mention of 'configured optional API keys' gives context about the data returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns server metadata and optional API keys. The verb 'Return' and resource 'server metadata and configured optional API keys' are specific and distinct from siblings like 'discover_papers' or 'export_to_zotero'.
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?
Description implies usage for inspecting server configuration, but no explicit guidance on when to use versus siblings or when not to use. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristically review a proposed research idea against selected papers, scoring novelty, feasibility, and literature support from keyword overlap. Scores are relative heuristics, not a language-model judgment.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| idea | Yes | ||
| selected_papers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that scoring is heuristic and based on keyword overlap, not language-model judgment, which gives transparency into the tool's behavior. However, it does not explain the output format or any 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?
The description is a single, well-structured sentence that conveys the action, scoring dimensions, and nature of the tool without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's three parameters and complex paper object, the description omits guidance on required paper fields and does not describe the output. This lack of completeness forces the agent to guess, especially for a tool with no output schema and no annotations.
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 meaning beyond parameter names. The complex 'selected_papers' object with many optional fields lacks guidance on which fields are important, leaving the agent without sufficient context.
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 reviews a research idea against selected papers, scoring novelty, feasibility, and literature support. It distinguishes from siblings by specifying the heuristic, keyword-based approach and that it is not a language-model judgment.
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 a user has a research idea and specific papers to evaluate. It notes scores are relative heuristics, hinting at limitations, but does not explicitly state when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0auto_literature_screendiscover_papersexpand_related_papersexport_to_zoterogenerate_research_ideasliterature_mcp_healthreview_research_ideaauto_literature_screen and discover_papers are exact aliases, creating confusion and redundancy. Other tools are distinct but the duplication lowers disambiguation.
Most tools use verb_noun pattern (e.g., export_to_zotero, generate_research_ideas), but auto_literature_screen and literature_mcp_health deviate. The naming is readable but not fully consistent.
7 tools is a reasonable number for a literature MCP. The presence of two aliases slightly inflates the count, but overall it's well-scoped.
Covers search, related-paper expansion, export, and idea generation/review. Missing are operations to view intermediate results, manually curate selections, or import from other sources, which are notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/simthw/opensourse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
