Skip to main content
Glama

List new papers

list_papers
Read-onlyIdempotent

Use this when the user asks what is new: the latest papers in a field, of a study type such as randomized trials, on a body system, or by one author (a name, or an author_id from get_paper). Newest first by the date AgingResearch.News added them, with search_papers' filters and an optional words filter. For the papers that best answer a question, use search_papers.

Input Schema

NameRequiredDescriptionDefault
qNoFull-text filter over title and abstract. Supports "quoted phrases", OR and -exclusions. Results stay in date order; use search_papers for ranked results.
limitNoResults per page.
sinceNoOnly papers added on or after this UTC date (YYYY-MM-DD; a full ISO timestamp is cut to its date).
untilNoOnly papers added on or before this UTC date (YYYY-MM-DD).
authorNoPapers by an author. A name matches every author who answers to it: the words in any order, with or without accents, an initial standing for any name it begins (`sinclair d`). An `author_id` from a paper's `authors_full` (an OpenAlex author id such as `A5022713595`, or an ORCID iD) matches that one person.
cursorNoFrom the last page's `pagination.next_cursor`; keep the other arguments the same.
systemNoBody system key (see `systems`). A paper matches when it involves any of them. Only papers that have been analyzed have systems.
age_linkNoHow the work itself connects to aging.
categoryNoCategory slug. A paper matches when its category or its secondary category is listed.
preprintNo`true` for preprints only, `false` for peer-reviewed papers only. Omit for both.
study_typeNoMain source of evidence.
min_relevanceNoHow closely papers must bear on aging, 0 to 3. Leave out for papers about aging; 1 adds adjacent papers; 0 returns every paper read, most of them not about aging.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedInput schema / properties / age_link / examples
      Removed value: -[
      -  [
      -    "lifespan_healthspan",
      -    "aging_lever"
      -  ]
      -]
    • removedInput schema / properties / category / examples
      Removed value: -[
      -  [
      -    "interventions"
      -  ]
      -]
    • changedInput schema / properties / cursor / description
      Previous value: -"Opaque cursor from `pagination.next_cursor` of the previous page. Keep the other parameters the same."New value: +"From the last page's `pagination.next_cursor`; keep the other arguments the same."
    • changedInput schema / properties / limit / description
      Previous value: -"Results per page, 1 to 25."New value: +"Results per page."
    • removedInput schema / properties / study_type / examples
      Removed value: -[
      -  [
      -    "human_trial",
      -    "animal"
      -  ]
      -]
    • removedInput schema / properties / system / examples
      Removed value: -[
      -  [
      -    "brain-nerves",
      -    "muscle"
      -  ]
      -]
  2. Changed1 schema field changed
    • changedInput schema / properties / system / description
      Previous value: -"Body system key (see `systems`). A paper matches when it involves any of them."New value: +"Body system key (see `systems`). A paper matches when it involves any of them. Only papers that have been analyzed have systems."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: results are ordered 'Newest first by the date AgingResearch.News added them' and the tool supports 'search_papers' filters and an optional words filter.' It does not describe return format or pagination, but the added ordering semantics are meaningful.

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?

The description is two tightly written sentences with zero waste. The primary use case is front-loaded, followed immediately by the alternative, and every phrase earns its place.

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?

For a 12-parameter read-only list tool with full schema coverage and safety annotations, the definition is nearly complete: it explains selection criteria, ordering, and the sibling alternative. It stops short of describing pagination or return fields, but those gaps are minor given the absence of an output schema and the presence of a documented cursor parameter.

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%, so every parameter is fully documented in the schema. The description generically references 'search_papers' filters and an optional words filter' but adds no syntax or constraints beyond what the schema already provides. Baseline 3 is appropriate.

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 states a specific verb (list) and resource (papers), specifies the scope of 'new' papers by field, study type, body system, or author, and explicitly distinguishes this tool from search_papers. An agent can immediately tell what this tool returns and how it differs from its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit trigger ('Use this when the user asks what is new') and a clear alternative rule ('For the papers that best answer a question, use search_papers'), covering both when to use this tool and when not to.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources