pubmed-search-mcp

Overview Schema Source Related Servers Discussions Admin

generate_search_queries

Read-onlyIdempotent

Transforms a research topic into search-ready materials: keywords, MeSH terms, synonyms, and suggested queries with PubMed interpretations, enabling precise Boolean literature searches.

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.

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.9/5.0

Behavior5/5

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior beyond this: it returns raw materials rather than final queries, performs spelling correction via NCBI ESpell, does MeSH/synonym expansion, and can show PubMed's actual interpretation of a query. This gives the agent an accurate model of what the tool does and does not do.

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 front-loaded with purpose and then structured into two clear usage modes, which helps an agent navigate a complex workflow. It is quite long with decorative separators and redundant step numbering, but nearly every section carries operational value, so the verbosity is justified for this tool's complexity.

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, the description fully enumerates the return fields: corrected_topic, keywords, mesh_terms, all_synonyms, and suggested_queries with estimated_count and pubmed_translation. It also covers the two main invocation contexts and how to chain with siblings, so an agent has everything needed to call the tool correctly.

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%, but the description's Args section fully compensates. It explains topic as 'a single keyword or PICO element,' defines all three strategy values with their effects on suggested_queries, states defaults for check_spelling and include_suggestions, and clarifies how the parameters affect behavior.

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 opens with a clear verb and resource: 'Gather search intelligence for a topic' and explicitly frames the output as 'RAW MATERIALS' and 'BUILDING BLOCKS for search, not finished queries.' This distinguishes it from siblings like analyze_search_query and unified_search, whose jobs are to validate and execute 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?

The description provides two explicit usage modes with step-by-step protocols: Mode 1 for single-topic keyword search and Mode 2 for PICO-based clinical questions. It names exact sibling tools to call before and after this tool, including validate_pico_plan, analyze_search_query, and unified_search, so an agent knows when to use this tool versus alternatives.

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