Skip to main content
Glama
Sign In
smaniches

Semantic Scholar MCP Server

by smaniches
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

semantic_scholar_get_paper

Read-onlyIdempotent

Get paper details. Accepts: S2 ID, DOI:xxx, ARXIV:xxx, PMID:xxx, CorpusId:xxx

Instructions

Get paper details. Accepts: S2 ID, DOI:xxx, ARXIV:xxx, PMID:xxx, CorpusId:xxx

Returns title, abstract, authors, venue, year, citation counts, TLDR,
and open-access PDF link for one paper, e.g. paper_id='ARXIV:1706.03762'.
Set include_citations / include_references to also list citing and
referenced papers (fetched in parallel, 1-100 per page each). Paginate
the two directions independently with citations_offset/references_offset;
JSON output exposes citations_page.next and references_page.next.
Results are cached
in memory for 5 minutes; an unknown ID raises a not-found error. Client-side
requests use a 1.0-second unkeyed interval and a conservative 1.1-second
authenticated default; explicitly higher S2-assigned quotas can be configured.
429/502/503 responses retry automatically with backoff. Returns
Markdown by default, response_format='json' for raw JSON. To fetch many
papers at once use semantic_scholar_bulk_papers.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.17
    • addedInput schema / $defs / PaperDetailsInput / properties / citations_offset
      Added value: +{
+  "default": 0,
+  "description": "Pagination offset for citing papers (default 0)",
+  "minimum": 0,
+  "title": "Citations Offset",
+  "type": "integer"
+}
    • addedInput schema / $defs / PaperDetailsInput / properties / references_offset
      Added value: +{
+  "default": 0,
+  "description": "Pagination offset for referenced papers (default 0)",
+  "minimum": 0,
+  "title": "References Offset",
+  "type": "integer"
+}
  2. Changed1 schema field changedv1.2.13
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_paper_detailsOutput",
-  "type": "object"
-}New value: +null
  3. Changed5 schema fields changedv1.2.12
    • changedInput schema / $defs / PaperDetailsInput / properties / citations_limit / description
      Previous value: -"Max citations to return"New value: +"Max citing papers returned when include_citations=true (1-100, default 10)"
    • changedInput schema / $defs / PaperDetailsInput / properties / include_citations / description
      Previous value: -"Include citing papers"New value: +"Also list papers that cite this one (default false)"
    • changedInput schema / $defs / PaperDetailsInput / properties / include_references / description
      Previous value: -"Include referenced papers"New value: +"Also list papers this one cites (default false)"
    • changedInput schema / $defs / PaperDetailsInput / properties / paper_id / description
      Previous value: -"Paper ID: S2 ID, DOI:xxx, ARXIV:xxx, PMID:xxx, CorpusId:xxx"New value: +"Paper ID: a 40-character S2 hex ID ('649def34f8be52c8b66281af98ae884c09aef38b'), 'DOI:10.18653/v1/N18-3011', 'ARXIV:1706.03762', 'PMID:19872477', 'CorpusId:215416146', 'ACL:W12-3903', or 'URL:https://...'"
    • changedInput schema / $defs / PaperDetailsInput / properties / references_limit / description
      Previous value: -"Max references to return"New value: +"Max referenced papers returned when include_references=true (1-100, default 10)"
  4. Changed2 schema fields changedv1.2.6
    • addedInput schema / $defs / PaperDetailsInput / properties / api_key / deprecated
      Added value: +true
    • changedInput schema / $defs / PaperDetailsInput / properties / api_key / description
      Previous value: -"API key (overrides SEMANTIC_SCHOLAR_API_KEY env var)"New value: +"API key (overrides SEMANTIC_SCHOLAR_API_KEY env var). Deprecated: prefer the environment variable. Removal planned for v2.0.0."
  5. Changed1 schema field changedv1.0.3
    • addedInput schema / $defs / PaperDetailsInput / properties / api_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "API key (overrides SEMANTIC_SCHOLAR_API_KEY env var)",
+  "title": "Api Key"
+}
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnly/idempotent/openWorld), but the description adds substantial operational context the annotations cannot: a 5-minute in-memory cache, a not-found error on unknown IDs, client-side request intervals (1.0s unkeyed / 1.1s authenticated), automatic retry with backoff on 429/502/503, and Markdown-by-default output. This is exactly the kind of behavior an agent needs to set retry expectations and pacing.

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?

Front-loaded with purpose and accepted IDs, then returns, then flags/pagination, then cache/rate-limit behavior. Dense but well ordered; the rate-limit and backoff detail is somewhat peripheral to selecting or calling the tool but does earn its place for an agent that must pace requests.

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

Completeness5/5

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

No output schema exists, so the description carries the return-value burden and does so: it lists title, abstract, authors, venue, year, citation counts, TLDR, and OA PDF link, plus the shape of paginated citation/reference output (citations_page.next). Error, caching, and format behavior are all covered, leaving nothing an agent needs to invoke it correctly.

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?

With schema description coverage reported at 0%, the description compensates well by naming the accepted ID prefixes (DOI/ARXIV/PMID/CorpusId), the 1-100 per-page bounds on citation/reference listings, the independent offsets for each direction, and response_format='json'. It omits only the deprecated api_key parameter and its env-var override behavior, which the schema itself documents.

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?

States a specific verb+resource ('Get paper details') and immediately enumerates the accepted identifier forms, so the agent knows exactly what this fetches. It also explicitly routes multi-paper retrieval to semantic_scholar_bulk_papers, distinguishing it from the sibling it most closely overlaps with.

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?

Gives a clear condition for choosing the sibling: 'To fetch many papers at once use semantic_scholar_bulk_papers,' and explains the optional include_citations/include_references toggles. It stops short of stating when to prefer this over search_papers or match_paper, so it's strong but not fully exclusionary.

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

Deploy Server

Other Tools