pubmed-search-mcp

Overview Schema Source Related Servers Discussions Admin

save_pipeline

Destructive

Persist a YAML/JSON search pipeline under a name for reuse in unified_search, with optional tags, description, and workspace/global storage scope.

Instructions

Save a pipeline configuration for later reuse.

The config format is identical to unified_search's pipeline parameter (YAML or JSON). Saved pipelines can be loaded later by name: unified_search(pipeline="saved:weekly_remimazolam")

Args: name: Unique identifier (alphanumeric + hyphens/underscores, max 64 chars). Overwrites if name already exists (upsert semantics). config: Pipeline YAML/JSON string. Same format as unified_search pipeline param. tags: Bounded array of canonical tags (e.g., ["anesthesia", "sedation"]). description: Human-readable description of the pipeline's purpose. scope: Storage scope - "workspace" (project-level, git-trackable), "global" (user-level, cross-project), or "auto" (workspace if available, otherwise global). Default: "auto".

Returns: Confirmation with pipeline metadata.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	Yes
`tags`	No
`scope`	No	auto
`config`	Yes
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.7.7Oct 7, 2026

addedInput schema / properties / scope / anyOf

Added value: +[
+  {
+    "default": "auto",
+    "enum": [
+      "auto",
+      "workspace",
+      "global"
+    ],
+    "title": "Scope",
+    "type": "string"
+  },
+  {
+    "pattern": "^[ \\t\\r\\n]*(?:[aA][uU][tT][oO]|[wW][oO][rR][kK][sS][pP][aA][cC][eE]|[gG][lL][oO][bB][aA][lL])[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]

removedInput schema / properties / scope / enum

Removed value: -[
-  "auto",
-  "workspace",
-  "global"
-]

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

changedInput schema / properties / tags / anyOf

Previous value: -[
-  {
-    "items": {
-      "maxLength": 64,
-      "minLength": 1,
-      "pattern": "^[A-Za-z0-9](?:[A-Za-z0-9_.-]{0,63})$",
-      "type": "string"
-    },
-    "maxItems": 20,
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "maxLength": 64,
+      "minLength": 1,
+      "pattern": "^[A-Za-z0-9](?:[A-Za-z0-9_.-]{0,63})$",
+      "type": "string"
+    },
+    "maxItems": 20,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  },
+  {
+    "contentMediaType": "application/json",
+    "contentSchema": {
+      "anyOf": [
+        {
+          "items": {
+            "maxLength": 64,
+            "minLength": 1,
+            "pattern": "^[A-Za-z0-9](?:[A-Za-z0-9_.-]{0,63})$",
+            "type": "string"
+          },
+          "maxItems": 20,
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Tags"
+    },
+    "description": "One JSON-encoded container; the decoded value must satisfy contentSchema.",
+    "maxLength": 1000000,
+    "type": "string"
+  },
+  {
+    "description": "One JSON code fence; after removing the fence, decode JSON and validate against x-pubmed-decodedSchema.",
+    "maxLength": 1000000,
+    "pattern": "^\\s*```(?:[jJ][sS][oO][nN])?[ \\t]*\\r?\\n[\\s\\S]*\\r?\\n```\\s*$",
+    "type": "string",
+    "x-pubmed-decodedSchema": {
+      "anyOf": [
+        {
+          "items": {
+            "maxLength": 64,
+            "minLength": 1,
+            "pattern": "^[A-Za-z0-9](?:[A-Za-z0-9_.-]{0,63})$",
+            "type": "string"
+          },
+          "maxItems": 20,
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Tags"
+    },
+    "x-pubmed-encoding": "fenced-json"
+  }
+]

Changed12 schema fields changedv0.7.2Sep 13, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / config / maxLength
```
Added value: +100000
```
addedInput schema / properties / config / minLength
```
Added value: +1
```
addedInput schema / properties / description / maxLength
```
Added value: +2000
```
addedInput schema / properties / name / maxLength
```
Added value: +64
```
addedInput schema / properties / name / minLength
```
Added value: +1
```

addedInput schema / properties / name / pattern

Added value: +"^[a-z0-9](?:[a-z0-9_-]{0,63})$"

addedInput schema / properties / scope / enum

Added value: +[
+  "auto",
+  "workspace",
+  "global"
+]

addedInput schema / properties / tags / anyOf

Added value: +[
+  {
+    "items": {
+      "maxLength": 64,
+      "minLength": 1,
+      "pattern": "^[A-Za-z0-9](?:[A-Za-z0-9_.-]{0,63})$",
+      "type": "string"
+    },
+    "maxItems": 20,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / tags / default
```
Previous value: -""New value: +null
```
removedInput schema / properties / tags / type
```
Removed value: -"string"
```

changedOutput schema / (root)

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

First observedv0.5.16Jun 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description explains that saving overwrites an existing name (upsert semantics) and details storage scope semantics — workspace is git-trackable, global is cross-project, auto resolves at runtime. It does not cover permissions/errors, and the upsert language sits in mild tension with idempotentHint=false, but the destructive behavior itself is disclosed clearly.

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?

Front-loads the one-line purpose, then uses Args/Returns structure with a compact usage example. Mostly efficient; the inline example and the repeated 'same format as unified_search pipeline param' remark cost a little redundancy but each earns its place.

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?

With no output schema, the 'Returns: Confirmation with pipeline metadata' line is a reasonable (if thin) return note, and the description covers format, naming, tags, scope, and overwrite behavior for a 5-parameter mutation tool. Only operational details like permission requirements or failure modes are absent.

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 must carry all parameter meaning, and it does: name format/limits plus overwrite behavior, config format equivalence, tags as a bounded array of canonical tags with examples, description purpose, and all three scope values with defaults. This is a strong compensation for an undocumented 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?

Specific verb+resource ('Save a pipeline configuration') plus scope ('for later reuse'), and it distinguishes itself from siblings by naming the load path (unified_search(pipeline="saved:...")) and implying the inverse of load_pipeline/delete_pipeline. An agent can tell instantly what this does and how saved data flows back into unified_search.

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

Usage Guidelines4/5

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

It gives clear usage context: the config format matches unified_search's pipeline parameter, pipelines are reusable by name, and the example shows the round trip. It stops short of explicit when-to-use/when-not rules against neighbors such as schedule_pipeline or list_pipelines, so it is clear context without exclusions.

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

Deploy Server

save_pipeline

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools