A
licenseNot graded
qualityB
maintenanceAn MCP server that enables coding agents to search academic papers, ingest full-text PDFs, extract structured details, and manage citations in literature research workflows.
25
MIT
Crossref Academic MCP Server
by AiAgentKarl
Provides AI-powered citation analysis, abstracts, and impact metrics for academic papers.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Crossref Academic MCP ServerFind recent papers about transformer architectures in NLP"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Crossref Academic MCP Server
MCP Server that gives AI agents access to scientific papers, citations, and academic research data. Queries Crossref, OpenAlex, and Semantic Scholar — three major open academic APIs covering 150M+ research works.
No API keys required. All data sources are free and open.
Tools
Tool | Description |
| Search for scientific papers across Crossref + OpenAlex simultaneously |
| Get full metadata for a paper via DOI (bibliographic data + abstract + impact metrics) |
| Find papers that cite a given paper (via Semantic Scholar) |
| Look up an author's profile — publications, h-index, affiliations, research topics |
| Find the most-cited recent papers in a topic area (trending research since 2023) |
Related MCP server: mcp-openalex
Installation
With pip (recommended)
pip install crossref-academic-mcp-serverFrom source
git clone https://github.com/AiAgentKarl/crossref-academic-mcp-server.git
cd crossref-academic-mcp-server
pip install -e .Configuration
Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):
Using pip install
{
"mcpServers": {
"crossref-academic": {
"command": "crossref-server"
}
}
}Using uvx (no install needed)
{
"mcpServers": {
"crossref-academic": {
"command": "uvx",
"args": ["crossref-academic-mcp-server"]
}
}
}Example Usage
Search for papers:
"Find recent papers about transformer architectures in NLP"
Look up a specific paper:
"Get details for DOI 10.1038/s41586-021-03819-2"
Explore citations:
"What papers cite the original attention paper?"
Author lookup:
"Show me Yoshua Bengio's publication profile"
Trending research:
"What are the most-cited papers about quantum computing from the last two years?"
Data Sources
Crossref — 150M+ metadata records, DOI resolution, bibliographic data
OpenAlex — Open catalog of scholarly works, authors, institutions, topics
Semantic Scholar — AI-powered citation analysis, abstracts, impact metrics
More MCP Servers by AiAgentKarl
Category | Servers |
🔗 Blockchain | |
🌍 Data | Weather · Germany · Agriculture · Space · Aviation · EU Companies |
🔒 Security | |
🤖 Agent Infra | Memory · Directory · Hub · Reputation |
🔬 Research |
License
MIT
Available Tools
5 toolsget_author_profileA
Suche nach einem Autor und zeige Profil-Informationen.
Nutzt OpenAlex für Autoren-Daten inkl. Publikationszahlen, Zitationsmetriken und Forschungsgebiete.
Args: name: Name des Autors, z.B. "Yoshua Bengio"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data source (OpenAlex) and the type of data returned, which adds some transparency. However, it lacks details about error handling, authentication needs, rate limits, or whether the operation is read-only. With no annotations, the description carries the full burden but provides only partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the core function, one line about the data source, and an Args section with a brief parameter description. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description adequately covers the purpose and data types. It lacks explicit mention of output structure, but the examples of data (publication counts, citations, fields) provide sufficient context for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is explained with a description and a concrete example ('Yoshua Bengio'), adding meaning beyond the schema's property title. Although schema coverage is 0%, the description compensates effectively, though it could be more precise about name format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for an author and displays profile information, including specific data types (publication counts, citation metrics, research fields). It distinguishes itself from sibling tools like search_papers or get_citations by focusing on author profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify when to choose this over get_citations or search_papers, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_citationsA
Finde Papers, die ein bestimmtes Paper zitieren.
Nutzt Semantic Scholar für Zitationsanalyse. Zeigt welche neueren Arbeiten auf einem Paper aufbauen.
Args: doi: DOI des Quell-Papers, z.B. "10.1038/s41586-021-03819-2" limit: Maximale Anzahl Zitationen (Standard: 10, Max: 100)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | ||
| limit | No |
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description mentions Semantic Scholar but fails to disclose important behavioral traits such as rate limits, auth requirements, or the exact return structure (e.g., pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two short paragraphs plus Args) and front-loaded with purpose. The Args section is clear, though the overall structure could be slightly more standardized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low schema coverage, the description provides adequate context (source, parameter details, purpose). However, it lacks details on return format or potential limits (e.g., rate limiting, pagination).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section documents both parameters: doi with an example and limit with default/max constraints. This compensates for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves papers citing a given paper, using Semantic Scholar. It directly contrasts with sibling tools like search_papers (general search) and get_paper_details (single paper info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing citation analysis but does not explicitly state when to avoid this tool or name alternatives. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paper_detailsA
Hole vollständige Metadaten eines Papers via DOI.
Kombiniert Daten aus Crossref (bibliographisch) und Semantic Scholar (Abstract, Einfluss-Metriken).
Args: doi: Digital Object Identifier, z.B. "10.1038/s41586-021-03819-2"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses data sources but omits other behavioral traits like read-only nature, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences clearly state purpose and data sources, followed by parameter details. Efficient and front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes what data is combined and from which sources, sufficient for an agent to infer return structure. Lacks mention of output schema or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value over schema by defining DOI, providing an example, and explaining its role. Compensates for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete paper metadata via DOI and distinguishes it from siblings by specifying the data sources (Crossref and Semantic Scholar).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when a DOI is available and full metadata is needed, but does not explicitly state when not to use it or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_papersB
Suche nach wissenschaftlichen Papers über Crossref und OpenAlex.
Durchsucht zwei große akademische Datenbanken gleichzeitig und kombiniert die Ergebnisse. Ideal für Literaturrecherche.
Args: query: Suchbegriff(e), z.B. "machine learning healthcare" limit: Maximale Anzahl Ergebnisse pro Quelle (Standard: 10, Max: 50)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions combining results from two databases but lacks disclosure on side effects, rate limits, error handling, or authentication requirements. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a brief sentence and an Args section. Mixed language (German/English) but still efficient. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description covers purpose, parameters, and basic behavior. However, it does not describe the return format or fields. For a simple search tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds value by explaining that 'query' is search terms and 'limit' is max results per source with default (10) and max (50). However, it omits details like query syntax (boolean, phrases) and whether 'limit' is per source or total.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for scientific papers via Crossref and OpenAlex, combining results. It distinguishes from siblings like get_author_profile, get_citations, get_paper_details, and search_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Says 'Ideal für Literaturrecherche' but does not explicitly state when to use vs alternatives or provide exclusions. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_topicsA
Finde die meistzitierten neueren Papers zu einem Thema.
Sucht über OpenAlex nach Papers seit 2023, sortiert nach Zitationszahl. Ideal um Trend-Themen zu erkunden.
Args: topic: Themengebiet, z.B. "large language models", "CRISPR" limit: Maximale Anzahl Ergebnisse (Standard: 10, Max: 50)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| limit | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool searches OpenAlex, filters papers since 2023, and sorts by citation count. This provides meaningful behavioral insight beyond the tool name, though it does not mention rate limits, caching, or result structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs and a bulleted Args list. Every sentence adds value, and the main purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description provides sufficient context: source database, time filter, sorting criteria, and parameter details. It could be improved by briefly noting what the output contains (e.g., paper titles and citation counts).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the topic parameter by providing examples ('large language models', 'CRISPR') and explaining it as a subject area. For limit, it clarifies the default (10) and maximum (50), which goes beyond the schema's basic type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the most-cited recent papers on a topic, specifying the source (OpenAlex), time range (since 2023), and sorting (by citations). This distinguishes it from sibling tools like search_papers, which likely perform broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Ideal um Trend-Themen zu erkunden' (ideal for exploring trending topics), providing clear usage context. However, it does not explicitly mention when not to use this tool or suggest alternatives like search_papers for non-trending topics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v0.1.0- First observed
get_author_profile - First observed
get_citations - First observed
get_paper_details - First observed
search_papers - First observed
search_topics
TDQS
A4/5.0
Disambiguation5/5
Each tool targets a distinct academic research task: author profile, citation lookup, paper details, paper search, and topic trend search. No functional overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case: get_author_profile, get_citations, get_paper_details, search_papers, search_topics.
Tool Count5/5
With 5 tools, the server is well-scoped for academic literature research, covering essential operations without unnecessary complexity.
Completeness4/5
Core workflows—search, details, citations, author profiles, and trending topics—are covered. Minor gaps like backward reference lookup or journal info are absent but not critical for the stated purpose.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Academic research MCP server for paper search, citation checks, graphs, and deep research.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server for the OpenAlex scholarly database, providing AI agents with tools to search and retrieve academic works, authors, and institutions via natural language queries.8MIT
- FlicenseAqualityDmaintenanceAn MCP server that integrates Scopus, Crossref, and PubMed APIs to search academic papers and fetch abstracts, usable with any MCP-compatible AI client.2-
- AlicenseAqualityCmaintenanceUnified MCP server for scientific literature search and extraction, integrating databases like Scopus, OpenAlex, Semantic Scholar, and Unpaywall to enable AI agents to discover papers, track citations, and analyze content.27MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/crossref-academic-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server