Google Scholar MCP Server
Provides tools for searching academic literature on Google Scholar, supporting query operators, year ranges, cited-by lookups, and retrieval of citation formats (MLA, APA, Chicago, Harvard, Vancouver) along with BibTeX and EndNote export links.
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 ServerFind all versions of the paper 'Attention Is All You Need'"
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.
Google Scholar MCP Server
A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client two read-only Google Scholar tools. Search the literature with Scholar's own operators, year ranges and cited-by lookups, then pull a paper's citation in five styles with its BibTeX and EndNote export links, both as structured JSON, with nothing to host.
It reads public Google Scholar pages that a signed-out visitor can see.
1,000 free credits every month, no card required, which is 100 Scholar calls at the 10-credit rate.
https://mcp.hasdata.com/api/mcp?apis=google_scholar
Contents
Related MCP server: CiteNexus MCP
What you need
An MCP client and a HasData API key from the dashboard, free to create with no card, and the free tier covers about 100 calls a month at the 10-credit rate. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/google-scholar-mcp on npm and hasdata-google-scholar-mcp on PyPI, shown below.
Quick start
The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.
Field | Value |
URL |
|
Transport | HTTP, streamable |
Auth header |
|
Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.
claude mcp add --transport http google-scholar "https://mcp.hasdata.com/api/mcp?apis=google_scholar" \
--header "x-api-key: HASDATA_API_KEY"Settings, then Connectors, then Add custom connector, then paste https://mcp.hasdata.com/api/mcp?apis=google_scholar and sign in.
For the config-file route, Claude Desktop loads only local (stdio) servers, so it reaches a remote server through a stdio launcher. The @hasdata/google-scholar-mcp package is that launcher, and it reads the key from the environment. Add this to claude_desktop_config.json:
{
"mcpServers": {
"google-scholar": {
"command": "npx",
"args": ["-y", "@hasdata/google-scholar-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}For Python instead of Node, swap the launcher for the PyPI package, which uvx runs without a manual install:
{
"mcpServers": {
"google-scholar": {
"command": "uvx",
"args": ["hasdata-google-scholar-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"google-scholar": {
"url": "https://mcp.hasdata.com/api/mcp?apis=google_scholar",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf calls the field serverUrl, not url:
{
"mcpServers": {
"google-scholar": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=google_scholar",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}.vscode/mcp.json in the workspace:
{
"servers": {
"google-scholar": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=google_scholar",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Example prompts
Each of these lands on one tool, or on two in sequence when the second needs an id the first returns.
Find papers on transformer architectures published since 2023 and sort them by citation count.
Who has cited this paper, and how has that grown year on year?
Give me the BibTeX for this paper.
Find review articles only on this topic, excluding citations without full records.
Show me every indexed version of this paper and which of them have a PDF.
Find recent work by this author on this topic.
A prompt naming a paper takes two calls, one search to reach its resultId and one citation lookup. A prompt about who cites a paper also takes two, because the second call reuses citedBy.citesId from the first.
Tools
Two tools, 10 credits per successful call.
Get Scholar search results
hasdata_google_scholar_scholar_getScholarSearchResults
A page of Scholar results.
Parameter | Type | Required | Notes |
| string | yes | The query. Scholar operators such as |
| number | Published from and up to these years | |
| number | Result offset, where | |
| number | Results per page | |
| number |
| |
| string | Find articles citing this one, using a | |
| string | Find every indexed version of an article, using a | |
| string | Search type, | |
| number |
| |
| number |
| |
| string | Interface language, one of 159 | |
| array | Restrict to these content languages | |
| string |
| |
| number |
|
Returns searchInformation with totalResults, queryDisplayed and the time Scholar reported, an organicResults array, and pagination.
Each result carries position, resultId, title, link, snippet, a publicationInfo object, a resources array, citedBy, versions, relatedPagesLink and citeHasdataLink.
publicationInfo.authors is the part worth knowing about. Alongside the raw summary line it lists the authors Scholar has profiles for, each with a name, a profile link and an authorId, which is how you follow one author rather than parsing a byline.
citedBy and versions are the two ids that make this tool compose with itself. citedBy.citesId goes back into cites to walk a citation graph, and versions.clusterId goes into cluster to see every indexed copy of the same paper.
{
"position": 1,
"resultId": "A7L9JolPKkoJ",
"title": "A historical survey of advances in transformer architectures",
"link": "https://www.mdpi.com/2076-3417/14/10/4316",
"snippet": "… of the Vision Transformer (ViT) opening a new realm of architectures which build … transformer architecture, it becomes pertinent to examine in detail the architecture of the transformer …",
"publicationInfo": {
"summary": "AR Sajun, I Zualkernan, D Sankalpa - Applied Sciences, 2024 - mdpi.com",
"authors": [
{ "name": "AR Sajun", "authorId": "k6zWX4EAAAAJ", "link": "https://scholar.google.com/citations?user=k6zWX4EAAAAJ&hl=en" }
]
},
"resources": [{ "fileFormat": "Html", "title": "mdpi.com", "link": "https://www.mdpi.com/2076-3417/14/10/4316" }],
"citedBy": { "total": 97, "citesId": "5344171358311789059" },
"versions": { "total": 7, "clusterId": "5344171358311789059" }
}Get Scholar citation formats
hasdata_google_scholar_cite_getScholarCitationFormats
The citation block for one paper.
Parameter | Type | Required | Notes |
| string | yes | A |
| string | Interface language |
Returns citations, the formatted string in MLA, APA, Chicago, Harvard and Vancouver, and links, the export URLs for BibTeX, EndNote, RefMan and RefWorks.
{
"citations": [
{
"title": "APA",
"snippet": "Sajun, A. R., Zualkernan, I., & Sankalpa, D. (2024). A historical survey of advances in transformer architectures. Applied Sciences, 14(10), 4316."
}
],
"links": [
{ "name": "BibTeX", "link": "https://scholar.googleusercontent.com/scholar.bib?q=info:A7L9JolPKkoJ:scholar.google.com/&output=citation..." }
]
}Errors and failure paths
Plan for these rather than assuming a happy path.
On the citation tool, q is a paper id rather than a query. It takes the resultId from a search result, such as A7L9JolPKkoJ. Passing a title or a DOI there returns nothing useful, and the shared parameter name is the reason people get this wrong.
citesId and clusterId can hold the same value, and they are not interchangeable. They were identical on the paper above. One goes into cites to find papers citing this one, the other into cluster to find copies of this one. Sending the right number to the wrong parameter returns a plausible page of the wrong thing.
type arrives on some results and not others. It was present on one result in five, describing the format of the primary resource. Read resources[].fileFormat when you need to know whether a PDF exists.
A BibTeX link is a Scholar URL with a signature in it, not the BibTeX itself. The links array gives you addresses to fetch, and those carry expiring scisig tokens, so fetch them promptly rather than storing them for later.
totalResults is Scholar's estimate and it is very rough. The query above reported 2,080,000. Treat it as an order of magnitude, never as a count.
Scholar counts citations, not quality, and it indexes preprints, theses and citing-only records. asVis: 1 drops citation-only entries when you need records with full metadata.
Paging deep gets thin. Scholar limits how far a result set goes and starts repeating or blocking well before the estimate suggests, so narrow with asYlo, asYhi or asSdt rather than walking start upward.
Results that carry data also carry a requestMetadata.id worth quoting in support.
Pricing, free tier and limits
Each Scholar tool costs 10 credits per successful call. Response size does not change the price, so raising num is the cheap way to widen a search.
The free tier is 1,000 credits every month with no card, which is 100 Scholar calls at the base rate. It renews with the billing cycle, so a low-volume agent runs on the free tier indefinitely.
Paid plans start at $49 a month for 200,000 credits, which is 20,000 calls. The unit price falls with volume, from $2.45 per 1,000 calls on the entry plan to $1.00 on Business, $0.84 on Growth and $0.74 on the largest high-volume plans.
Your plan also sets concurrency. The free tier allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Retry on the 429 with a backoff in anything unattended, because an agent that walks a citation graph will reach the ceiling before you do.
A request that comes back non-200 is not billed. A successful call that finds nothing is still a call.
Tool selection
Start from what the prompt gives you. A topic, an author or a year range goes to the search tool. A resultId you already hold goes straight to the citation tool.
Then think about which id the next step needs. A literature sweep is one search call with a large num. A citation graph is a search call followed by one cites call per paper you follow. A deduplication pass across preprints and published versions is a cluster call per paper. Each of those reuses an id the first response already gave you, so a second search call is usually wasted.
Raise num before you page. Cost is per call rather than per result, so one wide page beats three narrow ones.
How it compares
Google Scholar has no public API, so the comparison worth making is against the open bibliographic APIs.
OpenAlex or Semantic Scholar | This server | |
Eligibility | Open, no key for basic use | An API key |
Coverage | Large, curated, DOI-centred | What Scholar indexes, including theses and preprints |
Citation counts | Their own, computed from their graph | Scholar's, as displayed |
Citation strings | Build them yourself from metadata | MLA, APA, Chicago, Harvard, Vancouver, as Scholar formats them |
Full-text links | DOI and open-access locations | The resource links Scholar shows, including PDFs |
Structured metadata | Rich and typed | As the page presents it |
The row that decides it is whose citation count you need. For bibliometrics on typed, stable metadata, OpenAlex and Semantic Scholar are better instruments and they are free. Reach for this one when the question is specifically about what Google Scholar shows, which is what most researchers actually look at, or when you want the formatted citation rather than the fields to build one.
FAQ
Is there an official Google Scholar MCP server?
Google does not publish one, and Scholar has no public API either. This one is maintained by HasData and reads public Scholar pages.
What is a Google Scholar MCP server?
An MCP server exposes tools an AI client can call. This one turns Scholar search results and citation blocks into JSON an agent can reason over, without a browser or a scraping library in your stack.
Do I need a Google account?
No. The only credential is your HasData key.
How do I get the BibTeX for a paper?
Two calls. Search to get the paper's resultId, then pass that id as q to the citation tool, and take the BibTeX URL from links.
How do I find everything that cites a paper?
Take citedBy.citesId from the search result and send it back as the cites parameter. The response is the citing papers, paged like any other search.
What is the difference between cites and cluster?
cites finds papers that cite the one you named. cluster finds other indexed versions of that same paper, such as a preprint next to the published article. The two ids often look identical, so pick by what you want rather than by the number.
Can I search by author?
Yes, with Scholar's own operator, as author:"J Dean" in q. Search results also carry authorId for authors with a Scholar profile, which is the stabler handle.
Can I use this together with other HasData APIs?
Yes. One key covers everything, and one endpoint serves them all through the apis parameter. Point a client at ?apis=google_scholar,google_serp to get both tool sets in one connection, or at mcp.hasdata.com/api/mcp for the full catalogue.
Is HasData affiliated with Google?
No. HasData is an independent service and is not affiliated with, endorsed by, or sponsored by Google. Google Scholar is a trademark of its respective owner. The tools work with publicly available data only, and you are responsible for using the results in line with Google's terms and the law that applies to you.
Compliance and personal data
Author names, affiliations and Scholar profile ids are personal data, even though they are published as part of the scholarly record. Building a profile of one researcher's output is a different act from counting citations on a topic, and it is the one that needs a second thought about purpose and retention. The papers themselves stay under their own licences, so a link is not permission to redistribute a PDF.
HasData links
Google Scholar API documentation, the REST endpoints behind these tools
Other HasData MCP servers: Google Search, Google Images, Google Maps, Google Trends, Bing, DuckDuckGo, YouTube, TikTok, Instagram, Amazon, Walmart, Shopify, Yelp, Yellow Pages, Zillow, Redfin, Airbnb, Booking.com, Indeed, Glassdoor.
Development
The launcher is a thin stdio bridge to the remote server, so there is nothing to build.
npm install
HASDATA_API_KEY=your_key_here npm testThe tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=google_scholar returns the two expected tools, that no name changed, that both still require q and carry descriptions, that the search parameters this README documents are still in the schema, and that the key in use is actually accepted.
Two tests go further. One asserts that a live search still returns resultId, citedBy.citesId and versions.clusterId, because those three ids are what let the tools compose and nothing else in the response would reveal their loss. The other feeds a resultId straight into the citation tool, which is the two-call workflow this README documents, and checks the five styles come back. Together they cost 20 credits a run, which is the price of a canary that can fail for the right reason.
The contract suite also runs weekly on a schedule, because the upstream tool list can change without anyone touching this repository.
Contributing
A tool table, a response sample or a documented behaviour that does not match reality is worth an issue. There is a template for exactly that. Pull requests are welcome for the same, and for anything in the launcher.
License
MIT, see LICENSE.
Available Tools
2 toolshasdata_google_scholar_cite_getScholarCitationFormatsgoogle_scholar_cite: GET /A
Get Scholar Citation Formats
Looks up citation formats and export links for a single Google Scholar organic search result, identified by its resultId (as returned in a google/scholar organic result). Returns formatted citation snippets (MLA, APA, Chicago, Harvard, Vancouver) and reference-manager export links (BibTeX, EndNote, RefMan, RefWorks). Use to build citation/bibliography features or complete a research workflow started with google/scholar.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The `resultId` of a Google Scholar organic result, as returned by the google/scholar endpoint. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. |
TDQS
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 transparency. It discloses that the tool returns citation snippets and export links, implying a read-only operation. However, it does not mention potential errors (e.g., invalid `resultId`), rate limits, or whether the operation is idempotent. This is a minor 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 concise and well-structured: a title line, a clear functional explanation, an output summary, and use-case guidance. No redundant information or fluff is present. Every sentence contributes to the tool's understanding.
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 no output schema is provided, the description compensates by explicitly listing the expected output types (citation formats and export links). It also explains the input provenance (from google/scholar results) and the intended use cases, covering all essential context an agent needs to invoke the tool correctly.
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 both parameters described. The `q` parameter is explained as the `resultId` from a google/scholar result, providing critical cross-tool context. The `hl` parameter includes guidance on format (two-letter code) and a range (159 allowed) with examples, which exceeds basic type information. These descriptions add meaningful value 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 tool's function: looking up citation formats and export links for a single Google Scholar result. It specifies the verb 'Looks up', identifies the resource type (Google Scholar organic result), and differentiates from sibling tools by referencing the `resultId` returned by the google/scholar endpoint. The use cases ('build citation/bibliography features') further clarify its purpose.
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 indicates when to use the tool: after obtaining a `resultId` from a google/scholar organic result, and for citation/bibliography needs. It implicitly contrasts with the search tool that produces the results. However, it does not explicitly mention alternative tools or scenarios where this tool would be inappropriate, but the context is sufficient for a clear use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_google_scholar_scholar_getScholarSearchResultsgoogle_scholar_scholar: GET /A
Get Scholar Search Results
Scrapes Google Scholar for a query with author:/source: search helpers, year range (asYlo/asYhi), cited-by and all-versions lookups (cites/cluster), review-article and citation-inclusion filters, language/language-restrict, and start/num pagination. Returns each organic result with title, link, snippet, publication info (authors with profile links), cited-by count and link, related-articles link, and all-versions count and link. Use for academic research, literature review automation, citation tracking, and grounding research agents with scholarly sources.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. Supports Google Scholar search helpers such as `author:` and `source:`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| lr | No | The 'lr' parameter specifies the language of the websites to return results from. This parameter filters results based on the language of the web content. | |
| num | No | Maximum number of results to return per page. | |
| asRr | No | Set to 1 to return review articles only, or 0 (default) to return all articles. | |
| safe | No | Adult content filtering option. | |
| asSdt | No | Search type/filter, e.g. `0,5` for the default Articles filter, `4` for case law with court codes, or `0`/`7` for patents. | |
| asVis | No | Set to 1 to exclude citations from the results, or 0 (default) to include them. | |
| asYhi | No | Return results published up to and including this year. | |
| asYlo | No | Return results published from this year onward. | |
| cites | No | Unique article ID to look up articles that cite it, as returned in a result's `citedBy.citesId`. | |
| start | No | Result offset for pagination, where 0 is the first result. | |
| filter | No | Defines whether to enable or disable the filters for 'Similar Results' and 'Omitted Results'. Set to 1 (default) to enable these filters, or 0 to disable them. | |
| scisbd | No | Sort results by date instead of relevance: 1 for abstracts only, 2 for everything. Omit for relevance sorting. | |
| cluster | No | Unique article ID to look up all indexed versions of that article, as returned in a result's `versions.clusterId`. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'scrapes Google Scholar' and 'returns' organic results, implying a read-only operation. However, there are no annotations and the description does not mention potential rate limits, blocking, authentication requirements, or the absence of side effects. It covers basic behavior but leaves some operational expectations implicit.
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 focused paragraph that front-loads the purpose and then lists key features and use cases. It is not overly verbose, though it somewhat duplicates parameter details already present in the schema. Overall it is concise and well-organized.
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 compensates for the absence of an output schema by enumerating the result fields and linking them to parameter behavior. It includes enough context for an agent to understand expected outputs and typical applications. It lacks only explicit error/rate-limit handling, which is minor for a search GET endpoint.
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?
While the schema already describes all parameters (100% coverage), the prose description adds valuable context, such as examples for `asSdt` (e.g., '0,5' for Articles), the meaning of `scisbd` for date sorting, and how `cites`/`cluster` map to returned result fields. This goes beyond simple parameter names.
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 identifies the tool as scraping Google Scholar for search results, listing the key query capabilities (author/source helpers, year range, citation lookups) and the exact output fields (title, link, snippet, cited-by, versions). This differentiates it from sibling tools like the citation formatter.
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 explicitly states recommended use cases ('academic research, literature review automation, citation tracking, and grounding research agents with scholarly sources'). It does not explicitly name alternative tools or provide 'when not to use' guidance, but the use cases are sufficiently specific to guide selection.
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.
2 tool updates
v1.0.0- First observed
hasdata_google_scholar_cite_getScholarCitationFormats - First observed
hasdata_google_scholar_scholar_getScholarSearchResults
TDQS
Scored across 2 tools
The two tools serve clearly distinct purposes: one performs searches across Google Scholar, while the other retrieves citation formats for a previously returned result. There is no functional overlap, and their complementary relationship is explicit.
Both names share the same provider prefix and follow a snake_case get-style verb, making them predictable. The resource segment differs (cite vs scholar), but this is minor and does not obscure meaning.
With only two tools, the server feels thin for a domain as broad as Google Scholar. However, the two tools cover the most essential scholarly search and citation workflows, so the count is borderline but not unreasonable.
The core workflow of searching for scholarly results and retrieving citation formats is well covered. Missing capabilities like fetching a full author profile or a detailed cited-by list are notable but can be worked around via the existing search parameters.
Maintenance
Related MCP Connectors
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Search Google Scholar for academic papers, citations, and author profiles.
ArXiv preprints + Google Scholar papers, with citation counts in one query.
Search papers, format citations in 60 styles, and verify bibliographies against scholarly sources.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables academic research through Google Scholar by searching for papers, finding author publications, discovering recent research, and identifying highly cited works through web scraping with natural language queries.MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to access academic citations, fetch metadata, and generate BibTeX entries directly from Google Scholar via MCP tools.1MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to search and analyze Google Scholar publications, authors, citations, and download papers.112MIT
- AlicenseAqualityCmaintenanceEnables searching academic literature via Semantic Scholar with relevance filters, batch metadata retrieval, and citation-graph recommendations.5AGPL 3.0