Un servidor de Protocolo de Contexto Modelo (MCP) que permite buscar y recuperar información de artículos académicos de múltiples fuentes.
El servidor proporciona a los LLM:
Funcionalidad de búsqueda de artículos académicos en tiempo real
Acceso a metadatos y resúmenes de artículos
Capacidad de recuperar contenido de texto completo cuando esté disponible
Respuestas de datos estructurados siguiendo la especificación MCP
Si bien está diseñada principalmente para la integración con el cliente Claude Desktop de Anthropic, la especificación MCP permite una posible compatibilidad con otros modelos de IA y clientes que admiten capacidades de llamada de herramientas/funciones (por ejemplo, la API de OpenAI).
Nota : Este software se encuentra en desarrollo. Las características y funcionalidades están sujetas a cambios.
Este servidor expone las siguientes herramientas:
search_papers : Busque artículos académicos en múltiples fuentes
Parámetros:
query (str): texto de consulta de búsqueda
limit (int, opcional): número máximo de resultados a devolver (predeterminado: 10)
Devuelve: Cadena formateada que contiene detalles del papel
fetch_paper_details : recupera información detallada de un artículo específico
Parámetros:
paper_id (str): Identificador del artículo (DOI o Semantic Scholar ID)
source (str, opcional): Fuente de datos ("crossref" o "semantic_scholar", predeterminado: "crossref")
Devuelve: Cadena formateada con metadatos completos del artículo que incluyen:
Título, autores, año, DOI
Lugar, estado de acceso abierto, URL del PDF (solo Semantic Scholar)
Resumen y resumen TL;DR (cuando esté disponible)
search_by_topic : busca artículos por tema con filtro de rango de fechas opcional
Parámetros:
topic (str): Texto de consulta de búsqueda (limitado a 300 caracteres)
year_start (int, opcional): Año de inicio del rango de fechas
year_end (int, opcional): Año de finalización del rango de fechas
limit (int, opcional): número máximo de resultados a devolver (predeterminado: 10)
Devuelve: Cadena formateada que contiene resultados de búsqueda que incluyen:
Títulos de artículos, autores y años
Resúmenes y resúmenes TL;DR cuando estén disponibles
Información sobre el lugar y acceso abierto
Related MCP server: Research MCP
Para instalar automáticamente Academic Paper Search Server para Claude Desktop a través de Smithery :
npx -y @smithery/cli install @afrise/academic-search-mcp-server --client claudeTenga en cuenta que este método no ha sido probado en gran medida, ya que su servidor parece tener problemas. Puede seguir las instrucciones independientes hasta que se arregle el problema de Smithery.
Instalar dependencias:
uv add "mcp[cli]" httpxConfigure las claves API requeridas en su entorno o archivo .env :
# These are not actually implemented
SEMANTIC_SCHOLAR_API_KEY=your_key_here
CROSSREF_API_KEY=your_key_here # Optional but recommendedEjecutar el servidor:
uv run server.pyAgregue el servidor a su configuración de Claude Desktop ( claude_desktop_config.json ):
{
"mcpServers": {
"academic-search": {
"command": "uv",
"args": ["run ", "/path/to/server/server.py"],
"env": {
"SEMANTIC_SCHOLAR_API_KEY": "your_key_here",
"CROSSREF_API_KEY": "your_key_here"
}
}
}
}Reiniciar Claude Desktop
Este servidor está construido utilizando:
SDK de Python MCP
FastMCP para una implementación de servidor simplificada
httpx para solicitudes API
API de Semantic Scholar
API de Crossref
Este proyecto está licenciado bajo la Licencia Pública General GNU Affero v3.0 (AGPL-3.0). Esta licencia garantiza que:
Puede utilizar, modificar y distribuir libremente este software.
Cualquier modificación debe ser de código abierto bajo la misma licencia.
Cualquier persona que proporcione servicios de red utilizando este software debe poner a disposición el código fuente.
Se permite el uso comercial, pero el software y cualquier derivado deben seguir siendo gratuitos y de código abierto.
Consulte el archivo LICENCIA para ver el texto completo de la licencia.
¡Agradecemos tus contribuciones! Puedes ayudarnos de la siguiente manera:
Bifurcar el repositorio
Crear una rama de características ( git checkout -b feature/amazing-feature )
Confirme sus cambios ( git commit -m 'Add amazing feature' )
Empujar a la rama ( git push origin feature/amazing-feature )
Abrir una solicitud de extracción
Tenga en cuenta:
Siga el estilo y las convenciones del código existente
Agregar pruebas para cualquier nueva funcionalidad
Actualice la documentación según sea necesario
Asegúrese de que sus cambios respeten los términos de la licencia AGPL-3.0
Al contribuir a este proyecto, usted acepta que sus contribuciones estarán licenciadas bajo la licencia AGPL-3.0.
Get detailed information about a specific paper.
Args:
paper_id: Paper identifier (DOI for Crossref, paper ID for Semantic Scholar)
source: Source database ("semantic_scholar" or "crossref")
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | ||
| source | No | semantic_scholar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed information,' which implies a read-only operation, but it doesn't disclose any behavioral traits such as authentication needs, rate limits, error handling, or what 'detailed information' includes. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 appropriately sized and front-loaded, starting with a clear purpose statement followed by a concise 'Args' section that lists parameters with brief explanations. Every sentence earns its place by providing essential information without unnecessary details, making it efficient and easy to parse.
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 the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters well, but it lacks information on behavioral aspects like what 'detailed information' entails, potential errors, or usage constraints. Without an output schema, the description should ideally hint at the return structure, but it doesn't, leaving some context gaps.
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 adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'paper_id' is a 'Paper identifier (DOI for Crossref, paper ID for Semantic Scholar)' and 'source' is a 'Source database' with options 'semantic_scholar' or 'crossref'. This clarifies the purpose and format of the parameters, compensating well for the lack of 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 clearly states the tool's purpose: 'Get detailed information about a specific paper.' This specifies the verb ('Get') and resource ('paper'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_by_topic' or 'search_papers', which likely return lists rather than details for a specific paper.
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 usage by specifying that it's for a 'specific paper' and lists the required 'paper_id' and optional 'source' parameters. This suggests it should be used when you have a known paper identifier, but it doesn't explicitly state when to use this tool versus the sibling search tools or provide any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers by topic with optional date range.
Note: Query length is limited to 300 characters. Longer queries will be automatically truncated.
Args:
topic (str): Search query (max 300 chars)
year_start (int, optional): Start year for date range
year_end (int, optional): End year for date range
limit (int, optional): Maximum number of results to return (default 10)
Returns:
str: Formatted search results or error message
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes | ||
| year_end | No | ||
| year_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: the query length limit (300 characters with truncation) and the return type (formatted search results or error message). However, it lacks details on permissions, rate limits, error conditions beyond truncation, or pagination behavior, which are important for a search 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 appropriately sized and well-structured. It starts with a clear purpose statement, adds a critical behavioral note (query length limit), and then lists parameters and returns in a formatted way. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.
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 the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers parameters and basic behavior but lacks output details (e.g., result format beyond 'formatted'), error handling specifics, and differentiation from siblings. For a search tool, this leaves gaps in guiding the agent 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?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'topic' as the search query with a character limit, 'year_start' and 'year_end' for date range, and 'limit' for maximum results with a default. This compensates well for the schema's lack of descriptions, though it could note that year parameters are optional integers.
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 tool's purpose: 'Search for papers by topic with optional date range.' It specifies the verb ('search'), resource ('papers'), and scope ('by topic with optional date range'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_papers' or 'fetch_paper_details,' which would be needed for a perfect score.
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 no guidance on when to use this tool versus alternatives like 'search_papers' or 'fetch_paper_details.' It mentions optional parameters like date range and limit, but doesn't explain scenarios where this tool is preferred over siblings or any prerequisites for usage. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers across multiple sources.
args:
query: the search query
limit: the maximum number of results to return (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
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 mentions searching 'across multiple sources' but does not cover critical aspects such as authentication needs, rate limits, pagination, or what the response format looks like. This leaves significant gaps in understanding the tool's behavior.
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 brief and front-loaded with the main purpose, but the 'args' section is somewhat redundant as it repeats parameter names without adding new insights. It could be more structured to avoid duplication and enhance clarity.
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 the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on result format, error handling, source specifics, and behavioral traits, making it inadequate for full contextual understanding.
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 adds meaningful context for both parameters: 'query' is explained as 'the search query,' and 'limit' as 'the maximum number of results to return (default 10).' Since schema description coverage is 0%, this compensates well by clarifying parameter purposes beyond the bare schema.
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 the tool 'Search for papers across multiple sources,' which provides a clear verb ('Search') and resource ('papers'). However, it does not differentiate from sibling tools like 'search_by_topic' or specify what 'multiple sources' entails, making it somewhat vague in distinguishing its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_by_topic' or 'fetch_paper_details.' The description lacks context on scenarios, prerequisites, or exclusions, leaving usage decisions unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools 'search_by_topic' and 'search_papers' have significant overlap in purpose—both search for papers, with only minor differences in parameters. This creates ambiguity, as an agent might struggle to choose between them. The 'fetch_paper_details' tool is distinct, but the two search tools are not clearly differentiated.
The naming is mixed: 'fetch_paper_details' uses a verb_noun pattern, while 'search_by_topic' and 'search_papers' use verb_preposition_noun and verb_noun styles, respectively. This inconsistency makes the set less predictable, though the names are still readable and descriptive.
With only 3 tools, the server feels thin for an academic paper search domain. It lacks essential operations like filtering by author, journal, or citation count, and there's no update or delete functionality, which limits its utility for comprehensive paper management.
The tool surface is incomplete for academic paper search. It covers basic fetch and search operations but misses key features such as author-based searches, citation tracking, paper categorization, or integration with reference managers. This will likely cause agent failures in complex workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/afrise/academic-search-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
