Skip to main content
Glama
Sign In
pubmed-clinical-mcp

pubmed-clinical-mcp

by jxia622
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

fetch_pmc_full_text

Retrieve full-text sections from PubMed Central using a PMCID or PMID for access to legal clinical literature.

Instructions

Fetch legal PubMed Central full-text sections when a PMCID is available.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fetch_pmc_full_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
pmidNo
pmcidNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention what happens if both pmid and pmcid are provided, if none are provided, or any authentication or rate limits. The term 'legal' hints at compliance but is vague.

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?

The description is a single, front-loaded sentence with no waste. It earns its place by stating the core action and condition, though it could be slightly expanded without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two optional params with no schema descriptions, no annotations, and an output schema that may cover return values, the description is too brief. It fails to explain parameter interaction or fallback behavior, leaving critical gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description should explain parameter usage. It only implies pmcid is preferred but does not clarify the role of pmid, whether they are interchangeable, or what happens when both are provided.

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 uses a specific verb ('Fetch') and resource ('legal PubMed Central full-text sections'), clearly distinguishing it from siblings like check_full_text_availability or fetch_pubmed_articles. The condition 'when a PMCID is available' clarifies scope.

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?

The description implies usage when a PMCID is available but does not explicitly state when not to use it, nor does it mention alternatives like check_full_text_availability for availability checks or fetch_pubmed_articles for non-PMC content.

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