Enables searching the arXiv preprint repository, looking up papers by arXiv ID, and downloading full-text PDFs of open-access preprints.
Offers venue proceedings surveys and venue-scoped searches, allowing agents to explore what papers a conference actually accepts.
Provides access to Semantic Scholar's scholarly search, paper metadata, TLDRs, and citation graph traversal through the MCP server.
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., "@research-mcp search for recent papers on energy-efficient data centers"
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.
Read-only MCP server for academic research. Lets an LLM agent search papers, inspect metadata, follow citation graphs, generate BibTeX, and read full texts of open-access PDFs — all via FastMCP tools.
Python 3.13+
Internet access to the public APIs (no API key required)
Related MCP server: scholar-mcp
API | Role |
Semantic Scholar | Primary search, metadata, TLDRs, citation graph. Tried first. |
OpenAlex | Automatic fallback when Semantic Scholar is rate-limited, plus open-access PDF resolution. |
arXiv | Dedicated preprint search ( |
DBLP | Venue proceedings surveys ( |
Crossref | BibTeX generation ( |
PyMuPDF | PDF text extraction. |
Semantic Scholar is rate-limited when used without a key, so every request retries with exponential backoff (honoring Retry-After) before falling back to OpenAlex. Results always tell the agent which source was used. The arXiv API enforces a ~3 s spacing rule, which the server honors; DBLP resets connections on rapid sequential requests, so venue-stream pages are fetched with a 3 s politeness delay too.
All brittle API responses, search results, venue proceedings corpora, and PDFs are cached on disk under ~/.cache/research-mcp/ (api/ for JSON responses, pdf/ for downloaded PDFs):
Fresh cache hits are served instantly — repeat queries don't touch the network.
Venue corpora (assembled from DBLP pages) are cached as a whole, so re-surveys of a conference program are instant even if DBLP drops a page.
Stale fallback: if an API is down or rate-limiting, the last cached response is served anyway, so the agent still gets an answer.
Cache TTLs: 7 days for arXiv and BibTeX (stable data), 24 h for search/metadata and DBLP. Override the location with RESEARCH_MCP_CACHE_DIR.
Register the server in your coding agent's MCP configuration. For example, in Opencode's opencode.json:
{
"mcp": {
"research-mcp": {
"command": [
"uvx",
"--from",
"git+https://github.com/404Simon/research-mcp",
"research-mcp"
],
"enabled": true,
"type": "local"
}
}
}Variable | Purpose |
| Set for guaranteed 1 RPS and higher reliability (falls back to OpenAlex otherwise). |
| Where API responses and PDFs are cached. Default: |
search_papersSearch academic papers by keyword with optional venue and year filters. Returns structured results with title, year, venue, authors, DOI, abstract, citation count, and an open-access PDF link when available.
Argument | Type | Description |
|
| Search terms |
|
| Filter by venue, e.g. |
|
| Earliest publication year |
|
| Latest publication year |
|
| Max results (default 20) |
|
|
|
source="arxiv" searches the arXiv preprint API and is the recommended way to find specific recent papers by exact name, e.g. query='ti:"carbon intensity" AND abs:forecast' (arXiv field syntax is passed through verbatim). All results are cached, so repeat searches are instant.
venue_proceedingsSurvey a venue's proceedings (what actually gets published there). Use this to check whether a paper idea fits a conference like ACM e-Energy.
Argument | Type | Description |
|
| Venue name (e.g. |
|
| Only papers from one year (e.g. |
|
| Topic filter; papers are ranked by title-keyword overlap |
|
| Max results (default 20) |
The full venue corpus is fetched from DBLP (paginated past its 100-hit cap), ranked client-side, and cached as a whole — re-surveys are instant.
{"results": [
{"title": "Reinforcement Learning Approach for Optimal Distributed Energy Management in a Microgrid",
"year": 2018, "venue": "IEEE Transactions on Power Systems",
"authors": ["Elham Foruzan", "Leen-Kiat Soh", "S. Asgarpoor"],
"doi": "10.1109/tpwrs.2018.2823641",
"abstract": "In this paper, a multiagent-based model is used ...",
"citation_count": 297, "open_access_pdf": null,
"source": "openalex"}],
"note": "(Semantic Scholar unavailable — used OpenAlex instead: RequestFailed)",
"count": 1}paper_detailsFull metadata for a paper. Accepts a DOI (e.g. 10.1109/tpwrs.2018.2823641), an arXiv ID (e.g. 2408.03506, arXiv:2408.03506, or an arxiv.org/abs/... URL), or an OpenAlex ID.
Argument | Type | Description |
|
| DOI, arXiv ID, or OpenAlex ID |
Returns title, authors, venue, year, abstract, TLDR, citation count, DOI, and open-access PDF:
get_citation_graphFollow a paper's citations forward or backward for snowball searching.
Argument | Type | Description |
|
| DOI, OpenAlex ID ( |
|
|
|
|
| Max results (default 20) |
get_bibtexGenerate a BibTeX entry for a DOI. Uses Crossref's native transform; falls back to local generation from OpenAlex metadata (handles arXiv DOIs that Crossref doesn't know).
Argument | Type | Description |
|
| DOI |
@article{Foruzan_2018, title={Reinforcement Learning Approach for Optimal Distributed Energy Management in a Microgrid}, volume={33}, ..., author={Foruzan, Elham and Soh, Leen-Kiat and Asgarpoor, Sohrab}, year={2018} }read_paper_full_textDownload an open-access PDF and extract its text with PyMuPDF. Pass a DOI, an arXiv ID (e.g. 2408.03506), or a direct PDF URL. PDFs are cached locally (~/.cache/research-mcp/pdf/).
Argument | Type | Description |
|
| DOI, arXiv ID, or |
|
| Truncate returned text (default 50000) |
|
| Cache the PDF locally (default |
Returns the extracted text, page count, source URL, and cached path. If no open-access copy is found, the agent gets a clear message telling it to search for an OA copy or pass a PDF URL directly.
src/
main.py # FastMCP server, tool definitions, fallback orchestration
client.py # HTTP client with retry/backoff (429/5xx, Retry-After)
cache.py # Disk cache (~/.cache/research-mcp/) with stale fallback
semanticscholar.py # Semantic Scholar: search, details, citations (optional API key)
openalex.py # OpenAlex: search, details, citation graph, OA-PDF resolution
arxiv.py # arXiv API: search, ID lookups (3 s politeness, 7-day cache)
dblp.py # DBLP: venue proceedings + venue-scoped search (paged corpus cache)
crossref.py # Crossref: BibTeX transform + local fallback generator
pdf.py # PDF download/validation/caching + PyMuPDF text extractionNo API key required. Run uv sync && uv run research-mcp to start the server over stdio.
Generate a BibTeX citation entry for a paper by DOI via Crossref (falls back to local generation from OpenAlex metadata). Result is cached.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses useful traits beyond the name: Crossref lookup, fallback to OpenAlex metadata, local generation, and caching. This gives the agent meaningful expectations about execution and repeat calls.
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 with no filler. The primary action is front-loaded, fallback behavior is clearly parenthesized, and caching is stated in a standalone sentence. Every clause adds 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?
The tool is simple (one parameter, no annotations, output schema present), and the description covers data sources, fallback behavior, and caching. It could add polish by mentioning failure behavior for unknown DOIs, but the core information an agent needs to select and invoke it is present.
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 for the single parameter is 0%, so the description must compensate. It does so by explaining that the paper is identified 'by DOI', giving semantic meaning to the only required parameter. It lacks format/example guidance, but for a single string parameter this is sufficient.
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 ('Generate') and a specific output resource ('BibTeX citation entry for a paper by DOI'). It also names the data sources (Crossref, with OpenAlex fallback), which makes it easy to distinguish from siblings like paper_details and get_citation_graph.
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 clear use case: obtain a BibTeX citation for a known DOI. It does not explicitly name alternatives or exclusion conditions, but the purpose is specific enough that an agent can infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow a paper's citation graph. paper_id is a DOI, an OpenAlex ID (W...), or a Semantic Scholar paper ID. direction: "citing" (papers that cite this paper, forward search) or "referenced" (papers this paper cites, backward search). Returns structured results plus the data source used. Results are cached.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| paper_id | Yes | ||
| direction | No | citing |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 reveals that results are cached, that the response includes the data source used, and defines the traversal directions. It could additionally mention pagination or limit behavior, but the current disclosure is solid for a read-only lookup tool.
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 compact and front-loaded, with the core purpose in the first clause and each subsequent sentence carrying useful information. There is no filler or repetition of schema details that are already visible.
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 this tool's complexity, the description covers the essential invocation details: ID formats, direction semantics, result nature, and caching. Since an output schema is present, the description does not need to explain return fields, and no critical calling information is missing.
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 adds real meaning by enumerating paper_id formats (DOI, OpenAlex ID, Semantic Scholar ID) and explaining direction values. The limit parameter is left to schema/default semantics, which is a minor gap given its simplicity.
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 and resource ('Follow a paper's citation graph') and defines direction semantically. It is easily distinguishable from sibling tools like search_papers, paper_details, and get_bibtex because citation traversal is a unique operation.
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 concrete usage context by explaining accepted paper_id formats and the two direction modes with forward/backward semantics. It does not explicitly state when not to use the tool or name alternatives, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for a paper. Pass a DOI (e.g. "10.1109/tpwrs.2018.2823641"), an arXiv ID (e.g. "2407.19074", "arXiv:2407.19074", or an arxiv.org/abs/... URL), or an OpenAlex ID (W...). Semantic Scholar first, OpenAlex/Crossref fallback: title, authors, venue, year, abstract, TLDR, citation count, DOI, and open-access PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| doi_or_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 meaningful behavior: Semantic Scholar is tried first, with OpenAlex/Crossref as fallback, and it lists the specific fields returned. It does not mention rate limits or behavior for nonexistent IDs, but for a read-only lookup the disclosed behavior is solid.
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 compact and front-loaded with the core purpose. Every sentence adds value: the first states the operation, the second covers accepted inputs, and the third summarizes the fallback behavior and output fields. There is no fluff or repetition.
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 one-parameter read tool with an output schema, the description is largely complete it covers input formats, source preference, and returned fields. It misses explicit guidance on when to use siblings and what happens when an identifier is not found, but these are minor gaps given the tool's 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?
The schema only defines doi_or_id as a string with no further description, so the description must compensate. It does: it explains the three accepted identifier types with concrete examples for DOI, arXiv ID (bare, prefixed, and URL), and OpenAlex ID. This is complete parameter semantics.
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 ('Get full metadata for a paper') and specifies the resource: paper metadata retrieved by DOI, arXiv ID, or OpenAlex ID. It is distinct from the sibling tools such as search_papers or read_paper_full_text, though it does not explicitly call out those alternatives.
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 this tool: when you already have an identifier for a paper and want full metadata. It gives accepted ID formats and examples, but it does not explicitly say 'use search_papers when you lack an identifier' or otherwise state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full text of a paper. Pass a DOI, an arXiv ID (e.g. "2407.19074"), or a direct PDF URL. Resolves the open-access PDF automatically, downloads it (cached locally under ~/.cache/research-mcp/pdf/ by default), extracts the text with PyMuPDF, and returns up to max_chars characters.
Use paper_details or search_papers to find a paper's open_access_pdf first; pass that URL directly if DOI resolution finds no open-access copy.
| Name | Required | Description | Default |
|---|---|---|---|
| cache | No | ||
| max_chars | No | ||
| doi_or_pdf_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 discloses the full pipeline: it resolves the open-access PDF, downloads it, caches locally under ~/.cache/research-mcp/pdf/ by default, extracts text with PyMuPDF, and truncates to max_chars. This goes well beyond a bare verb, though it does not cover error behavior when no open-access version is found.
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 paragraphs, frontloaded with the action and accepted identifiers, then process details and usage advice. No redundant filler; every sentence adds operational 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?
For a 3-parameter tool with an output schema, the description covers all needed call context: accepted input formats, resolution strategy, download/caching behavior, truncation, and fallback advice. Nothing essential is missing.
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 clarifies the primary parameter accepts DOI, arXiv ID, or direct PDF URL, and explains max_chars controls truncation. The cache parameter is only implied via the caching default, so coverage is not complete but sufficient.
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 clear action ('Read the full text of a paper') and a specific resource (a paper identified by DOI, arXiv ID, or PDF URL). It contrasts with siblings such as search_papers and paper_details by focusing on full-text retrieval, so an agent can select it unambiguously.
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 second paragraph explicitly instructs the agent to use paper_details or search_papers to find the open_access_pdf first and to pass a direct URL if DOI resolution returns no open-access copy. This gives concrete when-to-use guidance and routing to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search academic papers by keyword. Returns structured results: title, year, venue, authors, DOI, abstract, citation count, and an open-access PDF link when available.
source:
"auto" (default): Semantic Scholar first, automatic OpenAlex fallback.
"semanticscholar" / "openalex": force one engine.
"arxiv": search the arXiv preprint API directly — best for finding specific recent papers by exact name. Supports arXiv field syntax in query, e.g. 'ti:"carbon intensity" AND abs:forecast'.
"dblp": search DBLP publications (supports venue).
Optionally filter by venue (e.g. "e-Energy"). Venue-scoped queries are routed through DBLP automatically, because OpenAlex has no usable venue filter. All results are cached on disk, so repeat searches are instant even if an API rate-limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| venue | No | ||
| source | No | auto | |
| year_end | No | ||
| year_start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 explains the automatic fallback from Semantic Scholar to OpenAlex, on-disk caching behavior, DBLP routing for venue queries, and the structured result format. This gives the agent a strong mental model of the tool's behavior beyond the schema.
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 front-loaded with the tool's purpose and return format, and the subsequent sections for sources and caching are informative rather than padded. It is somewhat long, but every sentence adds useful behavioral or selection detail.
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 return shape, source behavior, caching, and venue routing, which is substantial for a search tool. The main omissions are the limit and year-filter parameters, and there is no explicit guidance on when to use sibling tools instead, but the core invocation path is well supported.
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 description compensates for the 0% schema coverage by explaining the query, venue, and source parameters in detail, including source-specific syntax. However, it does not describe the limit, year_start, or year_end parameters, leaving a meaningful gap for a tool with six parameters and no 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 opens with a specific verb and resource: 'Search academic papers by keyword,' and enumerates the exact return fields (title, year, venue, authors, DOI, abstract, citation count, PDF link). This clearly distinguishes it from sibling tools like paper_details, get_citation_graph, and read_paper_full_text.
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 gives actionable guidance for source selection, such as marking arXiv as 'best for finding specific recent papers by exact name' and explaining that venue-scoped queries are routed through DBLP automatically. It does not explicitly contrast this tool with sibling tools, but it provides clear context for when to use it and how to choose among internal alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List papers published in a venue's proceedings (via DBLP) — for surveying what a conference like ACM e-Energy actually accepts. Returns title, year, authors, DOI.
venue: a venue name (e.g. "e-Energy") or a DBLP stream key (e.g. "conf/eenergy"). year: optional single year to filter proceedings (e.g. 2024). query: optional keyword to only return papers matching a topic (e.g. "carbon"). Results are cached, so re-surveys are instant.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| query | No | ||
| venue | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full transparency burden, and it does well: it discloses the data source (DBLP), the exact return fields (title, year, authors, DOI), and the caching behavior ('Results are cached'). It does not cover failure modes, rate limits, or data freshness, but the core behavioral profile is clearly communicated.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by compact parameter explanations and a useful caching note. It is slightly longer than strictly necessary due to the inline examples, but every element earns its place and none is redundant.
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 and there are no annotations, the description covers the essential call context: purpose, source, return fields, parameter semantics, and caching. The main gap is the undocumented 'limit' parameter, which may affect result completeness for large proceedings. Overall it is sufficiently complete for an agent to select and invoke the tool effectively.
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 for most parameters: venue is explained with both a display name and a DBLP stream key, year is explained as an optional filter, and query is explained as a keyword filter with examples. However, the 'limit' parameter is absent from the description entirely, so one of the four parameters remains semantically underspecified.
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 opens with a specific verb and resource: 'List papers published in a venue's proceedings (via DBLP)'. This clearly differentiates the tool from siblings like search_papers, paper_details, or get_bibtex by bounding it to a venue-scoped survey operation, and it even gives a concrete usage scenario ('ACM e-Energy').
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 clear context by explicitly framing the tool for surveying what a conference 'actually accepts', which tells an agent when this tool is useful. However, it does not explicitly mention alternative tools or state when not to use this one, so it stops short of full when/when-not guidance.
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.0get_bibtexget_citation_graphpaper_detailsread_paper_full_textsearch_papersvenue_proceedingsScored across 6 tools
Each tool targets a clearly distinct research workflow step: keyword search, metadata lookup by ID, citation graph traversal, venue-based survey, BibTeX generation, and full-text extraction. Even where search_papers supports a venue filter, venue_proceedings is clearly positioned as venue-first exploration, so an agent can reliably pick the right tool.
All names are readable and consistently snake_case, but they mix conventions: search_papers, get_citation_graph, get_bibtex, and read_paper_full_text are verb-led, while paper_details and venue_proceedings are bare noun phrases. This is a mixed pattern rather than a truly consistent verb_noun schema.
Six tools is well within the ideal range for a research assistant server. Each tool covers a distinct capability and none feels redundant or unnecessary for the stated domain of academic paper discovery and reading.
The tool surface covers the core academic research lifecycle: finding papers by keyword or venue, retrieving detailed metadata, exploring citations both forward and backward, reading full text, and generating BibTeX entries. There are no obvious dead ends or missing operations that would prevent an agent from completing a typical literature research workflow.
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.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Read-only MCP over an agentic SLR workspace with per-claim citation verification
Read-only MCP over an agentic SLR workspace with per-claim citation verification
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/404Simon/research-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
