Provides a tool to search arXiv's API for academic papers, returning titles, arXiv IDs, abstract and PDF URLs, publication dates, years, authors, DOIs, and abstracts.
Integrates with Crossref's API, providing a tool to search the works database, returning titles, DOIs, authors, journals, years, and abstracts.
Provides a tool to search Semantic Scholar's Graph API for academic papers, returning titles, years, venues, authors, external IDs, abstracts, and open-access PDF URLs.
Click on "Deploy 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., "@literature-mcp find recent arXiv papers on diffusion models and extract the full text of the top one"
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 that gives an agent direct search
access to the main academic literature APIs plus PDF full-text extraction. It is a
thin wrapper: each tool calls one upstream API and returns that API's own fields,
rather than merging everything into a normalised record. That matters when you want
per-source details — arXiv's pdf_url, Semantic Scholar's openAccessPdf, Crossref's
container-title — that an aggregator would drop.
Tool | Upstream | What it returns |
|
| title, arXiv id, abs/pdf URLs, published date, year, authors, DOI, abstract |
|
| title, DOI, authors, journal, year, abstract |
|
| title, year, venue, authors, external ids, abstract, open-access PDF URL |
|
| title, URL, relevance score, snippet — web results, lower confidence than the paper databases |
|
| clean readable text of one web page |
| local file or URL (PyMuPDF) | page count and full extracted text; downloads the PDF first if given a URL |
The first three need no credentials. search_tavily and extract_url require a
Tavily API key. No key is hard-coded in the source — everything is read from the
environment or a .env file next to the package.
Every search tool takes optional year_from / year_to filters and caps result
counts at 50 to stay inside the upstream rate limits. HTTP 429 responses are retried
once with a short backoff.
Related MCP server: paper-search-mcp
Requires Python 3.11+ and uv.
git clone https://github.com/SinCircle/literature-mcp.git
cd literature-mcp
cp .env.example .env # then edit .env and add your keys
uv syncThe server communicates over stdio and writes only logs to stderr, so it will not corrupt the JSON-RPC stream. Point any MCP client at:
uv run --project /absolute/path/to/literature-mcp literature-mcpAll settings are optional and read from the environment (via .env or exported
variables):
Variable | Purpose |
| Required for |
| Sent to Crossref's polite pool and used in the |
| Optional; raises Semantic Scholar rate limits above the shared public tier. |
| Where |
uv run python -c "
import asyncio, literature_mcp.server as s
print([t.name for t in asyncio.run(s.mcp.list_tools())])
"Expect the six tool names listed above. To smoke-test a live call without an agent:
uv run python -c "
import asyncio
from literature_mcp.server import search_crossref
print(asyncio.run(search_crossref('Kalman filter', rows=2)))
"search_crossref is the friendliest target for a smoke test: it needs no API key and
its rate limit is far more forgiving than arXiv's, which throttles aggressively and
returns HTTP 429 if you call it more than a few times a minute.
The search tools return metadata only. Use read_paper_pdf for the text, or the
open_access_pdf / pdf_url fields to find a copy.
read_paper_pdf returns an empty text plus a note when a PDF is scanned images
with no text layer; run those through OCR yourself.
Results are returned in upstream order. No ranking, deduplication, or cross-source merging is applied — that is deliberate, and left to the caller.
Tool outputs are truncated (read_paper_pdf at max_chars, Tavily snippets at a
few thousand characters) to keep responses inside an agent's context budget.
MIT — see LICENSE.
Extract clean, readable page content from a URL via Tavily (api.tavily.com/extract).
Requires TAVILY_API_KEY. Returns the extracted raw content for each result URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It usefully discloses the API dependency (TAVILY_API_KEY) and the return shape (raw content per result URL), but omits failure modes, rate limits, and whether the URL count is bounded.
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 tight sentences with zero waste. Action and provider are front-loaded, and the auth/return notes follow concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essentials: what it does, the external dependency, and the return shape. Given only one parameter, no output schema, and no annotations, this is nearly sufficient, though it could mention expected input format (e.g., full URL vs. scheme requirements).
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?
Only one parameter and zero schema description coverage. The description clarifies that it accepts a URL and implies per-URL extraction, and notes content is 'raw' which hints at the output format. Baseline 4 for a single-param tool with a reasonably explained parameter.
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?
States a specific verb (extract) and resource (clean readable page content from a URL) and names the underlying provider. It distinguishes from search_* siblings by being the content-retrieval step, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: fetching content from a known URL, contrasted with sibling search tools that discover URLs. However, no explicit when-to-use vs. when-not or direct callout of alternatives like search_tavily.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the full text of a PDF given a local file path or an http(s) URL.
If given a URL, the PDF is downloaded to the server's pdf dir first. Returns
local_path, page_count, char count and the extracted text (truncated to
max_chars, or one page if page is given). Scanned PDFs with no text layer
return an empty text plus a note telling you to run the file through OCR.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| max_chars | No | ||
| path_or_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden and does reasonably well: it discloses the side effect of downloading a URL result to the server's pdf dir, the truncation behavior governed by max_chars, and the empty-text-plus-note outcome for scanned PDFs. It omits error behavior for invalid paths/URLs and any size or time limits, so it earns a 4 rather than a 5.
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?
Three sentences, no filler, front-loaded with purpose then download behavior then return/edge-case behavior. Slightly dense in the middle sentence but every clause carries 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?
For a 3-parameter read tool with no output schema, the description covers the return shape (local_path, page_count, char count, text), the download side effect, truncation and the scanned-PDF case. Remaining gaps, such as error handling and max_chars units, are minor.
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 supplies meaningful semantics for two of three parameters: path_or_url (local path or http(s) URL) and page (one page instead of the whole document), while max_chars is only implied by the word 'truncated'. This compensates for the schema gap without fully documenting every parameter's default and units.
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?
States a specific verb (extract) and resource (full text of a PDF) with accepted input forms (local path or http(s) URL). Clearly distinguishable from siblings, which are all search/extraction tools for other sources; none of them read a local PDF.
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?
Usage is implied by the input types (use a local path or URL), and the OCR note hints at a fallback path, but it never says when to prefer this over extract_url for a remote PDF or what to do instead for a scanned document beyond 'run through OCR'. No exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arXiv via its public API (export.arxiv.org/api/query).
Returns raw per-hit metadata: title, arxiv_id, abs/pdf URLs, published date, year, authors, DOI and abstract. Year filtering is applied locally on the published date.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| query | Yes | ||
| year_to | No | ||
| year_from | No | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the underlying API, the exact return payload fields, and the non-obvious behavior that year filtering happens locally on published date rather than server-side. It says nothing about rate limits, pagination, failure modes, or result caps, so it is helpful but incomplete.
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?
Three sentences, front-loaded with the identity and endpoint, then the return shape, then the filtering caveat. Every sentence carries information; only the parenthetical endpoint adds mild 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?
There is no output schema, but the description enumerates the returned fields well enough that an agent knows what comes back. The gap is input-side: five parameters with zero schema descriptions and no annotation coverage leave sort and max_results behavior unspecified.
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% across 5 parameters, so the description must compensate and largely does not. It clarifies the semantics of year_from/year_to (local filtering on published date), but query, sort, and max_results receive no explanation at all.
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?
States a specific verb+resource: searches arXiv via its documented public API endpoint. Naming arXiv implicitly separates it from search_crossref and search_semanticscholar, but it never explicitly says how it differs from those siblings, so it stops short of a 5.
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 when-to-use guidance, no exclusions, and the sibling tools (search_crossref, search_semanticscholar, search_tavily) are never referenced. The agent must infer from the source name alone which search backend to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Crossref via its public REST API (api.crossref.org/works).
Returns raw per-hit metadata: title, DOI, authors, journal, year and (stripped) abstract.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| query | Yes | ||
| year_to | No | ||
| year_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions the API endpoint and return fields but omits rate limits, authentication needs, pagination behavior, and whether the search is read-only. It does state the return fields, which is helpful, but significant behavioral gaps remain.
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, front-loading the core action and endpoint, then listing return fields in a single compact sentence. Every part 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?
No output schema exists, so the description should explain return values; it partially does by listing fields. However, with four parameters at 0% schema description coverage and no annotations, critical details like parameter meanings and behavioral traits are missing, leaving the agent under-informed.
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 of the four parameters (query, rows, year_from, year_to). With low coverage, the description must compensate but provides no parameter details.
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 a specific verb and resource ('Search Crossref via its public REST API') and names the endpoint, clearly identifying what the tool does. It does not explicitly differentiate from siblings like search_arxiv or search_semanticscholar, but the distinct API name provides implicit differentiation.
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 such as search_arxiv or search_semanticscholar. The description provides no context about appropriate use cases, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Semantic Scholar via its public Graph API (paper/search).
Returns raw per-hit metadata: title, year, publication date, venue, authors, external ids (DOI/arXiv/PubMed), abstract and open-access PDF URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| year_to | No | ||
| year_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that it uses a public Graph API and lists the returned fields, but it omits important traits such as rate limits, authentication requirements, pagination behavior, and whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and then detail the return format. Every sentence earns its place, though it could be slightly tighter.
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 helpfully explains return values, which is important because there is no output schema. However, it omits any parameter guidance and usage context, making it adequate but incomplete for a four-parameter 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%, and the description does not mention any of the four parameters (query, limit, year_from, year_to). Since the schema lacks parameter descriptions, the description fails to compensate, leaving parameter meanings entirely undocumented.
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 a specific verb (Search) and resource (Semantic Scholar via its public Graph API), even naming the endpoint (paper/search). However, it does not differentiate from sibling tools like search_crossref or search_arxiv, so an agent must infer when to choose this one.
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 explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. The description merely states what the tool does, leaving usage context implicit at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web search via Tavily (api.tavily.com/search). Requires TAVILY_API_KEY.
Returns title, url, relevance score and a content snippet per hit. Use for preprints/blog-level web statements; treat as lower confidence than paper databases.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| search_depth | No | advanced |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It usefully discloses return fields (title, url, relevance score, snippet) and a prerequisite (TAVILY_API_KEY), but omits rate limits, failure modes, or result freshness. For a search tool with no annotations, that's adequate but incomplete.
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?
Compact three-sentence structure: endpoint/auth first, return shape next, usage guidance last. Each sentence carries information, though the auth requirement could be folded tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, auth, return fields, and confidence tier, but with no annotations, no output schema, and 0% parameter coverage, the description leaves input semantics and safety/behavioral profile empty. It's minimal-viable for a 3-param search tool but not rich.
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 for three undocumented parameters. It never mentions query, max_results, or search_depth, leaving the enum and defaults entirely to the schema. The return-field list is helpful but doesn't address inputs.
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?
States a specific verb and resource ('Web search via Tavily') and even names the underlying endpoint. It distinguishes itself from sibling paper databases by scoping to 'preprints/blog-level web statements', a clear contrast with search_crossref, search_semanticscholar, and search_arxiv.
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?
Gives clear usage context ('Use for preprints/blog-level web statements') and a comparison to alternatives ('treat as lower confidence than paper databases'). However, it doesn't name explicit when-not-to-use conditions or route to a specific sibling tool by name, so it stops short of a 5.
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.
v0.1.0extract_urlread_paper_pdfsearch_arxivsearch_crossrefsearch_semanticscholarsearch_tavilyScored across 6 tools
Each tool targets a distinct data source or extraction type: four search tools for different databases (Crossref, Semantic Scholar, Tavily, arXiv), one for web page extraction, and one for PDF text extraction. No two tools overlap in purpose, and descriptions clearly differentiate their use cases.
All tool names follow a consistent verb_noun pattern: search_[source], extract_url, read_paper_pdf. Snake_case is used throughout with no mixing of conventions, making the set predictable.
Six tools are well-scoped for a literature search and reading server. Each adds a distinct capability (search across four sources, web extraction, PDF reading) without redundancy or bloat.
The surface covers multiple literature search sources, web search, web page extraction, and PDF reading, which fully supports the domain of finding and reading papers. No obvious gaps remain for the stated purpose.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Web research for agents: quality-scored Google search, webpage extraction, and deep research.
