Skip to main content
Glama

google_scholar

Search academic papers and scholarly content on Google Scholar with citation lookups, author/source search, year filters, and pagination.

Instructions

Searches academic papers and scholarly content on Google Scholar, with support for citation lookups, author/source search helpers, year filters, and pagination. [Credits: 5 API credits per request] Notes: Article/result 'id' values from scholar_results (e.g. 7QAkDEkBjpYJ) feed the google_scholar_cite endpoint's query parameter. cluster_id (from inline_links.versions) and cites_id (from inline_links.cited_by) are the tokens used respectively with the cluster and cites parameters on this same endpoint. Pagination uses page (0-indexed); pagination.page_no in the response maps page numbers to result URLs. Returns: { related_searches: [ { title, link } ], scholar_results: [ { title, title_link, id, displayed_link, snippet, inline_links: { versions: { total, link, cluster_id }, cited_by: { total, link, cites_id }, related_pages_link }, resources: [ { title, type, link } ] } ], pagination: { current, page_no: { : url } } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lrNoLimit search to one or multiple languages, used as lang_{language_code}. See Google LR Language Page.
htmlNoRender the response as raw HTML instead of parsed JSON. (default: false)
pageNoPage number of Google Scholar searches. 0 = first page, 1 = second page, etc. (default: 0)
safeNoAdult content filter. Allowed values: active, off. (default: off)
as_rrNoWhether to show only review articles: 1 = enable filter, 0 = show all results. (default: 0)
citesNoUnique article ID to run a 'Cited By' search - returns documents citing the given article. Combine with query to search within citing articles.
queryYesSearch query; supports helpers like author: or source:. Becomes optional if the cites parameter is supplied (combining cites+query refines to citing articles matching the query). Cannot be used together with cluster.
as_sdtNoActs as filter or search type. As filter (article search): 0 = excludes patents (default), 7 = includes patents. As search type: 4 = case law (US courts, all state/federal); can append court codes e.g. as_sdt=4,33,192 (4 must be first, comma-separated).
as_visNoWhether citations are included in results: 1 = exclude citations, 0 = include citations. (default: 0)
as_yhiNoEnding year for results, e.g. as_yhi=2018 excludes results after 2018. Can combine with as_ylo.
as_yloNoStarting year for results, e.g. as_ylo=2018 excludes results before 2018. Can combine with as_yhi.
filterNoEnables (1) or disables (0) the 'Similar Results' and 'Omitted Results' filters. (default: 1)
scisbdNoWhether to include only abstract results (1) or all results (0).
clusterNoUnique ID for an article to fetch all available versions of it. Cannot be used simultaneously with query and cites.
resultsNoNumber of results per page.
languageNoLanguage of the results, e.g. en, es, fr, de. See Google Language Page. (default: en)
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It details credit cost (5 API credits per request), pagination behavior, and return structure (including related_searches, scholar_results, pagination). It does not explicitly state read-only nature, but the context implies it. It is transparent about input-output relations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-sentence overview, then adds credits, usage notes, and return format. It is relatively dense but well-organized, avoiding unnecessary repetition. The return schema is provided in lieu of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 16 parameters and no output schema, the description provides a complete return object definition and explains inter-parameter dependencies. It covers pagination and language filters adequately, making the tool usable without external references.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by clarifying relationships: query becomes optional if cites is provided, cluster cannot be used with query and cites, and IDs from results tie to parameters. This goes beyond individual schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Searches academic papers and scholarly content on Google Scholar' and lists specific capabilities (citation lookups, author/source helpers, year filters, pagination). This distinguishes it from siblings like google_scholar_author (author details) and google_scholar_cite (citation output).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit notes on how to use IDs from results for other endpoints (e.g., 'id' values feed google_scholar_cite, cluster_id and cites_id are used with cluster and cites parameters). It also explains pagination (0-indexed) and provides return schema. However, it lacks direct comparison with all sibling tools, though the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alessandrobenigni/ScrapingDog-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server