Skip to main content
Glama

find_related_articles

Read-onlyIdempotent

Find articles related to a given PubMed article using PubMed's 'Related Articles' feature to discover similar research.

Instructions

Find articles related to a given PubMed article. Uses PubMed's "Related Articles" feature to find similar papers.

═══════════════════════════════════════════════════════════════ 🔗 CITATION NETWORK EXPLORATION WORKFLOW ═══════════════════════════════════════════════════════════════

This is ONE of THREE tools for exploring citation networks:

1️⃣ find_related_articles() ← YOU ARE HERE │ 📌 Algorithm-based similarity (like PubMed "Similar Articles") │ 📌 Finds papers with similar topics, MeSH terms, authors │ 📌 Good for: Discovering related research you might have missed └─► Returns: Similar papers (not based on citations)

2️⃣ find_citing_articles() │ 📌 Forward citation search (who cited THIS paper?) │ 📌 Finds papers published AFTER the source article │ 📌 Good for: Tracking impact, finding follow-up studies └─► Returns: Papers that cite this article

3️⃣ get_article_references() │ 📌 Backward citation search (what did THIS paper cite?) │ 📌 Finds papers published BEFORE the source article │ 📌 Good for: Finding foundational papers, methodology sources └─► Returns: This article's bibliography

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

Step 1: Start with a key paper find_related_articles(pmid="23132851") → Find similar research directions

Step 2: Explore backward (foundations) get_article_references(pmid="23132851") → Find the foundational papers it builds on

Step 3: Explore forward (impact) find_citing_articles(pmid="23132851") → Find how the field developed after this paper

Args: pmid: PubMed ID of the source article ("12345678" or "PMID:12345678"). limit: Maximum number of related articles to return (1-50, default: 5).

Returns: List of related 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": 5,
      +    "maximum": 50,
      +    "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: -50
    • 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: +50
    • 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": "find_related_articlesOutput",
      -  "type": "object"
      -}New value: +null
  3. First observedv0.5.16

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavior context: results are algorithm-based similarity (topics, MeSH terms, authors), not citation-derived, and papers are not ordered by publication date. It does not mention pagination, rate limits, or error cases for an unknown PMID.

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 purpose is front-loaded in the first two lines, but roughly 30 lines of box-drawing separators, emoji, and a workflow example that largely repeats the numbered sibling list is oversized for a two-parameter tool. Decorative formatting earns no place; the comparative content is the only part that does.

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 simple read-only lookup with two parameters and no output schema, the description is nearly sufficient: it covers what it does, when to use it, inputs, and that it returns 'similar papers'. The return description ('List of related articles with details') is vague and there is no note on ordering or truncation, but annotations carry the safety/idempotency profile.

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 50%; the pmid schema entry itself already documents accepted forms far more precisely (URL, prefix, backticks, rejections) than the description's '12345678' or 'PMID:12345678'. The description restates the limit range/default that the schema already enforces, so it adds little beyond the schema. 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 opening line states a specific verb+resource ('Find articles related to a given PubMed article') and the second line names the underlying mechanism (PubMed's Related Articles feature). The numbered sibling comparison makes it unmistakable versus find_citing_articles and get_article_references.

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 explicitly routes the agent: 'Good for: Discovering related research you might have missed' plus named alternatives for forward and backward citation search, with a three-step example workflow showing when each tool is appropriate. No inference required.

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