Skip to main content
Glama

get_article_references

Read-onlyIdempotent

Fetch the references cited by a PubMed article to locate foundational papers, methodology sources, or verify claims.

Instructions

Get the references (bibliography) of a PubMed article.

Returns the list of articles that this paper cites in its bibliography. This is the OPPOSITE of find_citing_articles:

  • get_article_references: Papers THIS article cites (backward in time)

  • find_citing_articles: Papers that cite THIS article (forward in time)

═══════════════════════════════════════════════════════════════ 📚 BACKWARD CITATION SEARCH (Foundation Discovery) ═══════════════════════════════════════════════════════════════

Direction: Source Paper → Papers it cited (BACKWARD in time)

USE CASES: ──────────

  • 🏛️ Find foundational papers: Core works the field builds on

  • ⚗️ Methodology sources: Papers describing techniques used

  • 📖 Background reading: Build understanding of a topic

  • 🔍 Verify claims: Check sources for specific assertions

═══════════════════════════════════════════════════════════════ EXAMPLE WORKFLOW: ═══════════════════════════════════════════════════════════════

Start with a recent review article

get_article_references(pmid="38123456", limit=50) → Get the bibliography of this review

Find most-cited foundational papers

get_citation_metrics(pmids="last", sort_by="citation_count") → Identify which references are the most influential

Read a foundational paper

fetch_article_details(pmids="12345678") → Get full details of an important reference

Args: pmid: PubMed ID of the source article ("12345678" or "PMID:12345678"). limit: Maximum number of references to return (1-100, default: 20).

Returns: List of referenced articles with details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pmidYesComplete identifier string; optional identifier prefix, official article URL, or inline backticks. No numbers, foreign hosts, URL queries/fragments or partial identifiers.
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.7.7
    • addedInput schema / properties / limit / anyOf
      Added value: +[
      +  {
      +    "default": 20,
      +    "maximum": 100,
      +    "minimum": 1,
      +    "title": "Limit",
      +    "type": "integer"
      +  },
      +  {
      +    "description": "ASCII decimal integer; the integer branch's bounds apply after conversion.",
      +    "maxLength": 32,
      +    "pattern": "^[ \\t\\r\\n]*-?(?:0|[1-9][0-9]*)[ \\t\\r\\n]*$",
      +    "type": "string"
      +  }
      +]
    • removedInput schema / properties / limit / maximum
      Removed value: -100
    • removedInput schema / properties / limit / minimum
      Removed value: -1
    • removedInput schema / properties / limit / type
      Removed value: -"integer"
    • addedInput schema / properties / pmid / description
      Added value: +"Complete identifier string; optional identifier prefix, official article URL, or inline backticks. No numbers, foreign hosts, URL queries/fragments or partial identifiers."
    • addedInput schema / properties / pmid / examples
      Added value: +[
      +  "33053718",
      +  "PMID:33053718",
      +  "https://pubmed.ncbi.nlm.nih.gov/33053718/"
      +]
    • addedInput schema / properties / pmid / format
      Added value: +"pubmed-pmid"
    • addedInput schema / properties / pmid / x-pubmed-input
      Added value: +"pmid"
  2. Changed8 schema fields changedv0.7.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • removedInput schema / properties / pmid / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "integer"
      -  }
      -]
    • addedInput schema / properties / pmid / maxLength
      Added value: +512
    • addedInput schema / properties / pmid / minLength
      Added value: +1
    • addedInput schema / properties / pmid / type
      Added value: +"string"
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "title": "Result",
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "get_article_referencesOutput",
      -  "type": "object"
      -}New value: +null
  3. First observedv0.5.16

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds directional semantics and a worked multi-tool workflow, but says nothing about error behavior for an invalid/unknown pmid, whether missing references yield an empty list, or pagination beyond the limit cap. With annotations carrying the behavioral load, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core statement is front-loaded and the example workflow genuinely helps an agent chain calls, but the ASCII banner blocks, emoji headings and repeated direction framing consume a large fraction of the text without adding decision-relevant content. Information is real but over-formatted for its size.

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?

There is no output schema, and the description gives only a thin return statement ('List of referenced articles with details'), but the direction, scoping, example chaining and error-free happy path make the tool callable correctly. A short note on return fields or empty-result behavior would close the remaining gap.

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 50%: pmid is richly documented in the schema (prefixes, URL form, backticks, rejection rules), while limit carries only bounds. The description restates pmid formats ('12345678' or 'PMID:12345678') and the limit range/default, both of which already appear in the schema, so it adds no meaning beyond the structured fields. Baseline 3.

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 verb+resource ('Get the references (bibliography) of a PubMed article') and immediately positions it against a named sibling: 'This is the OPPOSITE of find_citing_articles'. The backward-vs-forward citation contrast lets an agent pick the right tool without opening either schema.

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?

Provides explicit when-to-use categories (foundational papers, methodology sources, background reading, verifying claims) and an explicit alternative with the selecting condition (get_article_references = papers this article cites; find_citing_articles = papers that cite it). Nothing is left to inference.

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