pubmed-search-mcp

Overview Schema Source Related Servers Discussions Admin

generate_search_queries

Read-onlyIdempotent

Builds raw PubMed search materials from a topic or PICO element, correcting spelling and returning keywords, MeSH terms, and synonyms for Boolean query construction.

Instructions

Gather search intelligence for a topic - returns RAW MATERIALS for Agent to decide.

This tool provides the BUILDING BLOCKS for search, not finished queries. The Agent decides how to use them.

══════════════════════════════════════════════════════════════════════ TWO USAGE MODES: ══════════════════════════════════════════════════════════════════════

MODE 1: KEYWORD SEARCH (single topic) ───────────────────────────────────── User: "搜尋 remimazolam 的文獻"

Step 1: generate_search_queries("remimazolam") Step 2: Build a Boolean query from returned materials Step 3: analyze_search_query(query="") Step 4: unified_search(query="")

══════════════════════════════════════════════════════════════════════

MODE 2: PICO SEARCH (clinical question) ─────────────────────────────────────── User: "remimazolam 在 ICU 鎮靜比 propofol 好嗎？會減少 delirium 嗎？"

Step 1: Agent extracts P/I/C/O from the clinical question, then calls validate_pico_plan(description=..., p=..., i=..., c=..., o=...) to validate the structured handoff and get a runnable PICO pipeline.

Step 2: For EACH PICO element, call generate_search_queries() IN PARALLEL: - generate_search_queries("ICU patients") → P materials - generate_search_queries("remimazolam") → I materials - generate_search_queries("propofol") → C materials - generate_search_queries("delirium") → O materials

Step 3: Combine materials using Boolean logic: High precision: (P_terms) AND (I_terms) AND (C_terms) AND (O_terms) Recall-oriented: (P_terms) AND (I_terms OR C_terms); validate against eligible seed papers

Step 4: Add Clinical Query filter if appropriate: - filters="clinical_query:therapy" → 治療效果比較 - filters="clinical_query:diagnosis" → 診斷相關 - filters="clinical_query:prognosis" → 預後相關 - filters="clinical_query:etiology" → 病因相關

Step 5: Validate the final query with analyze_search_query()
Step 6: Execute unified_search() with the final Boolean query

Features:

Spelling correction via NCBI ESpell
MeSH term lookup for standardized vocabulary
Synonym expansion from MeSH database
Query analysis: Shows how PubMed actually interprets each query (Agent's understanding vs PubMed's actual interpretation)

Args: topic: Search topic - can be a single keyword or PICO element strategy: Affects suggested_queries (if included) - "comprehensive": Multiple angles, includes reviews (default) - "focused": Adds RCT publication-type filter; study quality still requires appraisal - "exploratory": Broader search with more synonyms check_spelling: Whether to check/correct spelling (default: True) include_suggestions: Include pre-built query suggestions (default: True)

Returns: JSON with RAW MATERIALS: - corrected_topic: Spell-checked topic - keywords: Extracted significant keywords - mesh_terms: MeSH data with preferred terms and synonyms - all_synonyms: Flattened list of all synonyms - suggested_queries: Optional pre-built queries with: - estimated_count: How many results PubMed would return - pubmed_translation: How PubMed actually interprets the query

Input Schema

TableJSON Schema

