scholar-mcp

Batch Resolve Identifiers

batch_resolve

Read-only

Resolve a list of paper, patent, book, or ISBN identifiers into full records via multiple scholarly APIs. Large batches return a job handle to poll for 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. Patent numbers (e.g. 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 upstreams, 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

TableJSON 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 (e.g. ``EP1234567A1``, ``US11234567B2``), or ISBNs (prefixed ``ISBN:``, e.g. ``ISBN:9780201633610``).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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?

Beyond the readOnly/openWorld/non-destructive annotations, it discloses fan-out across S2/OpenAlex/EPO OPS/Open Library, auto-detection of patent numbers, and the async job-handle behavior. These are substantive behaviors not inferable from annotations.

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?

Four dense sentences with no fluff: purpose first, then upstream routing, then asynchronous behavior. Each sentence earns its place, and the structure front-loads the action.

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?

For a batch tool with a rich schema and annotations, it covers the essential operational facts: supported ID types, upstream fallback/configuration, and the expected job-handle flow. With an output schema present, nothing critical is missing.

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%, and the input schema already fully documents identifiers and fields, including examples and the enum. The description adds no new parameter-level semantic guidance; it merely restates identifier categories already present.

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 precise verb-object statement: 'Resolve a list of paper, patent, or book identifiers to full records.' It distinguishes itself from single-item siblings by emphasizing batch/list behavior and the S2 batch endpoint; the explicit identifier scoping makes selection unambiguous.

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?

It provides clear usage context: expected identifier types, upstream routing, and the fact that large batches return a job handle to poll with get_job_result. It does not explicitly name single-identifier alternatives or state when not to use this tool, preventing a 5.

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