Skip to main content
Glama
u9401066

pubmed-search-mcp

by u9401066
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

verify_reference_list

Read-onlyIdempotent

Checks a plain-text reference list against PubMed, matching each entry via PMID, DOI, or ECitMatch and returning a JSON report with verification statuses and review flags.

Instructions

Verify a plain-text reference list against PubMed evidence.

First version scope: - Reference-list verification only - Client supplies the extracted reference list text - Backend parses entries and resolves them via PMID / DOI / ECitMatch

Second version scope: - Adds unresolved review workflow for partial_match and unresolved rows - Returns a manual-review queue with retry queries and review checklist - Supports human-in-the-loop acceptance/rejection in client-side workflows

Args: reference_text: Plain-text references, ideally one per line or a numbered reference list extracted from a file. Limited to 200,000 characters / 400,000 UTF-8 bytes; each entry is limited to 4,000 characters / 8,000 UTF-8 bytes. source_name: Optional single-line file label for reporting (up to 255 characters / 512 UTF-8 bytes). max_references: Hard input-entry limit from 1 through 200. Inputs above the selected limit are rejected instead of truncated.

Returns: JSON verification report with parsed fields, matched PubMed evidence, per-reference verification status, and explicit source_unavailable / not_checked rows when evidence could not be assessed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
source_nameNo
max_referencesNo
reference_textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.7.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / max_references / maximum
      Added value: +200
    • addedInput schema / properties / max_references / minimum
      Added value: +1
    • addedInput schema / properties / reference_text / maxLength
      Added value: +200000
    • addedInput schema / properties / reference_text / minLength
      Added value: +1
    • addedInput schema / properties / source_name / maxLength
      Added value: +255
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "verify_reference_listOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.5.16

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare the read-only, idempotent, open-world safety profile, so the bar is lower. The description adds real behavioral context beyond that: resolution mechanisms (PMID/DOI/ECitMatch), that inputs above max_references are rejected rather than truncated, that source_unavailable/not_checked rows are emitted, and the human-in-the-loop review workflow for partial/unresolved rows.

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 Args and Returns sections are well-organized and front-loaded, but the 'First version scope' / 'Second version scope' roadmap paragraphs consume substantial space and do not help an agent invoke the tool correctly. The version meta-commentary is the main structural weakness.

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, but the Returns section describes the JSON verification report and its status values, and all three parameters are documented with limits. Behavioral and parameter context is sufficient for correct invocation, with only the absent when-to-use guidance leaving a gap.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: it documents reference_text formatting and size limits, source_name as an optional reporting label with its own limit, and max_references as a hard limit (1-200) with reject-not-truncate semantics. Only minor gap is that these limits echo the schema constraints without adding syntax guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: 'Verify a plain-text reference list against PubMed evidence.' This distinguishes it from siblings like get_article_references (which fetches an article's own references) by making 'verification' the core action. The version-scope framing is odd but the core purpose is unambiguous.

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

Usage Guidelines2/5

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

The description explains what the tool does and its input format, but never states when to choose it over alternatives or when not to. It contrasts 'First version scope' vs 'Second version scope' rather than contrasting this tool against sibling tools like get_article_references or unified_search, leaving routing to inference.

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