Name	Required	Default
`topic`	Yes
`strategy`	No	comprehensive
`check_spelling`	No
`include_suggestions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.7.7Oct 7, 2026

addedInput schema / properties / check_spelling / anyOf

Added value: +[
+  {
+    "default": true,
+    "title": "Check Spelling",
+    "type": "boolean"
+  },
+  {
+    "description": "Explicit true/false text, ignoring ASCII case and surrounding whitespace.",
+    "pattern": "^[ \\t\\r\\n]*(?:[tT][rR][uU][eE]|[fF][aA][lL][sS][eE])[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]

removedInput schema / properties / check_spelling / type
```
Removed value: -"boolean"
```

addedInput schema / properties / include_suggestions / anyOf

Added value: +[
+  {
+    "default": true,
+    "title": "Include Suggestions",
+    "type": "boolean"
+  },
+  {
+    "description": "Explicit true/false text, ignoring ASCII case and surrounding whitespace.",
+    "pattern": "^[ \\t\\r\\n]*(?:[tT][rR][uU][eE]|[fF][aA][lL][sS][eE])[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]

removedInput schema / properties / include_suggestions / type
```
Removed value: -"boolean"
```

addedInput schema / properties / strategy / anyOf

Added value: +[
+  {
+    "default": "comprehensive",
+    "enum": [
+      "comprehensive",
+      "focused",
+      "exploratory"
+    ],
+    "title": "Strategy",
+    "type": "string"
+  },
+  {
+    "pattern": "^[ \\t\\r\\n]*(?:[cC][oO][mM][pP][rR][eE][hH][eE][nN][sS][iI][vV][eE]|[fF][oO][cC][uU][sS][eE][dD]|[eE][xX][pP][lL][oO][rR][aA][tT][oO][rR][yY])[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]

removedInput schema / properties / strategy / enum

Removed value: -[
-  "comprehensive",
-  "focused",
-  "exploratory"
-]

removedInput schema / properties / strategy / type
```
Removed value: -"string"
```

Changed9 schema fields changedv0.7.2Sep 13, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / check_spelling / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "string"
-  }
-]

addedInput schema / properties / check_spelling / type
```
Added value: +"boolean"
```

removedInput schema / properties / include_suggestions / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "string"
-  }
-]

addedInput schema / properties / include_suggestions / type
```
Added value: +"boolean"
```

addedInput schema / properties / strategy / enum

Added value: +[
+  "comprehensive",
+  "focused",
+  "exploratory"
+]

addedInput schema / properties / topic / maxLength
```
Added value: +2000
```
addedInput schema / properties / topic / minLength
```
Added value: +1
```

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "generate_search_queriesOutput",
-  "type": "object"
-}New value: +null

First observedv0.5.16Jun 19, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and idempotency are covered. The description adds real behavioral context: reliance on external NCBI ESpell and MeSH services, the note that 'focused' adds an RCT publication-type filter but 'study quality still requires appraisal', and a detailed Returns breakdown. It stops short of stating rate limits or failure modes, so it is strong but not exhaustive.

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 and the Args/Returns blocks earn their place, but the two MODE walkthroughs are very long and largely re-document orchestration that overlaps the sibling tools' own descriptions (e.g. detailed PICO steps and filter syntax). The box-drawing formatting pads length without adding call-time clarity, so it is over-sized relative to the marginal value.

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?

With no output schema and 0% parameter description coverage, the description supplies everything needed: purpose, the two invocation patterns, full parameter semantics, and the exact JSON return fields including estimated_count and pubmed_translation. An agent can call this correctly and interpret the result without consulting other sources.

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 description coverage is 0%, so the description carries the full burden, and it does: 'topic' is explained as 'a single keyword or PICO element', each 'strategy' enum value is given distinct meaning including the caveat that focused adds an RCT filter without guaranteeing quality, and check_spelling/include_suggestions are explained with their defaults. This fully compensates for the bare schema.

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 lines state a specific purpose — 'Gather search intelligence for a topic - returns RAW MATERIALS' and 'BUILDING BLOCKS for search, not finished queries' — and it expands this into concrete outputs (corrected_topic, keywords, mesh_terms, all_synonyms, suggested_queries). This clearly distinguishes it from siblings like unified_search (executes) and analyze_search_query (interprets), and even resolves the naming tension between 'generate_search_queries' and 'not finished queries'.

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 spells out two distinct usage modes with user-intent examples and explicit step-by-step routing to sibling tools (validate_pico_plan, analyze_search_query, unified_search), plus when to apply each clinical_query filter. An agent knows exactly when to pick keyword mode vs PICO mode and what to call next, so 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.

Deploy Server

generate_search_queries

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools