Skip to main content
Glama
FujishigeTemma

semantic-scholar-mcp

search_paper

Search academic papers across disciplines using Semantic Scholar. Filter by publication type, year, venue, citation count, and more to find relevant research.

Instructions

Search for papers using Semantic Scholar. Use 'fields' parameter to customize returned data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesA plain-text search query string. - No special query syntax is supported - Hyphenated query terms yield no matches (replace it with space to find matches).
fieldsNoA comma-separated list of the fields to be returned. The paperId field is always returned. See the resource 'semantic-scholar://fields/paper' for available fields. Examples: - `title,url` - `title,embedding.specter_v2` - `title,authors,citations.title,citations.abstract` paperId,title,abstract,authors,year,citationCount
publicationTypesNoA comma-separated list of publication types to include. Available types: Review, JournalArticle, CaseReort, ClinicalTrial, Conference, Dataset, Editorial, LettersAndComments, MetaAnalysis, News, Study, Book, BookSection Example: `Review,JournalArticle` will return papers with publication types Review and/or JournalArticle
openAccessPdfNoRestricts results to only include papers with a public PDF.
minCitationCountNoRestricts results to only include papers with the minimum number of citations.
publicationDateOrYearNoRestricts results to the given range of publication dates or years (inclusive). Accepts the format `<startDate>:<endDate>` with each date in `YYYY-MM-DD` format. Each term is optional, allowing for specific dates, fixed ranges, or open-ended ranges. In addition, prefixes are suported as a shorthand, e.g. `2020-06` matches all dates in June 2020. Specific dates are not known for all papers, so some records returned with this filter will have a `null` value for publicationDate. `year`, however, will always be present. For records where a specific publication date is not known, they will be treated as if published on January 1st of their publication year. Examples: - `2019-03-05` on March 3rd, 2019 - `2019-03` during March 2019 - `2019` during 2019 - `2016-03-05:2020-06-06` as early as March 5th, 2016 or as late as June 6th, 2020 - `1981-08-25:` on or after August 25th, 1981 - `:2015-01` before or on January 31st, 2015 - `2015:2020` between January 1st, 2015 and December 31st, 2020
yearNoRestricts results to the given publication year or range of years (inclusive). Examples: - `2019` in 2019 - `2016-2020` as early as 2016 or as late as 2020 - `2010-` during or after 2010 - `-2015` before or during 2015
venueNoRestricts results to papers published in the given venues, formatted as a comma-separated list. Input could also be an ISO4 abbreviation. Examples include: - Nature - New England Journal of Medicine - Radiology - N. Engl. J. Med. Example: `Nature,Radiology` will return papers from venues Nature and/or Radiology.
fieldsOfStudyNoA Comma-separated list of fields of study to include. Available fields of study: Computer Science,Medicine,Chemistry,Biology,Materials Science,Physics,Geology,Psychology,Art,History,Geography,Sociology,Business,Political Science,Economics,Philosophy,Mathematics,Engineering,Environmental Science,Agricultural and Food Sciences,Education,Law,Linguistics Example: `Physics,Mathematics` will return papers with either Physics or Mathematics in their list of fields-of-study.
offsetNoStarting position in the list of results
limitNoMaximum number of results to return (max: 100)
Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions the API but omits details on rate limits, authentication, error handling, or sorting. The schema covers parameters but not behavior.

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?

Description is a single sentence, very concise and front-loaded. It wastes no words, though it could be slightly more structured to separate purpose from customization hint.

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

Completeness2/5

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

Given 11 parameters, no output schema, and no annotations, the description provides insufficient context. It does not explain output format, default behavior, or full capabilities. The schema partially compensates, but description lacks completeness for a complex search tool.

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 description coverage is 100%, so baseline is 3. The description adds minimal context (e.g., 'Use fields parameter to customize') beyond what the schema already provides. No parameter enums or additional value added.

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?

Description clearly states it searches papers using Semantic Scholar, specifying the resource and action. It distinguishes from sibling tools (get_authors, get_citation, get_paper) which are for individual retrieval, not search.

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

Usage Guidelines3/5

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

Description implies usage for searching papers but does not explicitly state when to prefer this tool over siblings or provide criteria for exclusion. The context is clear but lacks explicit guidance.

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/FujishigeTemma/semantic-scholar-mcp'

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