scholar-mcp

Batch Resolve Identifiers

batch_resolve

Read-only

Resolve lists of paper, DOI, patent, and ISBN identifiers to full records across scholarly sources; large batches return a job handle for polling results.

Instructions

Resolve a list of paper, patent, or book identifiers to full records.

Uses the S2 batch endpoint for paper IDs/DOIs, with OpenAlex fallback. An OpenAlex-sourced paper ("source": "openalex") has the same keys as an S2 one for the requested fields, with paperId null. Patent numbers (such as EP1234567A1) are auto-detected and resolved via the EPO OPS API when configured. ISBNs (prefixed ISBN:) are resolved via Open Library.

Identifiers fan out across three upstream sources, so a large batch runs long and is then handed back as a job handle to poll with get_job_result rather than the records themselves.

Input Schema

Name	Required	Description	Default
`fields`	No	Field set preset (applies to paper results only).	standard
`identifiers`	Yes	List of S2 IDs, DOIs (prefixed ``DOI:``), plain DOIs, patent numbers (such as ``EP1234567A1`` or ``US11234567B2``), or ISBNs (prefixed ``ISBN:``, such as ``ISBN:9780201633610``).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.1.1Nov 5, 2026

changedInput schema / properties / identifiers / description

Previous value: -"List of S2 IDs, DOIs (prefixed ``DOI:``), plain DOIs,\npatent numbers (e.g. ``EP1234567A1``, ``US11234567B2``),\nor ISBNs (prefixed ``ISBN:``, e.g. ``ISBN:9780201633610``)."New value: +"List of S2 IDs, DOIs (prefixed ``DOI:``), plain DOIs,\npatent numbers (such as ``EP1234567A1`` or ``US11234567B2``),\nor ISBNs (prefixed ``ISBN:``, such as ``ISBN:9780201633610``)."

Changed4 schema fields changedv1.10.0Sep 8, 2026
- addedOutput schema / additionalProperties
```
Added value: +true
```
- removedOutput schema / properties
```
Removed value: -{
-  "result": {
-    "type": "string"
-  }
-}
```
- removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
- removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```
First observedv1.9.0Aug 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds behavior the agent cannot infer: identifiers fan out across three upstream sources, so large batches take a long time and return a job handle rather than records. It also discloses the OpenAlex fallback shape (same keys as S2 for the requested fields, with paperId null), which is exactly the kind of non-obvious result detail an agent needs.

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 purpose and then layered with the fallback and job-handle behavior, so an agent can stop reading early if it only needs the basics. A few parentheticals repeat the schema's own examples (EP1234567A1, ISBN: prefix), which is mild redundancy rather than bloat.

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?

This is a moderately complex multi-source aggregator, and the description covers fallback behavior, identifier routing, and the async job-handle path, while an output schema handles return shapes. What's left out is when the batch flips from direct records to a job handle and how partial failures or unresolvable IDs surface.

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%, so the baseline would be 3; the description earns more by explaining the identifier grammar as a whole (auto-detected patents, ISBN: prefixes) and by clarifying that the fields preset applies only to paper results. It still doesn't say which fields each preset contains or what happens to unresolvable identifiers in the list.

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 opens with a specific verb and resource ("Resolve a list of ... identifiers to full records") and names the entity types covered — papers, patents, books — which separates it from single-record siblings like get_paper or get_book. It also names get_job_result as the follow-up tool, so the agent can place this tool in the workflow without opening any schema.

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 gives concrete routing rules: plain or DOI-prefixed DOIs and S2 IDs go to the S2 batch endpoint with an OpenAlex fallback, patent numbers are auto-detected and sent to the EPO OPS API, and ISBN-prefixed values go to Open Library. It also says that large batches return a job handle to poll with get_job_result. It does not explicitly say when to prefer this over per-record calls such as get_paper for a single identifier, so the contrast is implied rather than stated.

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