Allows searching for academic articles on Google Scholar, retrieving articles citing a specific paper, and getting all versions of an article from different sources.
Provides access to full-text Open Access articles via the CORE API, enabling retrieval of article full text, searching for articles with full-text available, and answering research questions using evidence from 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., "@Google Scholar MCP Server search for transformer neural networks from 2023"
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.
MCP server for academic research via Claude Code. Search Google Scholar and access Open Access full-text articles.
Google Scholar Search via SerpAPI
Search academic articles by query, year, language
Get articles citing a specific paper
Get all versions of an article from different sources
Full-text Access via CORE API
Retrieve full text of Open Access articles
Search specifically for articles with full-text available
Answer research questions using evidence from papers (RAG pattern)
Related MCP server: AI Research Assistant - Semantic Scholar
Tool | Description |
| Search for academic articles on Google Scholar |
| Get articles citing a specific paper |
| Get all versions of an article |
| Get full text of Open Access article |
| Search for articles with full-text |
| Answer research questions using evidence from Open Access papers |
SerpAPI (Required)
Sign up at serpapi.com
Free tier: 100 searches/month
Paid plans from $75/month for 5,000 searches
CORE API (Optional, for full-text)
Register at core.ac.uk/api-keys/register
Free: 100,000 requests/day
git clone https://github.com/alimov-andrey/google-scholar-mcp.git
cd google-scholar-mcp
uv pip install -e .cp .env.example .env
# Edit .env and add your API keys:
# SERPAPI_API_KEY=your_key_here
# CORE_API_KEY=your_key_here # optionalOption A: Global config (~/.claude/claude_mcp_config.json)
{
"mcpServers": {
"google-scholar": {
"command": "bash",
"args": ["-c", "cd /path/to/google-scholar-mcp && exec python -m src.main"]
}
}
}Option B: Project config (.mcp.json in project root)
{
"mcpServers": {
"google-scholar": {
"command": "bash",
"args": ["-c", "cd /path/to/google-scholar-mcp && exec python -m src.main"]
}
}
}Search for "transformer neural networks" articles from 2023Get articles citing this paper (use citation_id from search results)Get full text for article with DOI 10.1234/examplegoogle-scholar-mcp/
├── src/
│ ├── main.py # FastMCP server entry point
│ ├── config.py # Pydantic settings
│ ├── clients/
│ │ ├── exceptions.py # APIError, RateLimitError, AuthenticationError
│ │ ├── serpapi.py # SerpAPI async client with retry
│ │ └── core_api.py # CORE API async client with retry
│ ├── models/
│ │ └── scholar.py # Pydantic response models
│ └── tools/
│ ├── scholar.py # Google Scholar tools
│ └── fulltext.py # Full-text access tools
├── tests/ # Unit tests (86 tests)
├── pyproject.toml
└── .github/workflows/
└── test.yml # CI pipeline# Install with dev dependencies
uv pip install -e ".[dev]"
# Run tests
pytest tests/ -v
# Run server locally
python -m src.mainPython 3.12+ with FastMCP 2.14
httpx for async HTTP with retry logic
Pydantic for data validation
stdio transport for MCP communication
MIT
Answer a research question using evidence from Open Access papers.
Searches CORE API for relevant papers and returns abstracts and text snippets as evidence. Use this for literature review and evidence-based answers. The AI will synthesize the answer from the returned sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of sources to retrieve (max 10) | |
| question | Yes | Research question in natural language |
| Name | Required | Description |
|---|---|---|
| evidence | Yes | |
| question | Yes | |
| total_sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses the tool searches CORE API and returns abstracts/snippets, but lacks details on rate limits, authentication, error handling, or what happens with no results.
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?
Three sentences, no waste, front-loaded with purpose. Every sentence adds 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?
Covers purpose, method, and result format reasonably. Output schema likely details return structure. Minor gaps like behavioral limitations prevent a 5.
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 covers both parameters with descriptions (100% coverage). Description adds no extra semantics beyond what the schema already provides.
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 answers research questions using Open Access papers, with evidence from abstracts and snippets. It distinguishes from siblings (e.g., search_articles for raw lists) by emphasizing synthesis.
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?
Accurately recommends use for literature review and evidence-based answers, but does not explicitly exclude other use cases or mention alternatives like search_articles for raw retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all versions of a specific article from different sources.
Use the cluster_id from search_articles results.
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | Cluster ID from a previous search result |
| Name | Required | Description |
|---|---|---|
| versions | Yes | |
| cluster_id | Yes | |
| total_versions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It does not mention if the operation is read-only, return format, pagination, or any limits. This is a significant gap.
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?
Two concise sentences, both necessary: first states purpose, second gives usage guidance. No wasted words.
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 tool with one parameter and full schema coverage, the description is complete. It tells what to do and where to get the input. An output schema exists to handle return values, so description doesn't need to cover that.
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 already describes cluster_id as 'Cluster ID from a previous search result'. The description adds value by specifying that it comes from search_articles, providing helpful context beyond the 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 clearly states the action 'Get all versions of a specific article from different sources', which is specific and distinguishes it from siblings like search_articles (searching) and get_fulltext (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 instruction 'Use the cluster_id from search_articles results' provides clear context for when to use this tool, but it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get articles that cite a specific paper.
Use the citation_id from search_articles results.
| Name | Required | Description | Default |
|---|---|---|---|
| citation_id | Yes | Citation ID from a previous search result | |
| num_results | No | Number of citing articles (max 20) |
| Name | Required | Description |
|---|---|---|
| citation_id | Yes | |
| citing_articles | Yes | |
| total_citations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. However, it does not mention whether the tool is read-only, requires authentication, or handles invalid inputs. This lack of transparency could lead to misuse.
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?
Two sentences, no wasted words. The first sentence states the purpose, the second provides a critical usage guideline. Perfectly front-loaded and efficient.
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 presence of an output schema reduces the burden. The description covers the essential usage flow and parameter sourcing. It could mention the output format or error handling, but is sufficient for a simple retrieval tool.
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?
With 100% schema coverage, the baseline is 3. The description adds value by specifying the source of citation_id (from search_articles results), which goes beyond the schema. It does not elaborate on num_results.
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 gets articles that cite a specific paper, a distinct purpose compared to siblings like search_articles or get_article_versions. The verb 'get' and resource 'articles that cite a specific paper' are specific.
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 advises using citation_id from search_articles results, providing clear context for when to use this tool. It lacks explicit when-not or alternatives, but the guidance is helpful and minimizes ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full text of an Open Access article via CORE API.
Provide at least one identifier: DOI, title, or CORE ID. Returns full text if available, otherwise abstract and download link.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI of the article | |
| title | No | Title of the article | |
| core_id | No | CORE ID of the article |
| Name | Required | Description |
|---|---|---|
| title | No | |
| source | No | |
| abstract | No | |
| fulltext | No | |
| download_url | No | |
| fulltext_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses fallback behavior: returns full text if available, otherwise abstract and download link. No annotations, so description provides behavioral context effectively.
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?
Two sentences, first states purpose, second provides requirements and fallback. No wasted words.
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?
Output schema exists, so no need to detail returns. Covers core behavior, parameter requirements, and fallback. Could mention error cases but still sufficient.
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 100%, but description adds value by explaining the identifiers' roles and requiring at least one, which goes beyond 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?
Verb 'Get full text' specifies action, 'Open Access article via CORE API' specifies resource and source. Fallback behavior distinguishes it from search tools like search_articles.
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?
States 'Provide at least one identifier' guiding parameter usage, but does not explicitly state when not to use or compare to alternatives beyond implicit distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for academic articles on Google Scholar.
Returns articles with title, authors, year, citation count, and links. Use citation_id for get_citations and cluster_id for get_article_versions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for articles | |
| year_to | No | Filter articles up to this year | |
| language | No | Language code (e.g., 'en', 'ru') | en |
| year_from | No | Filter articles from this year | |
| num_results | No | Number of results (max 20) |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| articles | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the source (Google Scholar) and return data, but omits details on rate limits, authentication, error handling, or pagination. The behavior is adequately described for a simple 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 two concise sentences: one for purpose, one for return value and usage linkage. No extraneous information, every sentence adds 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?
Given the presence of an output schema, the description sufficiently covers the tool's functionality and return data. It could mention default parameters or limits, but is complete enough for a search tool.
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 is 100% and each parameter has a clear description in the schema. The tool description does not add deeper semantics for the input parameters, only referencing output IDs for sibling tools. Baseline 3 is appropriate.
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 searches for academic articles on Google Scholar and lists the return fields. It implies differentiation from siblings by referencing their output IDs, but does not explicitly contrast with 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 gives indirect guidance by pointing to sibling tools for specific tasks (get_citations, get_article_versions), but lacks explicit when-to-use or when-not-to-use statements. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Open Access articles with full-text available.
Returns articles from CORE aggregator with direct download links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (max 50) | |
| query | Yes | Search query for Open Access articles |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| articles | Yes | |
| total_results | 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 that results come from the CORE aggregator and include direct download links, which adds value beyond the input schema. However, it does not mention any rate limits, pagination behavior, or potential side effects, though for a search tool these are less critical.
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?
Two sentences with no wasted words. The first sentence clearly states the action and resource, the second adds the data source and key feature (download links). Front-loaded and efficient.
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, the description adequately covers the tool's purpose and data source. It explains that full-text is available and from where. It could be more explicit about the scope (only CORE aggregator) but is sufficient.
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 100%, so the baseline is 3. The description does not add any additional semantics for the parameters (query and limit) beyond what the schema already provides.
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?
Description clearly states the tool searches for Open Access articles with full-text available, and specifies the data source (CORE aggregator) and that direct download links are returned. This distinguishes it from sibling tools like search_articles and get_fulltext.
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 explicit guidance on when to use this tool versus alternatives. The description implies it is for Open Access articles with full text, but does not mention when not to use it or provide comparisons to sibling tools.
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.
v2.1.0ask_research_questionget_article_versionsget_citationsget_fulltextsearch_articlessearch_open_accessScored across 6 tools
Tools are mostly distinct with clear purposes. search_articles and search_open_access target different sources (Google Scholar vs. CORE), and ask_research_question synthesizes evidence, so overlap is minimal and well-explained.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_articles, get_citations), which is predictable and easy for agents to parse.
6 tools cover the core functionalities of a Google Scholar MCP server (search, citations, versions, full text, Q&A) without being excessive or insufficient.
The set covers essential workflows like searching, retrieving citations, versions, and full text. Minor gaps exist (e.g., no author-specific search or journal filtering), but overall it's well-scoped.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search arXiv and ACL Anthology, retrieve citations and references, and browse web sources to accel…
Search Google Scholar for academic papers, citations, and author profiles.
Real-time web and scholarly search with cited answers and multi-step deep research.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.