Skip to main content
Glama
u9401066

pubmed-search-mcp

by u9401066
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

prepare_figure_search

Read-onlyIdempotent

Prepare a scientific figure or image for biomedical literature search: returns the image for vision analysis and extraction of English search terms.

Instructions

Analyze a scientific figure or image for literature search.

═══════════════════════════════════════════════════════════════════════ 🔬 VISION-TO-LITERATURE SEARCH (Experimental) ═══════════════════════════════════════════════════════════════════════

This tool enables searching for scientific literature based on images.

WORKFLOW (the host agent performs the analysis and search): ─────────────────────────────────────────────────────────

  1. Provide an image (URL or base64-encoded)

  2. This tool returns the image using MCP ImageContent protocol

  3. YOU (the Agent) analyze the image using your vision capabilities

  4. Extract relevant ENGLISH search terms from the image

  5. Call search_biomedical_images() or unified_search() with extracted terms when literature retrieval is within the user-requested scope

  6. Return both the analysis and search results to the user

⚠️ IMPORTANT RULES: ────────────────

  • ALL search queries must be in ENGLISH (Open-i requirement)

  • This tool returns an image and guidance; it does not invoke a vision model

  • The host agent controls any subsequent search within its permissions

  • If the image shows a medical condition, extract the medical term in English

SEARCH TYPES: ─────────────

  • "comprehensive": General analysis, extract all relevant terms (default)

  • "methodology": Focus on methods, equipment, techniques shown

  • "results": Focus on data, graphs, statistical findings

  • "structure": Focus on molecular/chemical structures

  • "medical": Focus on clinical/medical imaging findings

USE CASES: ──────────

  • 📊 Scientific figures → Find papers with similar data/charts

  • 🔬 Microscopy images → Find related research

  • 🧬 Molecular structures → Find papers about the compound

  • 📈 Graphs/plots → Find papers with similar analyses

  • 🏥 Medical images → Find case reports or clinical studies

  • ⚗️ Lab equipment → Find methodology papers

IMPORTANT: ────────── Image observations are search hypotheses that require source verification. Follow the user-requested scope and the host agent's execution rules. Use English medical terminology in all search queries.

Args: source: Exactly one typed image source: {"kind": "base64", "data": "data:image/png;base64,..."} or {"kind": "url", "url": "https://example.org/figure.png"}. context: Optional context about what to look for in the image search_type: Type of analysis focus (comprehensive/methodology/results/structure/medical)

Returns: List containing: - ImageContent: The image for you to analyze - TextContent: Instructions for next steps

