Servidor MCP de solo lectura para investigación académica. Permite que un agente LLM busque artículos, inspeccione metadatos, siga grafos de citas, genere BibTeX y lea textos completos de PDF de acceso abierto, todo mediante herramientas FastMCP.
Python 3.13+
Acceso a Internet para las API públicas (no se requiere clave API)
Related MCP server: scholar-mcp
API | Rol |
Semantic Scholar | Búsqueda principal, metadatos, TLDR, grafo de citas. Se intenta primero. |
OpenAlex | Respaldo automático cuando Semantic Scholar está limitado por tasa, además de resolución de PDF de acceso abierto. |
arXiv | Búsqueda dedicada de preprints ( |
DBLP | Encuestas de actas de congresos ( |
Crossref | Generación de BibTeX ( |
PyMuPDF | Extracción de texto de PDF. |
Semantic Scholar está limitado por tasa cuando se usa sin clave, por lo que cada solicitud se reintenta con retroceso exponencial (respetando Retry-After) antes de recurrir a OpenAlex. Los resultados siempre indican al agente qué fuente se usó. La API de arXiv impone una regla de espaciado de ~3 s, que el servidor respeta; DBLP restablece las conexiones en solicitudes rápidas y secuenciales, por lo que las páginas de flujo de sedes se obtienen con un retraso de cortesía de 3 s también.
Todas las respuestas frágiles de API, resultados de búsqueda, corpus de actas de congresos y PDF se almacenan en caché en disco bajo ~/.cache/research-mcp/ (api/ para respuestas JSON, pdf/ para PDF descargados):
Aciertos de caché frescos se sirven al instante: las consultas repetidas no tocan la red.
Corpus de sedes (ensamblados desde páginas de DBLP) se almacenan en caché como un todo, por lo que re-encuestar un programa de conferencia es instantáneo incluso si DBLP pierde una página.
Respaldo obsoleto: si una API está caída o limitando la tasa, se sirve la última respuesta en caché de todos modos, para que el agente aún obtenga una respuesta.
TTL de caché: 7 días para arXiv y BibTeX (datos estables), 24 h para búsqueda/metadatos y DBLP. Sobrescribe la ubicación con RESEARCH_MCP_CACHE_DIR.
Registra el servidor en la configuración MCP de tu agente de codificación. Por ejemplo, en opencode.json de Opencode:
{
"mcp": {
"research-mcp": {
"command": [
"uvx",
"--from",
"git+https://github.com/404Simon/research-mcp",
"research-mcp"
],
"enabled": true,
"type": "local"
}
}
}Variable | Propósito |
| Configúrala para garantizar 1 RPS y mayor fiabilidad (de lo contrario, recurre a OpenAlex). |
| Dónde se almacenan en caché las respuestas de API y los PDF. Predeterminado: |
search_papersBusca artículos académicos por palabra clave con filtros opcionales de sede y año. Devuelve resultados estructurados con título, año, sede, autores, DOI, resumen, recuento de citas y un enlace a PDF de acceso abierto cuando está disponible.
Argumento | Tipo | Descripción |
|
| Términos de búsqueda |
|
| Filtrar por sede, p. ej. |
|
| Año de publicación más temprano |
|
| Año de publicación más reciente |
|
| Máximo de resultados (predeterminado 20) |
|
|
|
source="arxiv" busca en la API de preprints de arXiv y es la forma recomendada de encontrar artículos recientes específicos por nombre exacto, p. ej. query='ti:"carbon intensity" AND abs:forecast' (la sintaxis de campos de arXiv se pasa tal cual). Todos los resultados se almacenan en caché, por lo que las búsquedas repetidas son instantáneas.
venue_proceedingsEncuesta las actas de una sede (lo que realmente se publica allí). Úsalo para comprobar si una idea de artículo encaja en una conferencia como ACM e-Energy.
Argumento | Tipo | Descripción |
|
| Nombre de la sede (p. ej. |
|
| Solo artículos de un año (p. ej. |
|
| Filtro de tema; los artículos se clasifican por solapamiento de palabras clave en el título |
|
| Máximo de resultados (predeterminado 20) |
El corpus completo de la sede se obtiene de DBLP (paginado más allá de su límite de 100 resultados), se clasifica en el lado del cliente y se almacena en caché como un todo: las re-encuestas son instantáneas.
{"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_detailsMetadatos completos de un artículo. Acepta un DOI (p. ej. 10.1109/tpwrs.2018.2823641), un ID de arXiv (p. ej. 2408.03506, arXiv:2408.03506 o una URL arxiv.org/abs/...) o un ID de OpenAlex.
Argumento | Tipo | Descripción |
|
| DOI, ID de arXiv o ID de OpenAlex |
Devuelve título, autores, sede, año, resumen, TLDR, recuento de citas, DOI y PDF de acceso abierto:
get_citation_graphSigue las citas de un artículo hacia adelante o hacia atrás para búsqueda en bola de nieve.
Argumento | Tipo | Descripción |
|
| DOI, ID de OpenAlex ( |
|
|
|
|
| Máximo de resultados (predeterminado 20) |
get_bibtexGenera una entrada BibTeX para un DOI. Usa la transformación nativa de Crossref; recurre a la generación local a partir de metadatos de OpenAlex (maneja DOIs de arXiv que Crossref no conoce).
Argumento | Tipo | Descripción |
|
| 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_textDescarga un PDF de acceso abierto y extrae su texto con PyMuPDF. Pasa un DOI, un ID de arXiv (p. ej. 2408.03506) o una URL directa de PDF. Los PDF se almacenan en caché localmente (~/.cache/research-mcp/pdf/).
Argumento | Tipo | Descripción |
|
| DOI, ID de arXiv o URL de PDF |
|
| Trunca el texto devuelto (predeterminado 50000) |
|
| Almacena el PDF en caché localmente (predeterminado |
Devuelve el texto extraído, el recuento de páginas, la URL de origen y la ruta en caché. Si no se encuentra una copia de acceso abierto, el agente recibe un mensaje claro que le indica buscar una copia OA o pasar una URL de PDF directamente.
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 se requiere clave API. Ejecuta uv sync && uv run research-mcp para iniciar el servidor sobre 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
