litreview-mcp

Get paper details

get_paper

Read-only

Retrieve a single scholarly paper's abstract, full author list, citation count, and draft APA citation by OpenAlex ID or DOI. Verify author names and title capitalization before using the citation.

Instructions

Get one paper's abstract, full author list, citation count and a draft APA citation. The citation is generated from metadata: check author names and title capitalization before using it. The abstract is null when OpenAlex doesn't have one.

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": {
      "id": "<id>"
    },
    "name": "get_paper"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	OpenAlex ID (W2057673348) or DOI (10.1207/s15326985ep4102_4)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only give readOnlyHint and openWorldHint; the description adds real behavioral detail beyond that: the citation is auto-generated from metadata and can have wrong author names or title casing, and the abstract may be null when OpenAlex lacks it. It doesn't cover rate limits or error behavior on unknown IDs.

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 tight sentences with zero waste, front-loaded with what is returned, then the two caveats an agent most needs (citation reliability, null abstract).

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?

Complete for a simple one-parameter read tool: it describes the return payload, flags the two unreliable fields, and needs no output schema. Only error/miss behavior for an invalid ID is unaddressed.

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% and already documents the id parameter with format examples (OpenAlex ID or DOI). The description reinforces that this is a single-paper lookup keyed by that ID, but adds no new format or constraint detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get one paper's') and enumerates the returned fields: abstract, full author list, citation count, draft APA citation. It is distinguishable from search_papers and get_citations, though it never names those siblings explicitly.

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?

Usage is implied by the single-paper lookup framing (one paper by ID/DOI), and the citation caveat tells the agent to verify before using. There is no explicit when-to-use or when-not-to-use guidance relative to search_papers or get_citations.

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

Deploy Server