Search academic publications, find researchers, analyze citations, download papers, and perform advanced research workflows via Google Scholar.
Click on "Deploy 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 search for papers on transformer models published in 2024"
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.
The most comprehensive Google Scholar MCP server for AI assistants
Installation • Quick Start • Tools • API Reference • Contributing
A powerful Model Context Protocol (MCP) server that connects AI assistants like Claude to Google Scholar. Search academic publications, find researchers, analyze citations, download papers, and perform advanced research workflows.
Tool | Description |
| Search for academic papers by topic, author, or date range |
| Find researchers by name, field, or institution |
| Get detailed author info including h-index, publications, and coauthors |
| Find papers that cite a specific publication |
| Generate BibTeX entries for citations |
| Find related articles for a publication |
| Get all available versions of a paper |
| Download and store papers locally for offline access |
| List all locally stored papers |
| Read content of a stored paper |
| Advanced search with language, patent, and date filters |
Prompt | Description |
| Structured approach to conducting literature reviews |
| Find leading researchers in a specific field |
| Analyze the citation impact of a publication |
| Comprehensive multi-step paper analysis workflow |
| Synthesize research across multiple papers |
| Compare methodologies across research papers |
11 Powerful Tools: Search, citations, related articles, versions, downloads & more
Advanced Search: Filter by language, patents, review articles, and more
Local Paper Storage: Download and cache papers for offline access
Intelligent Caching: Reduce redundant requests with TTL-based caching
Rich Metadata: Abstracts, citation counts, h-index, coauthors, and more
Rate Limiting: Built-in protection against Google Scholar blocking
Error Handling: Graceful handling of rate limits and CAPTCHAs
BibTeX Support: Generate proper academic citations
Advanced Prompts: Pre-built workflows for deep paper analysis and research synthesis
Related MCP server: semantic-scholar-mcp
npx -y @smithery/cli install @dihannahdi/google-scholar-mcp --client claudenpm install -g @dihannahdi/google-scholar-mcpgit clone https://github.com/dihannahdi/google-scholar-mcp.git
cd google-scholar-mcp
npm install
npm run build# If installed globally
google-scholar-mcp
# From source
npm start
# Development mode
npm run devAdd to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"google-scholar": {
"command": "node",
"args": ["/path/to/google-scholar-mcp/dist/index.js"],
"env": {
"SCHOLAR_STORAGE_PATH": "~/.google-scholar-mcp/papers",
"SCHOLAR_RATE_LIMIT_MS": "3000",
"SCHOLAR_CACHE_ENABLED": "true",
"SCHOLAR_CACHE_TTL_MS": "3600000",
"SERPAPI_KEY": "your_serpapi_key_here",
"SCHOLAR_USE_SERPAPI_FALLBACK": "true"
}
}
}
}Or using npx:
{
"mcpServers": {
"google-scholar": {
"command": "npx",
"args": ["-y", "@dihannahdi/google-scholar-mcp"]
}
}
}Variable | Description | Default |
| Path to store downloaded papers |
|
| Rate limit between requests (ms) |
|
| Enable response caching |
|
| Cache time-to-live (ms) |
|
| Optional proxy URL | - |
| SerpAPI key for reliable fallback (get free key) | - |
| Enable automatic SerpAPI fallback when blocked |
|
| Rotate user agents to avoid detection |
|
| Add random delays between requests |
|
| Maximum jitter delay in milliseconds |
|
Google Scholar aggressively blocks automated access. To ensure 100% uptime, we recommend using SerpAPI as a fallback:
Get a free API key at serpapi.com (100 free searches/month)
Set environment variables:
export SERPAPI_KEY="your_serpapi_key"
export SCHOLAR_USE_SERPAPI_FALLBACK="true"How it works:
The server first attempts direct scraping (free, but may be blocked)
If blocked, it automatically falls back to SerpAPI (reliable, paid)
Results are normalized to the same format regardless of source
Benefits of SerpAPI:
✅ 100% uptime guarantee
✅ No CAPTCHA or blocking issues
✅ Handles all anti-bot measures
✅ Rich structured data
✅ Author profiles, citations, related articles
Search for recent machine learning papers about transformers
Tool: search_publications
Arguments:
query: "transformer neural network"
yearStart: 2020
numResults: 10
sortBy: "relevance"Find researchers working on quantum computing at MIT
Tool: search_author
Arguments:
query: "quantum computing"
organization: "MIT"
numResults: 5Get detailed profile for Geoffrey Hinton
Tool: get_author_profile
Arguments:
scholarId: "JicYPdAAAAAJ"Find papers citing "Attention Is All You Need"
Tool: get_citations
Arguments:
clusterId: "4054916225996727837"
numResults: 10
sortBy: "date"Create BibTeX for a paper
Tool: generate_bibtex
Arguments:
title: "Attention Is All You Need"
authors: ["Ashish Vaswani", "Noam Shazeer", "Niki Parmar"]
year: 2017
venue: "Advances in Neural Information Processing Systems"Search Google Scholar for academic publications.
Parameters:
Parameter | Type | Required | Default | Description |
query | string | Yes | - | Search query |
author | string | No | - | Filter by author name |
yearStart | number | No | - | Start year for filter |
yearEnd | number | No | - | End year for filter |
numResults | number | No | 10 | Number of results (1-20) |
sortBy | string | No | "relevance" | "relevance" or "date" |
Returns:
List of publications with title, authors, abstract, venue, year, citation count, URLs
Search for academic researchers.
Parameters:
Parameter | Type | Required | Default | Description |
query | string | Yes | - | Author name or keywords |
organization | string | No | - | Filter by institution |
numResults | number | No | 10 | Number of results (1-20) |
Returns:
List of author profiles with name, affiliation, interests, citation count
Get detailed author information.
Parameters:
Parameter | Type | Required | Description |
scholarId | string | Yes | Google Scholar author ID |
Returns:
Complete profile with publications, h-index, i10-index, coauthors, citation history
Get papers that cite a specific publication.
Parameters:
Parameter | Type | Required | Default | Description |
clusterId | string | Yes | - | Google Scholar cluster ID |
numResults | number | No | 10 | Number of results (1-20) |
sortBy | string | No | "relevance" | "relevance" or "date" |
Returns:
List of citing publications with details
Generate a BibTeX citation entry.
Parameters:
Parameter | Type | Required | Description |
title | string | Yes | Publication title |
authors | string[] | Yes | List of author names |
year | number | No | Publication year |
venue | string | No | Journal/conference name |
url | string | No | Publication URL |
Returns:
Formatted BibTeX entry
Find related articles for a given publication.
Parameters:
Parameter | Type | Required | Default | Description |
clusterId | string | Yes | - | Google Scholar cluster ID |
numResults | number | No | 10 | Number of results (1-20) |
Returns:
List of related publications with metadata
Get all available versions of a paper.
Parameters:
Parameter | Type | Required | Default | Description |
clusterId | string | Yes | - | Google Scholar cluster ID |
numResults | number | No | 10 | Number of results (1-20) |
Returns:
List of all versions (preprint, published, etc.)
Download and store a paper locally.
Parameters:
Parameter | Type | Required | Description |
url | string | Yes | URL to the paper (PDF, arXiv, etc.) |
filename | string | Yes | Name for the saved file |
metadata | object | No | Optional metadata (title, authors, year) |
Returns:
Path to stored file and confirmation
List all locally stored papers.
Parameters:
Parameter | Type | Required | Description |
pattern | string | No | Optional filter pattern |
Returns:
List of stored papers with metadata
Read the content of a stored paper.
Parameters:
Parameter | Type | Required | Description |
filename | string | Yes | Name of the stored file |
Returns:
Paper content (text format)
Advanced search with additional filters.
Parameters:
Parameter | Type | Required | Default | Description |
query | string | Yes | - | Search query |
exactPhrase | string | No | - | Exact phrase to match |
withoutWords | string | No | - | Words to exclude |
author | string | No | - | Filter by author |
source | string | No | - | Filter by source/journal |
yearStart | number | No | - | Start year filter |
yearEnd | number | No | - | End year filter |
language | string | No | "en" | Language code |
includePatents | boolean | No | true | Include patents in results |
includeCitations | boolean | No | true | Include citations |
numResults | number | No | 10 | Number of results |
Returns:
List of publications matching criteria
google-scholar-mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── config/
│ │ └── index.ts # Environment configuration
│ ├── types/
│ │ └── index.ts # TypeScript type definitions
│ ├── tools/
│ │ ├── definitions.ts # Tool schemas (11 tools)
│ │ ├── handlers.ts # Tool implementation
│ │ └── index.ts
│ ├── scraper/
│ │ ├── scholar.ts # Google Scholar scraper
│ │ └── index.ts
│ └── utils/
│ ├── helpers.ts # URL builders, rate limiting
│ ├── cache.ts # In-memory caching
│ ├── storage.ts # Local paper storage
│ └── index.ts
├── dist/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.mdnpm run build# Run MCP Inspector for debugging
npx @modelcontextprotocol/inspector node dist/index.jsRate Limiting: Google Scholar may rate-limit or block requests. The server includes delays and retries, but heavy usage may trigger blocks.
CAPTCHA: Excessive requests may trigger CAPTCHA challenges. If this happens, wait a few minutes before retrying.
No Official API: This server scrapes Google Scholar's web interface, which may break if Google changes their HTML structure.
Results Limited: Maximum 20 results per request to stay within reasonable limits.
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Model Context Protocol for the MCP SDK
Scholarly for inspiration
The academic community for making research accessible
For issues and questions:
Open an issue on GitHub
Check the MCP documentation
Made with ❤️ for the research community
Perform an advanced search with full Google Scholar parameters: language, patents, review articles, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Main search query | |
| author | No | Filter by author name | |
| sortBy | No | Sort order | relevance |
| source | No | Filter by source/journal name | |
| yearEnd | No | Publications up to this year | |
| language | No | Language code (e.g., "en", "es", "zh-CN") | en |
| yearStart | No | Publications from this year onwards | |
| numResults | No | Number of results | |
| includePatents | No | Include patents in results | |
| reviewArticlesOnly | No | Only return review articles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists parameters and mentions 'Google Scholar' but does not discuss expected behavior (e.g., search result format, rate limits, authentication needs). This omission leaves significant behavioral uncertainty.
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 a single concise sentence that packs key information without unnecessary elaboration. It front-loads the purpose and lists representative parameters efficiently.
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 has 10 parameters, no output schema, and no annotations, the description is too brief. It omits details about the output format, pagination, or how results are returned, which are essential for an advanced 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 description coverage is 100%, so the baseline is 3. The description mentions a few parameter categories (language, patents, review articles) but adds no semantic value beyond the schema's existing parameter descriptions. It does not compensate for any gaps.
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 it performs an advanced search with Google Scholar parameters like language, patents, and review articles. This distinguishes it from simpler search tools (e.g., search_publications, search_author) but does not explicitly contrast them, hence 4.
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 need advanced parameters such as language or patent filtering. However, it does not explicitly state when not to use it or mention alternative sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download and store a paper locally for offline access. Saves paper metadata and PDF if available.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Publication year | |
| title | Yes | Paper title | |
| venue | No | Journal or conference name | |
| pdfUrl | No | Direct URL to PDF | |
| authors | Yes | List of author names | |
| clusterId | No | Google Scholar cluster ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions saving metadata and PDF if available, but fails to disclose important details like storage location, permissions needed, whether it overwrites existing files, or the behavior when PDF is missing. This is a significant gap for a mutation 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 extremely concise, consisting of two short sentences. It front-loads the purpose and adds a supporting detail about what is saved. Every word earns its place with no redundancy.
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 6 parameters and no output schema, the description is somewhat complete but lacks explanation of what happens when PDF URL is not provided (since it's not required) and how the paper is located. More context on the download behavior would improve completeness.
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 input schema has 100% description coverage for all 6 parameters. The description adds no additional semantic information beyond what the schema already provides, so the baseline score of 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 action ('download and store'), the resource ('paper'), and the outcome ('for offline access'). It distinguishes this tool from siblings like 'read_paper' or 'list_papers' by emphasizing local storage and PDF availability.
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 when offline access is needed, but does not explicitly state when not to use it or provide alternatives such as 'read_paper' for online viewing. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a BibTeX citation entry for a publication. Useful for creating properly formatted citations for LaTeX documents.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Publication URL | |
| year | No | Publication year | |
| title | Yes | Publication title | |
| venue | No | Journal or conference name | |
| authors | Yes | List of author names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, authentication requirements, error handling, or how invalid inputs are treated. For a generation tool, 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?
The description is extremely concise with two sentences. The first sentence states the purpose and verb, and the second provides context. Every sentence earns its place with 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?
Given the lack of an output schema, the description should explain the return value, such as the format of the BibTeX string or citation key generation. It also does not mention if the tool supports all publication types (e.g., article, book). This leaves the agent uncertain about what to expect.
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 meaning to the parameters, such as the expected format for authors (e.g., 'First Last' vs 'Last, First') or handling of special characters. It merely restates the purpose.
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 ('Generate a BibTeX citation entry') and the resource ('a publication'), with additional context about its use for LaTeX documents. It distinguishes itself from sibling tools like search_publications or get_citations, which serve different purposes.
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: the tool is useful for generating properly formatted citations for LaTeX documents. However, it lacks explicit guidance on when not to use it or alternatives, such as if the user needs citations in other formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all versions/variants of a publication. Find preprints, published versions, and open access copies.
| Name | Required | Description | Default |
|---|---|---|---|
| clusterId | Yes | Google Scholar cluster ID of the publication |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the type of results (preprints, published, open access) but does not disclose potential rate limits, authentication requirements, or any side effects. The read nature is implied but not explicit.
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 extraneous words. The purpose is front-loaded in the first sentence, and the second adds specific examples. Highly concise 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?
For a simple retrieval tool with one parameter and no output schema, the description covers the main functionality well. However, more detail about the output format or potential limitations (e.g., pagination) would improve completeness.
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% with a single parameter described as 'Google Scholar cluster ID of the publication.' The description adds no additional meaning beyond the schema, which already sufficiently documents the parameter. 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 retrieves 'all versions/variants of a publication' and lists examples like preprints, published versions, and open access copies. It distinguishes from siblings like get_citations or search_publications by focusing on versions.
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 when you need to find different versions of a publication, but does not explicitly state when to avoid this tool or suggest alternatives like get_citations for citation data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Google Scholar author profile, including publications, citation metrics (h-index, i10-index), and coauthors.
| Name | Required | Description | Default |
|---|---|---|---|
| scholarId | Yes | Google Scholar author ID (e.g., "JicYPdAAAAAJ") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states what data is returned but does not disclose behavior such as read-only nature, rate limits, authentication requirements, or error handling for invalid IDs. Moderate transparency.
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 a single sentence that efficiently conveys the tool's purpose and key outputs with no redundant 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?
Given the tool has only one required parameter and no output schema, the description adequately covers the returned data (publications, metrics, coauthors). It is complete for a simple retrieval tool, though it could mention pagination or filtering if applicable.
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 the scholarId parameter with 100% coverage. The description adds value by providing an example ID format, enhancing understanding beyond the schema alone.
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 verb 'Get' and the resource 'Google Scholar author profile', listing specific outputs like publications, citation metrics (h-index, i10-index), and coauthors. It effectively distinguishes from sibling tools like search_author and list_papers.
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 for retrieving detailed author information by ID but lacks explicit guidance on when to use this tool over alternatives like search_author for finding IDs or list_papers for paper lists. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get papers that cite a specific publication. Requires the cluster ID from the publication's "Cited by" link.
| Name | Required | Description | Default |
|---|---|---|---|
| sortBy | No | Sort by relevance or date | relevance |
| clusterId | Yes | Google Scholar cluster ID | |
| numResults | No | Number of citing papers (default: 10, max: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only mentions that a cluster ID is required and implies a read operation. It does not disclose any potential side effects, rate limits, or other behavioral traits beyond the basic prerequisite. The absence of annotations means the description carries the burden, but it provides minimal transparency.
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 extremely concise: two sentences that directly state the purpose and a key prerequisite. No unnecessary words, and the essential information is front-loaded.
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?
While the description covers the basic purpose and a key prerequisite, it does not describe the output or return format. Without an output schema, the agent may need more context about what the response contains (e.g., list of paper titles, authors). Given the low complexity and high schema coverage of parameters, the description is moderately complete but lacks output details.
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 input schema already describes all three parameters with 100% coverage. The description adds only that the cluster ID comes from the publication's 'Cited by' link, which is a minor semantic addition beyond the schema. Therefore, a score of 3 (baseline for high schema coverage) 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's functionality: getting papers that cite a specific publication. It uses a specific verb ('Get') and resource ('papers that cite a specific publication'), and it distinguishes from siblings like 'search_publications' which searches broadly.
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 includes a clear prerequisite (requires cluster ID from 'Cited by' link), but does not explicitly state when to use this tool versus alternatives like 'search_publications' or 'get_related_articles'. The mention of the required input provides some guidance, but not full usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all locally downloaded papers in your research library.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states a read-only listing operation, but no details on ordering, pagination, or performance implications. It is adequate but minimal.
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?
A single sentence of 10 words with no wasted text. 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 zero parameters and no output schema, the description is mostly complete but lacks information about what fields are returned (e.g., titles, metadata). This is a minor gap for a simple listing 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?
There are no parameters, so schema coverage is 100% trivially. The description adds value by specifying the scope 'locally downloaded' which clarifies the data source beyond the empty schema. Baseline for 0 params is 4.
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 'List all locally downloaded papers in your research library' clearly states the action (list), resource (locally downloaded papers), and scope (all, your library). It effectively distinguishes from sibling tools like advanced_search and download_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?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied, but there is no mention of when not to use it or any comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read metadata and access a locally stored paper.
| Name | Required | Description | Default |
|---|---|---|---|
| paperId | Yes | Local paper ID (from list_papers) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention whether the tool is read-only, what exactly is returned (only metadata or the full paper), or any constraints like requiring the paper to be locally stored.
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 a single, concise sentence that immediately conveys the tool's purpose. No unnecessary words or redundant 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?
Given the tool's simplicity (one required string parameter, no output schema, no annotations), the description is minimally complete. However, it would benefit from clarifying what 'access' means (e.g., reading full text vs. metadata) and specifying the output format.
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% for the single parameter paperId, and the schema already describes it as 'Local paper ID (from list_papers).' The description adds no further meaning, so a baseline score of 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's function: 'Read metadata and access a locally stored paper.' It uses a specific verb (read) and resource (metadata of a locally stored paper), distinguishing it from siblings that handle downloads, citations, or searches.
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 download_paper or get_related_articles. There is no mention of prerequisites or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for academic researchers and their Google Scholar profiles. Find researchers by name, field, or institution.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Author name or research topic keywords | |
| numResults | No | Number of results (default: 10, max: 20) | |
| organization | No | Filter by institution/organization |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states search capability without disclosing read-only nature, rate limits, pagination, or result format. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no redundant information. 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?
Adequate for a simple search tool with fully described parameters, but lacks hints about output results and no guidance on sibling tool selection.
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%; description adds no new meaning beyond schema defaults and filters. Baseline 3.
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?
Clearly states it searches for academic researchers and Google Scholar profiles. Distinct from siblings like 'get_author_profile' or 'search_publications'.
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?
Implies usage for searching by name, field, or institution, but does not differentiate from 'get_author_profile' for known authors or provide when-not cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google Scholar for academic publications, papers, and research articles. Use this to find papers on topics, by authors, or within date ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for finding publications | |
| author | No | Filter results by author name | |
| sortBy | No | Sort by relevance or date | relevance |
| yearEnd | No | Filter publications up to this year | |
| yearStart | No | Filter publications from this year onwards | |
| numResults | No | Number of results (default: 10, max: 20) |
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 reveals the tool is a read operation (search) but does not disclose any other behaviors such as rate limits, authentication requirements, or result format.
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 consists of two concise sentences. The first front-loads the core purpose, and the second adds usage context. No fluff or redundancy.
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 tells when to use the tool but omits information about the return structure, pagination, or result format. Given the 6 parameters and no output schema, the description is adequate but not complete for an agent to fully understand usage without further inspection of the schema.
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 description's contribution is minimal. The description reinforces the purpose of query, author, and date parameters but adds little new meaning 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 it searches Google Scholar for academic publications, papers, and research articles. The verb 'search' and resource 'Google Scholar' are specific, but it does not explicitly distinguish from the sibling 'advanced_search' tool.
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?
It says 'Use this to find papers on topics, by authors, or within date ranges,' which provides context for usage. However, it does not mention when not to use it or mention alternatives like 'advanced_search'.
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.
v1.2.0advanced_searchdownload_papergenerate_bibtexget_all_versionsget_author_profileget_citationsget_related_articleslist_papersread_papersearch_authorsearch_publicationsScored across 11 tools
Each tool serves a distinct purpose: basic and advanced search, author discovery, citation tracking, version retrieval, local storage management, and citation generation. Even closely related tools like search_publications and advanced_search are clearly differentiated by parameter scope.
Most tool names follow a consistent verb_noun pattern (e.g., download_paper, search_author). The exception is advanced_search, which inverts the order (adjective+noun) rather than verb+noun. Overall, the pattern is predictable.
With 11 tools, the surface is well-scoped for a Google Scholar integration. It covers searching, author profiles, citation and related article discovery, local library management, and citation generation without being overwhelming.
The tool set covers the core academic research workflow comprehensively: search, retrieve, store, and cite. Minor gaps exist, such as the absence of bulk export or collaboration features, but these do not hinder basic usage.
Search Google Scholar for academic papers, citations, and author profiles.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…
