학술 연구용 읽기 전용 MCP 서버. LLM 에이전트가 논문 검색, 메타데이터 확인, 인용 그래프 추적, BibTeX 생성, 오픈 액세스 PDF 전문 읽기를 모두 FastMCP 도구를 통해 수행할 수 있게 해줍니다.
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는 키 없이 사용하면 속도 제한이 걸리므로 모든 요청은 OpenAlex로 대체되기 전에 지수 백오프로 재시도됩니다(Retry-After 존중). 결과는 항상 에이전트에게 어떤 소스가 사용되었는지 알려줍니다. arXiv API는 ~3 s 간격 규칙을 적용하며 서버는 이를 준수합니다. 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"
}
}
}Variable | Purpose |
| 보장된 1 RPS와 더 높은 안정성을 위해 설정(그렇지 않으면 OpenAlex로 대체). |
| API 응답과 PDF가 캐시되는 위치. 기본값: |
search_papers선택적 학술대회 및 연도 필터로 키워드를 사용해 학술 논문을 검색합니다. 제목, 연도, 학술대회, 저자, DOI, 초록, 인용 횟수, 가능한 경우 오픈 액세스 PDF 링크가 포함된 구조화된 결과를 반환합니다.
Argument | Type | Description |
|
| 검색어 |
|
| 학술대회로 필터링, 예: |
|
| 가장 이른 출판 연도 |
|
| 가장 최근 출판 연도 |
|
| 최대 결과 수(기본 20) |
|
|
|
source="arxiv"는 arXiv 프리프린트 API를 검색하며 정확한 이름으로 특정 최신 논문을 찾는 권장 방법입니다(예: query='ti:"carbon intensity" AND abs:forecast' — arXiv 필드 구문은 그대로 전달됨). 모든 결과가 캐시되므로 반복 검색은 즉시 이루어집니다.
venue_proceedings학술대회의 프로시딩(실제로 게시되는 내용)을 조사합니다. 논문 아이디어가 ACM e-Energy 같은 학회에 맞는지 확인하는 데 사용하세요.
Argument | Type | Description |
|
| 학술대회 이름(예: |
|
| 특정 연도의 논문만(예: |
|
| 주제 필터; 논문은 제목-키워드 중복도로 순위가 매겨짐 |
|
| 최대 결과 수(기본 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를 허용합니다.
Argument | Type | Description |
|
| DOI, arXiv ID 또는 OpenAlex ID |
제목, 저자, 학술대회, 연도, 초록, TLDR, 인용 횟수, DOI 및 오픈 액세스 PDF를 반환합니다:
get_citation_graph스노우볼 검색을 위해 논문의 인용을 앞뒤로 추적합니다.
Argument | Type | Description |
|
| DOI, OpenAlex ID( |
|
|
|
|
| 최대 결과 수(기본 20) |
get_bibtexDOI에 대한 BibTeX 항목을 생성합니다. Crossref의 네이티브 변환을 사용하며 OpenAlex 메타데이터에서의 로컬 생성으로 대체합니다(Crossref가 모르는 arXiv DOI 처리).
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_text오픈 액세스 PDF를 다운로드하고 PyMuPDF로 텍스트를 추출합니다. DOI, arXiv ID(예: 2408.03506) 또는 직접 PDF URL을 전달하세요. PDF는 로컬에 캐시됩니다(~/.cache/research-mcp/pdf/).
Argument | Type | Description |
|
| 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 extractionAPI 키가 필요 없습니다. 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
