Skip to main content
Glama
AnonymousOnyx22

Paper Finder MCP

by AnonymousOnyx22
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List papers by an author

list_author_papers
Read-only

Find and list an author's papers, ranked by citations, with optional year, citation, and open-access filters; resolves name variants through OpenAlex author records.

Instructions

Papers by one author, most cited first. The name is looked up in the OpenAlex author records first, so initials, a different order of the name parts and other spellings of the same person still find the papers, and the papers are then taken from that author id. When OpenAlex has no record for the name, the papers are matched by the name as it is written on them. A showing line says which papers are on this page and how many matched in all, with the page to ask for next. Inputs: author (required, the author name, for example Jane Doe, or an OpenAlex author id like A5108843829), from_year (optional earliest publication year), to_year (optional latest publication year), min_citations (optional, keep only the papers with at least this many citations), open_access_only (optional, false by default), page (optional, which page of results to show, 1 to 400, 1 by default), limit (optional, 1 to 25, default 8). Example prompt: 'list papers by John Dewey on education since 1950.'

Input Schema

NameRequiredDescriptionDefault
pageNoWhich page of results to show, 1 to 400, 1 by default. Pass the page the showing line names to read the next page.
limitNoHow many results to return, 1 to 25.
authorYesThe author name, for example Jane Doe. Initials and other name forms work. An OpenAlex author id like A5108843829 works too.
to_yearNoOnly papers published in or before this year.
from_yearNoOnly papers published in or after this year.
min_citationsNoOnly papers with at least this many citations.
open_access_onlyNoOnly papers with a free to read copy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.7
    • addedInput schema / properties / min_citations
      Added value: +{
+  "description": "Only papers with at least this many citations.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / to_year
      Added value: +{
+  "description": "Only papers published in or before this year.",
+  "maximum": 2100,
+  "minimum": 1900,
+  "type": "integer"
+}
  2. First observedv0.1.3

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover only read-only and open-world, so the description carries the rest and does: it discloses the two-stage author resolution (OpenAlex author records first, name-on-paper fallback), the citation-descending ordering, and the 'showing line' pagination contract. That is behavior an agent cannot get from the annotations.

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, ordering, and resolution behavior, and the example prompt earns its place. The enumerated 'Inputs:' block duplicates the schema and is the main slack in an otherwise well-ordered description.

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?

With no output schema, the description still explains the return shape (per-page listing plus total matched and next page) and the fallback matching path. Nothing essential for correct invocation is missing for a 7-parameter read 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 coverage is 100%, so every parameter is already documented, and the description's trailing 'Inputs:' list largely restates ranges and defaults. It adds only marginal value, such as the concrete 'Jane Doe' / 'A5108843829' author forms and the hint to pass the page from the showing line.

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 resource and scope up front ('Papers by one author, most cited first'), which immediately separates it from find_authors (person lookup) and search_papers (topic search). The verb and result ordering are both explicit.

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 clear context for when this tool applies (you know an author name or OpenAlex author id) and includes a concrete example prompt. It never names a sibling tool or states when to prefer search_papers/find_authors instead, so it stops short of full when/when-not guidance.

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