Google Scholar MCP Server

ask_research_question

Answer research questions by searching Open Access papers from CORE API. Retrieves abstracts and text snippets as evidence for literature review and evidence-based answers.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>"
    },
    "name": "ask_research_question"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Number of sources to retrieve (max 10)
`question`	Yes	Research question in natural language

Output Schema

Name	Required	Description	Default
`evidence`	Yes
`question`	Yes
`total_sources`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.1.0Jul 6, 2026

TDQS

A4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server