Example: prepare_figure_search(source={"kind": "url", "url": "https://example.com/figure1.png"}) prepare_figure_search( source={"kind": "base64", "data": "data:image/png;base64,iVBORw0..."} )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYes
contextNo
search_typeNocomprehensive

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv0.7.7
    • addedInput schema / $defs / InlineImageSource / properties / kind / anyOf
      Added value: +[
+  {
+    "const": "base64",
+    "title": "Kind",
+    "type": "string"
+  },
+  {
+    "pattern": "^[ \\t\\r\\n]*(?:[bB][aA][sS][eE]64)[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]
    • removedInput schema / $defs / InlineImageSource / properties / kind / const
      Removed value: -"base64"
    • removedInput schema / $defs / InlineImageSource / properties / kind / type
      Removed value: -"string"
    • addedInput schema / $defs / URLImageSource / properties / kind / anyOf
      Added value: +[
+  {
+    "const": "url",
+    "title": "Kind",
+    "type": "string"
+  },
+  {
+    "pattern": "^[ \\t\\r\\n]*(?:[uU][rR][lL])[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]
    • removedInput schema / $defs / URLImageSource / properties / kind / const
      Removed value: -"url"
    • removedInput schema / $defs / URLImageSource / properties / kind / type
      Removed value: -"string"
    • addedInput schema / properties / search_type / anyOf
      Added value: +[
+  {
+    "default": "comprehensive",
+    "enum": [
+      "comprehensive",
+      "methodology",
+      "results",
+      "structure",
+      "medical"
+    ],
+    "title": "Search Type",
+    "type": "string"
+  },
+  {
+    "pattern": "^[ \\t\\r\\n]*(?:[cC][oO][mM][pP][rR][eE][hH][eE][nN][sS][iI][vV][eE]|[mM][eE][tT][hH][oO][dD][oO][lL][oO][gG][yY]|[rR][eE][sS][uU][lL][tT][sS]|[sS][tT][rR][uU][cC][tT][uU][rR][eE]|[mM][eE][dD][iI][cC][aA][lL])[ \\t\\r\\n]*$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / search_type / enum
      Removed value: -[
-  "comprehensive",
-  "methodology",
-  "results",
-  "structure",
-  "medical"
-]
    • removedInput schema / properties / search_type / type
      Removed value: -"string"
    • addedInput schema / properties / source / anyOf
      Added value: +[
+  {
+    "discriminator": {
+      "mapping": {
+        "base64": "#/$defs/InlineImageSource",
+        "url": "#/$defs/URLImageSource"
+      },
+      "propertyName": "kind"
+    },
+    "oneOf": [
+      {
+        "$ref": "#/$defs/InlineImageSource"
+      },
+      {
+        "$ref": "#/$defs/URLImageSource"
+      }
+    ],
+    "title": "Source"
+  },
+  {
+    "contentMediaType": "application/json",
+    "contentSchema": {
+      "discriminator": {
+        "mapping": {
+          "base64": "#/$defs/InlineImageSource",
+          "url": "#/$defs/URLImageSource"
+        },
+        "propertyName": "kind"
+      },
+      "oneOf": [
+        {
+          "$ref": "#/$defs/InlineImageSource"
+        },
+        {
+          "$ref": "#/$defs/URLImageSource"
+        }
+      ],
+      "title": "Source"
+    },
+    "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": {
+      "discriminator": {
+        "mapping": {
+          "base64": "#/$defs/InlineImageSource",
+          "url": "#/$defs/URLImageSource"
+        },
+        "propertyName": "kind"
+      },
+      "oneOf": [
+        {
+          "$ref": "#/$defs/InlineImageSource"
+        },
+        {
+          "$ref": "#/$defs/URLImageSource"
+        }
+      ],
+      "title": "Source"
+    },
+    "x-pubmed-encoding": "fenced-json"
+  }
+]
    • removedInput schema / properties / source / discriminator
      Removed value: -{
-  "mapping": {
-    "base64": "#/$defs/InlineImageSource",
-    "url": "#/$defs/URLImageSource"
-  },
-  "propertyName": "kind"
-}
    • removedInput schema / properties / source / oneOf
      Removed value: -[
-  {
-    "$ref": "#/$defs/InlineImageSource"
-  },
-  {
-    "$ref": "#/$defs/URLImageSource"
-  }
-]
  2. Addedv0.7.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, but the description adds substantial behavior beyond that: it returns ImageContent plus TextContent, does NOT invoke a vision model, imposes an English-only query constraint (Open-i requirement), and notes the host agent controls any subsequent search within its permissions. These are exactly the behavioral facts an agent cannot get from the annotations.

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 workflow is well front-loaded and scannable, but the block is heavy with ASCII rules and emoji, and several points are restated — the English-only requirement appears in both IMPORTANT RULES and IMPORTANT, and the 'follow user-requested scope' idea is repeated. Some USE CASES bullets duplicate the SEARCH TYPES section, so not every line earns its place.

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 tool with no output schema, the description fully explains the return payload (ImageContent + TextContent) and the post-call workflow, and it documents all three parameters. An agent has everything needed to call it and to interpret the result correctly.

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 the load, and it does: it shows concrete source shapes for both base64 and URL kinds, describes context as 'what to look for in the image', and enumerates the meaning of each search_type value. It stops short of syntax-level detail (URL bounds, base64 size limits) but covers the semantic intent of all three parameters.

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?

States a specific verb and resource ('Analyze a scientific figure or image for literature search') and immediately clarifies the actual mechanism — it returns the image via MCP ImageContent rather than performing the search itself. This distinguishes it cleanly from siblings like search_biomedical_images and unified_search, which it names explicitly.

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?

Provides an explicit numbered workflow, states when to invoke (image provided, literature retrieval in scope), names the exact follow-up tools (search_biomedical_images(), unified_search()), and even gives the condition for the next step. Nothing about when/when-not to use it 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

Other Tools