Skip to main content
Glama

search

Query PubMed with Boolean, MeSH, and field tags to get hit counts, PMIDs, dates, journals, titles, authors, DOIs, and PMC links, with sorting, paging, and date range filters.

Instructions

检索 PubMed,返回命中数及 PMID、日期、期刊、标题、作者、DOI、PMC、文献类型。

term 使用英文 PubMed 语法:resorption[Title]、"root resorption"[tiab]、AND/OR/NOT、截词 *。 布尔算子写大写,引号只包短语,括号须配对。MeSH 请核对实际执行式:写错的带引号词会报 quotedphrasesnotfound,不带引号可能改写成别的概念;有命中不证明原短语存在。 sort: pub_date / relevance / author;不能按期刊质量排序。 field 可用 Title、Title/Abstract、Journal、Author、Affiliation、Language、Grant、PMID 等; 未支持值会报错。MeSH/文献类型请写进 term 的 [MeSH Terms]/[Publication Type] 标签。 日期按发表日期;mindate/maxdate 接受 YYYY、YYYY-MM、YYYY-MM-DD 或斜杠写法。 单端日期自动补另一端并提示。reldate=0 不限,正数为最近天数;和显式日期同时给时做 AND。 retmax 默认 20,上限 1000;retstart 为零起始偏移,上限 9998,最多可翻前 9999 条。 只要计数用 count;需要题录直接 search,无需先 count。as_json=True 返回完整解析和结构化记录。 detail: full 默认完整题录;brief 仅 PMID/日期/标题/全部文献类型;ids 仅 PMID,不取元数据或检查撤稿类型。 各档保留查询警告;brief 省略字段不表示缺失,ids 的 returned 计 PMID 数、esummary_missing 为 null。 先读 ⚠️:改写后的命中数不等于原查询命中数;0 条不证明主题无文献。PMC 号不保证立即可下载。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "term": "<term>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNo
termYes
fieldNo
detailNofull
retmaxNo
as_jsonNo
maxdateNo
mindateNo
reldateNo
retstartNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses caps (retmax default 20 / max 1000, retstart zero-based max 9998, so only the first 9999 records are reachable), date-interaction semantics (reldate ANDed with explicit dates, single-sided dates auto-filled), and failure modes (quotedphrasesnotfound, field validation errors). It warns that rewritten hit counts diverge from the original query, that zero hits does not prove a topic is empty, and that PMC IDs are not guaranteed downloadable — exactly the kind of caveats annotations would otherwise supply.

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?

Dense and information-rich with little filler, but the ordering is loose — return fields, query syntax, sorting, dates, pagination, detail modes, and finally warnings are interleaved, and the '先读 ⚠️' pointer at the end refers back to caveats already presented above it. Nearly every sentence earns its place, but the structure could be tighter and the warning block front-loaded.

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

Completeness5/5

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

For a 10-parameter tool with zero annotation coverage, the description covers query construction, all parameter semantics, result caps, degradation modes, and caveats, leaving nothing an agent needs in order to call it safely. An output schema exists, so its additional summary of returned fields is a bonus rather than a necessity.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it touches all ten parameters with meaning beyond types: term query syntax (field tags, uppercase operators, quoting/parenthesis rules, MeSH caution), sort's allowed values, field's supported values and error behavior, mindate/maxdate accepted formats, reldate's 0-vs-positive and AND semantics, retmax/retstart numeric limits, detail's enum effects, and as_json's payload shape. This is materially more than the bare schema provides.

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?

Opens with a specific verb+resource ('检索 PubMed') and immediately enumerates the returned fields (命中数、PMID、日期、期刊、标题、作者、DOI、PMC、文献类型). It also separates itself from the sibling tool 'count' by stating that counting alone should go there, so an agent can choose 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?

Gives explicit routing rules: use count for counts only, use search directly when records are needed without a prior count step. It also documents per-mode guidance for detail (full/brief/ids) including that ids skips metadata and retraction-type checks, and notes the negative constraint that sorting by journal quality is impossible.

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