用于学术研究的只读 MCP 服务器。让 LLM 代理能够搜索论文、查看元数据、追踪引用图谱、生成 BibTeX，并通过 FastMCP 工具读取开放获取 PDF 的全文。
Python 3.13+
可访问公共 API 的互联网连接（无需 API 密钥）
Related MCP server: scholar-mcp
API | 作用 |
Semantic Scholar | 主要搜索、元数据、TLDR、引用图谱。优先尝试。 |
OpenAlex | 当 Semantic Scholar 被限流时自动回退，同时用于开放获取 PDF 解析。 |
arXiv | 专用预印本搜索（ |
DBLP | 会议论文集调查（ |
Crossref | BibTeX 生成（ |
PyMuPDF | PDF 文本提取。 |
Semantic Scholar 在无密钥使用时会被限流，因此每个请求都会以指数退避方式重试（遵循 Retry-After），然后才回退到 OpenAlex。结果始终会告知代理使用了哪个数据源。arXiv API 强制约 3 秒的间隔规则，服务器会遵守；DBLP 在快速连续请求时会重置连接，因此会议流页面也以 3 秒的礼貌延迟获取。
所有易失效的 API 响应、搜索结果、会议论文集语料库和 PDF 都缓存在 ~/.cache/research-mcp/ 下的磁盘中（api/ 用于 JSON 响应，pdf/ 用于下载的 PDF）：
新鲜的缓存命中会即时返回——重复查询不会访问网络。
会议语料库（从 DBLP 页面组装）整体缓存，因此即使 DBLP 丢失某个页面，重新调查会议议程也能即时完成。
过期回退：如果 API 宕机或限流，仍会提供最后一次缓存的响应，因此代理仍能获得答案。
缓存 TTL：arXiv 和 BibTeX 为 7 天（数据稳定），搜索/元数据和 DBLP 为 24 小时。可通过 RESEARCH_MCP_CACHE_DIR 覆盖缓存位置。
在编码代理的 MCP 配置中注册服务器。例如，在 Opencode 的 opencode.json 中：
{
"mcp": {
"research-mcp": {
"command": [
"uvx",
"--from",
"git+https://github.com/404Simon/research-mcp",
"research-mcp"
],
"enabled": true,
"type": "local"
}
}
}变量 | 用途 |
| 设置后可保证 1 RPS 和更高的可靠性（否则回退到 OpenAlex）。 |
| API 响应和 PDF 的缓存位置。默认： |
search_papers按关键词搜索学术论文，可选用会议和年份筛选。返回结构化结果，包含标题、年份、会议、作者、DOI、摘要、引用次数，以及可用的开放获取 PDF 链接。
参数 | 类型 | 描述 |
|
| 搜索词 |
|
| 按会议筛选，例如 |
|
| 最早出版年份 |
|
| 最晚出版年份 |
|
| 最大结果数（默认 20） |
|
|
|
source="arxiv" 搜索 arXiv 预印本 API，是按确切名称查找特定近期论文的推荐方式，例如 query='ti:"carbon intensity" AND abs:forecast'（arXiv 字段语法原样传递）。所有结果都会缓存，因此重复搜索即时完成。
venue_proceedings调查某会议的实际论文集（实际发表的内容）。用于检查论文想法是否适合 ACM e-Energy 等会议。
参数 | 类型 | 描述 |
|
| 会议名称（例如 |
|
| 仅查看某一年的论文（例如 |
|
| 主题筛选；论文按标题关键词重叠度排序 |
|
| 最大结果数（默认 20） |
完整会议语料库从 DBLP 获取（分页超过其 100 条上限），在客户端排序，并整体缓存——重新调查即时完成。
{"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_details论文的完整元数据。接受 DOI（例如 10.1109/tpwrs.2018.2823641）、arXiv ID（例如 2408.03506、arXiv:2408.03506 或 arxiv.org/abs/... URL）或 OpenAlex ID。
参数 | 类型 | 描述 |
|
| DOI、arXiv ID 或 OpenAlex ID |
返回标题、作者、会议、年份、摘要、TLDR、引用次数、DOI 和开放获取 PDF：
get_citation_graph向前或向后追踪论文的引用，进行滚雪球式搜索。
参数 | 类型 | 描述 |
|
| DOI、OpenAlex ID（ |
|
|
|
|
| 最大结果数（默认 20） |
get_bibtex为 DOI 生成 BibTeX 条目。使用 Crossref 的原生转换；回退到从 OpenAlex 元数据本地生成（处理 Crossref 不认识的 arXiv DOI）。
参数 | 类型 | 描述 |
|
| 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_text下载开放获取 PDF 并使用 PyMuPDF 提取文本。传入 DOI、arXiv ID（例如 2408.03506）或直接 PDF URL。PDF 缓存在本地（~/.cache/research-mcp/pdf/）。
参数 | 类型 | 描述 |
|
| DOI、arXiv ID 或 |
|
| 截断返回文本（默认 50000） |
|
| 在本地缓存 PDF（默认 |
返回提取的文本、页数、来源 URL 和缓存路径。如果未找到开放获取副本，代理会收到明确消息，告知其搜索 OA 副本或直接传入 PDF URL。
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 extraction无需 API 密钥。运行 uv sync && uv run research-mcp 通过 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.
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.
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
