openi
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@openifind chest X-ray images of pneumonia"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-openi-server — Open-i Medical Image Search for Claude Code (MCP Server + CLI + Plugin)
Search medical, clinical, radiological and dental images from your terminal and from Claude Code — powered by Open-i (the U.S. National Library of Medicine's Open Access Biomedical Image Search Engine). No API key, no sign-up, no rate-limit token — Open-i is a fully public research API, and this project is the fastest way to query it from an AI coding agent or a shell.
This repository gives you several ways to reach the same Open-i search engine, all sharing one tested core (openi_client.py):
# | Component | What it is | How you use it |
1 | Claude Code plugin | A |
|
2 |
| A model-invocable Skill ( | The quick way: one slash command finds + returns (or embeds) the best image. Claude also triggers it on its own while writing notes. |
3 | MCP server ( | A Model Context Protocol server exposing a | Claude Code (or any MCP client) calls it for you, mid-conversation, and returns images as Markdown links. |
4 |
| A standalone terminal command. | You type |
5 | Manual | The classic, no-plugin way to wire up component #3. | Useful if you don't want to use the plugin/marketplace system, or need per-project config. |
The Open-i API is public and requires no API key.
ℹ️ API reference: always double-check the parameters and codes against the official docs at https://openi.nlm.nih.gov/services. This project targets the
GET /api/searchendpoint documented there.
⚠️ Don't confuse Open-i with NCBI's E-utilities.
openi.nlm.nih.gov(this project's only dependency) genuinely needs no key at all — it's a fully open, unauthenticated REST endpoint. A different, related NLM service — the NCBI E-utilities API ateutils.ncbi.nlm.nih.gov/www.ncbi.nlm.nih.gov(used for things like PubMed/PMC full-text lookups) — does require (or strongly recommend) an API key for higher rate limits. This project never calls that API: thearticle_urlfield in each result is just a plain, human-clickable link built from thepmcidOpen-i already returns (e.g.https://www.ncbi.nlm.nih.gov/pmc/articles/PMC123456/), not an authenticated API call. So: no key needed anywhere in this repo, today or if it grows — just be aware the two services are not the same thing if you extend this project to query NCBI directly.
Table of contents
Related MCP server: PubMed MCP Server
What can I search for?
Open-i indexes figures, charts, X-rays, CT/MRI scans, ultrasound, histology and clinical photographs extracted from PubMed Central articles and other NLM collections. Typical uses:
A dentistry reference:
openi "dental anatomy" --type gA clinical photo of a procedure:
openi "oral incision" --type phA radiograph:
openi "panoramic radiograph mandible" --type xA chart/diagram for a paper or slide deck:
openi "bone remodeling diagram" --type g
Requirements
Python 3.10 or newer (
python3 --version)Internet access to
https://openi.nlm.nih.gov(public, no API key/account needed)The Claude Code CLI — verify with
claude --versionEither of these, depending on which install path you pick:
uv— for the plugin install path (recommended, no venv needed)pip + the ability to create a virtual environment (
python3 -m venv) — for the manual install path
Windows notes
This project is fully tested on Windows (Git Bash + PowerShell), with two small differences from the Linux/macOS commands used throughout this README:
Venv layout:
python -m venv .venvcreates.venv\Scripts\python.exeon Windows, not.venv/bin/python. Theopenilauncher already detects both automatically — you only need to adjust the path yourself when typing aclaude mcp add/.mcp.jsoncommand by hand.$(pwd)substitution: this only works in a POSIX-style shell (Git Bash, WSL). In PowerShell/cmd, write the absolute path directly instead:# PowerShell — from inside the cloned repo claude mcp add openi -s user -- "E:\path\to\mcp-openi-server\.venv\Scripts\python.exe" "E:\path\to\mcp-openi-server\server.py"
Everything else (the openi command, cli.py, server.py) behaves identically on Windows once the venv is created — console output is forced to UTF-8 internally, so accented characters and the … ellipsis print correctly even on a legacy cp1252 terminal.
Quick start (60 seconds)
Fastest path — install as a plugin
No clone, no venv, no pip install. Just needs uv on your PATH. Run these three lines (in your shell or inside a Claude Code session as /plugin ...):
claude plugin marketplace add LeviReisJs/mcp-openi-server
claude plugin install openi@openi-marketplace
claude mcp list # should show: plugin:openi:openi ... ✓ ConnectedThen, in any Claude Code session, just ask — e.g. /openi:medical-image dental anatomy — or let Claude reach for it on its own. Done.
Or — standalone CLI / manual install
Use this if you want the openi terminal command, or prefer not to use the plugin system.
# 1. Clone the repository
git clone https://github.com/LeviReisJs/mcp-openi-server.git
cd mcp-openi-server
# 2. Create an isolated Python environment and install the two dependencies
python3 -m venv .venv
source .venv/bin/activate # Windows (PowerShell): .venv\Scripts\Activate.ps1
pip install -r requirements.txt
# 3. Try the standalone CLI right away
python cli.py "dental anatomy" -n 5# 4a. Register the MCP server with Claude Code — macOS / Linux / Git Bash:
claude mcp add openi -s user -- "$(pwd)/.venv/bin/python" "$(pwd)/server.py"# 4b. Register the MCP server with Claude Code — Windows PowerShell
# (run from inside the cloned repo; write out the absolute path):
claude mcp add openi -s user -- "$PWD\.venv\Scripts\python.exe" "$PWD\server.py"Verify either path with claude mcp list — you should see openi ... ✓ Connected.
That's it. The rest of this README explains each piece in depth.
0. Install as a Claude Code plugin (recommended)
This repository is itself a Claude Code plugin (.claude-plugin/plugin.json) and a self-hosted marketplace (.claude-plugin/marketplace.json) for that one plugin. This is the easiest, most portable way to get search_openi_images into Claude Code — no manual venv, no pip install, no absolute paths to configure. It works because the plugin's MCP entry uses uv run with the ${CLAUDE_PLUGIN_ROOT} variable (resolved automatically by Claude Code to wherever the plugin was installed), so uv fetches mcp and httpx into an ephemeral environment on first run — you never touch a venv.
Install (one-time)
# Add this repo as a marketplace (only needs to be done once)
claude plugin marketplace add LeviReisJs/mcp-openi-server
# Install the "openi" plugin from it
claude plugin install openi@openi-marketplaceYou can run the same two commands from inside an interactive Claude Code session using the slash-command form instead:
/plugin marketplace add LeviReisJs/mcp-openi-server
/plugin install openi@openi-marketplaceVerify
claude plugin list # shows: openi@openi-marketplace ... enabled
claude mcp list # shows: plugin:openi:openi ... ConnectedOr, inside a session, run /mcp to see it listed as a connected server, and /context to confirm the plugin is loaded.
Requirements for the plugin path specifically
uvinstalled and on yourPATH(the plugin's MCP server is launched viauv run, which needsuvitself — everything else,uvinstalls automatically on first launch).No Python venv, no
pip install -r requirements.txtneeded for this path —uvhandlesmcpandhttpxtransparently, cached after the first run.
Updating / removing
claude plugin marketplace update openi-marketplace # pull the latest plugin.json from GitHub
claude plugin update openi # update the installed plugin
claude plugin uninstall openi # remove it
claude plugin marketplace remove openi-marketplace # stop tracking this marketplace entirelyPrefer the manual route (no plugin system, no marketplace)? Skip to section 3 — it still works exactly as before and is fully supported.
1. The MCP server
server.py uses the official MCP Python SDK (FastMCP) and communicates over stdio — exactly what Claude Code expects. It exposes two tools:
search_openi_images— the main search tool.openi_reference— returns the filter-code cheat sheet (image types, specialties, article types) without leaving the conversation.
Install
cd mcp-openi-server
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt # installs: mcp, httpxRun it standalone (optional smoke test)
You normally never launch this by hand — Claude Code does. But you can confirm it starts:
python server.pyIt will wait silently for MCP messages on stdin. Press Ctrl+C to stop. (Seeing nothing is correct: stdio servers don't print to the console.)
The search_openi_images tool
Parameter | Type | Default | Meaning |
| string | — (required) | Search terms, in English (the agent translates for you). |
| int |
| Start index of the result window. |
| int |
| End index of the result window. |
| string | none | Image-type filter code(s), e.g. |
| string | none | Specialty code(s), e.g. |
| string | none | Article-type code(s). |
Returns a clean object:
{
"query": "dental anatomy",
"total": 42,
"returned": 5,
"api_url": "https://openi.nlm.nih.gov/api/search?query=dental+anatomy&m=1&n=5",
"results": [
{
"title": "Dental anatomy of the mandibular molar",
"image_url": "https://openi.nlm.nih.gov/imgs/512/1/PMC123/fig1.png",
"thumbnail_url": "https://openi.nlm.nih.gov/imgs/150/1/PMC123/fig1.png",
"summary": "Figure 1. Cross-section showing enamel, dentin and pulp.",
"article_url": "https://openi.nlm.nih.gov/pmc/articles/PMC123456/",
"uid": "PMC123-fig1"
}
]
}On failure it returns { "error": "...", "status": 400, "query": "..." }. HTTP 400 (bad request) and 500 (server error) from the API are caught and reported clearly, as are timeouts and network problems.
2. The openi terminal command
The quick shortcut. Run a search and get formatted results straight in your console — no Claude session required.
openi "dental anatomy"Make openi available everywhere
Pick one of these:
Option A — symlink onto your PATH (recommended):
# from inside the repo
chmod +x openi
ln -s "$(pwd)/openi" ~/.local/bin/openi # make sure ~/.local/bin is on your PATH
openi "panoramic radiograph"The openi launcher automatically finds and uses the project's .venv, so it works from any directory.
Option B — install as a console script:
source .venv/bin/activate
pip install . # reads pyproject.toml, installs an `openi` command
openi "dental caries"Option C — just call it directly (no install):
python cli.py "dental caries"CLI options
openi [-h] [-m START] [-n END] [-t TYPE] [-s SPECIALTY] [-a ARTICLE_TYPE]
[--json] [--markdown] [--timeout SECONDS] query [query ...]Flag | Meaning |
| Start index (default 1). |
| End index (default 10). |
| Image type, e.g. |
| Specialty code, e.g. |
| Article-type code. |
| Print raw JSON (great for piping into |
| Print Markdown with inline |
| HTTP timeout in seconds (default 30). |
Examples
openi "oral incision" --type ph -n 5 # 5 clinical photos
openi "bone remodeling" --type g --markdown # diagrams, as Markdown
openi "mandible fracture" --json | jq '.results[].image_url'Language note: the CLI sends your text to Open-i as-is (there is no LLM in the loop here). Open-i is English-only, so type English terms —
openi "dental caries", notopeni "cárie". Inside Claude Code, the agent translates automatically (see below).
3. Install the server into Claude Code (manual, no plugin)
If you already installed via section 0, you can skip this — it's the same end result via a different mechanism.
This is the manual way to make search_openi_images available in every Claude Code session, without using the plugin/marketplace system.
The exact command
From inside the cloned repo (so $(pwd) resolves correctly):
claude mcp add openi -- "$(pwd)/.venv/bin/python" "$(pwd)/server.py"openiis the name the server will have inside Claude Code.Everything after
--is the command Claude Code runs to start the server.Using the
.venvPython guarantees themcpandhttpxdependencies are found.
Add -s user to make it available in all your projects (not just the current directory):
claude mcp add openi -s user -- "$(pwd)/.venv/bin/python" "$(pwd)/server.py"Verify
claude mcp list # should show: openiOr, inside an interactive Claude Code session, run the slash command /mcp to see connected servers and their tools.
Alternative A — uv (no manual venv)
If you use uv:
claude mcp add openi -- uv run --directory "$(pwd)" --with mcp --with httpx python server.pyAlternative B — commit a .mcp.json (share with your team)
Copy the provided template and edit the absolute paths:
cp .mcp.json.example .mcp.json{
"mcpServers": {
"openi": {
"command": "/ABSOLUTE/PATH/mcp-openi-server/.venv/bin/python",
"args": ["/ABSOLUTE/PATH/mcp-openi-server/server.py"]
}
}
}Anyone who opens the project in Claude Code will be prompted to enable the openi server automatically.
Alternative C — Claude Desktop
Add the same block to claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/claude_desktop_config.json,
Windows: %APPDATA%\Claude\claude_desktop_config.json) and restart the app.
Removing it
claude mcp remove openiUsing it inside Claude Code (let the agent do it for you)
The quick way: the /openi:medical-image skill
When you install this as a plugin, it ships a Skill called medical-image. That gives you a fast, explicit way to trigger an image search without describing the whole workflow every time:
/openi:medical-image radiografia panorâmica de fratura de mandíbulaClaude runs the skill, which tells it to: translate the term to English, pick the right image-type filter, call search_openi_images, choose the most relevant result, and hand it back as a ready-to-paste Markdown image with a [Fonte] link. The skill also knows how to place the image directly into a note when you're working in a notes vault (e.g. Obsidian) — right under the relevant heading, with the citation kept — and can download it for offline use if your vault syncs to a phone/tablet.
Because it's model-invocable, Claude will also reach for the skill on its own when you're writing study notes and a figure would help — you don't have to type the slash command.
Or just ask in natural language
You never have to call any command — just ask, and Claude Code decides to use the tool and hands you back an image. Try prompts like:
"Search Open-i for a diagram of dental anatomy and show me the best image."
"Preciso de uma foto clínica de uma incisão oral para uma apresentação — busca no Open-i e me manda o link em Markdown." (Portuguese is fine — the agent translates the query to English before searching.)
"Find an X-ray of a mandible fracture on Open-i and embed it here."
Because the tool's description tells the agent to render results as Markdown image links, Claude will reply with something you can paste anywhere:

*Figure 1. Cross-section showing enamel, dentin and pulp.* — [Source](https://openi.nlm.nih.gov/pmc/articles/PMC123456/)You can also nudge the agent to filter: "only clinical photos" → it sets it="ph"; "only charts/diagrams" → it="g"; "dentistry specialty" → sp="d".
Filter codes reference
Values below come from the official OAS 2.0 spec at https://openi.nlm.nih.gov/services. Inside Claude Code you can also call the openi_reference tool to print them.
Image type (it / --type)
[xg, xm, x, u, ph, p, mc, m, g, c]
Code | Meaning (common ones) |
| graphics — charts, diagrams, illustrations |
| photograph — clinical / gross photo |
| X-ray |
| mammography |
| X-ray angiography |
| ultrasound |
| CT scan |
| MRI |
| microscopy / histology |
| PET |
Specialties (sp / --specialty)
[b, bc, c, ca, cc, d, de, dt, e, en, f, eh, g, ge, gr, gy, h, i, id, im, n, ne, nu, o, or, ot, p, py, pu, r, s, t, u, v, vil]
(e.g. d is the dentistry-related specialty; consult the site for the full legend.)
Article types (at / --article-type)
[ab, bk, bf, cr, dp, di, ed, ib, in, lt, mr, ma, ne, ob, pr, or, re, ra, rw, sr, rr, os, hs, ot]
Other endpoint parameters (advanced, supported by openi_client.py)
coll (collections: pmc, cxr, usc, hmd, mpx), favor (rank by), fields (search in), plus lic, sub, vid, hmp — see the official docs.
The Portuguese → English translation rule
Open-i's index is English-only. This project handles that in two different ways depending on the entry point:
MCP server (Claude Code): the
search_openi_imagesdocstring explicitly instructs the LLM agent to translate any Portuguese term to English before fillingquery. So"odontolegista"becomesforensic dentistry,"cárie"becomesdental caries, etc. — automatically.openiCLI: there is no LLM, so you should type English terms.
Common translations the agent uses:
Portuguese | English (sent to Open-i) |
incisão oral | oral incision |
odontolegista | forensic dentistry |
anatomia dental | dental anatomy |
radiografia panorâmica | panoramic radiograph |
cárie | dental caries |
How it works internally
┌────────────────────┐
Claude Code ──stdio──▶ server.py │ (MCP tool: search_openi_images)
└─────────┬──────────┘
│ imports
Your terminal ─────────▶ cli.py (openi) │
│ imports
▼
┌────────────────────┐ HTTPS GET
│ openi_client.py ├────────────▶ openi.nlm.nih.gov/api/search
│ • build params │◀──────────── JSON (200 / 400 / 500)
│ • call API (httpx) │
│ • parse + clean │
└────────────────────┘openi_client.py is the single source of truth: it builds the query parameters, calls the API with httpx, handles HTTP 400/500 and network/timeout errors, strips HTML out of captions, turns relative image paths into absolute URLs, and returns a tidy list of {title, image_url, thumbnail_url, summary, article_url}. Both server.py and cli.py just call it.
Troubleshooting
Symptom | Fix |
| Run |
Plugin installed but | Make sure |
| Re-run the |
Tool errors with "Could not reach Open-i" | Check your internet/proxy; confirm |
| You're not using the venv Python. Point Claude Code at |
No results | Ensure the query is English, broaden the terms, and drop |
HTTP 400 | A filter code is invalid — check the reference table. |
| Finish section 2 (symlink onto PATH or |
Project layout
mcp-openi-server/
├── .claude-plugin/
│ ├── plugin.json # Plugin manifest — makes this repo installable via `claude plugin install`
│ └── marketplace.json # Self-hosted marketplace listing the "openi" plugin (source: "./")
├── skills/
│ └── medical-image/
│ └── SKILL.md # The `/openi:medical-image` skill (quick find + embed)
├── server.py # MCP server (FastMCP, stdio) — the search "engine" for Claude Code
├── cli.py # Standalone CLI implementation
├── openi # Bash launcher so you can run `openi "…"` from anywhere
├── openi_client.py # Shared core: API call + response parsing (used by both)
├── requirements.txt # Runtime deps: mcp, httpx
├── pyproject.toml # Packaging + `openi` console-script entry point
├── .mcp.json.example # Template to auto-load the server per project in Claude Code (manual path)
├── LICENSE # MIT
└── README.md # This fileLicense
MIT. Open-i content itself is subject to the terms of the U.S. National Library of Medicine — see https://openi.nlm.nih.gov.
Available Tools
2 toolsopeni_referenceA
Return the Open-i filter code reference (image types, specialties, article types).
Handy when you need to look up which filter code corresponds to what, without leaving the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It merely states the output type but does not disclose any side effects, authentication needs, rate limits, or output structure. For a read-only reference tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the action and purpose. No extraneous information; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is nearly complete. It explains when to use the tool and what it returns. A slight gap is the lack of output format description, but overall it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially 100%. The description adds no parameter-level detail, but none is needed. The baseline of 3 is exceeded because the tool's simplicity means no additional semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a filter code reference for image types, specialties, and article types, using a specific verb and resource. It implicitly distinguishes from the sibling tool 'search_openi_images' by focusing on reference lookup rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: looking up filter codes without leaving the conversation. However, it does not explicitly exclude cases when the sibling tool would be more appropriate or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_openi_imagesA
Search Open-i (NLM) for medical, clinical, graphical and dental images.
Open-i (https://openi.nlm.nih.gov) is the U.S. National Library of Medicine's open-access biomedical image search engine. It indexes figures, charts, X-rays, photographs and illustrations from PubMed Central articles and other collections. No API key is required.
┌──────────────────────────────────────────────────────────────────────┐
│ ⚠️ TRANSLATION RULE — READ THIS BEFORE CALLING THE TOOL │
│ │
│ The Open-i index is ENGLISH-ONLY. You (the LLM agent) MUST translate │
│ every Portuguese term the user gives you into English BEFORE putting │
│ it into query. Never send Portuguese to the API. │
│ │
│ "incisão oral" -> "oral incision" │
│ "odontolegista" -> "forensic dentistry" │
│ "anatomia dental" -> "dental anatomy" │
│ "radiografia panorâmica"-> "panoramic radiograph" │
│ "cárie" -> "dental caries" │
│ │
│ If the user writes in English already, pass it through unchanged. │
└──────────────────────────────────────────────────────────────────────┘
Args: query: The search terms, IN ENGLISH (translate first — see rule above). m: Start index of the result window (1-based). Default 1. n: End index of the result window. Default 10. Ask for a small window (e.g. m=1, n=10) unless the user wants more. it: Image Type filter. One or more comma-separated codes from [xg, xm, x, u, ph, p, mc, m, g, c]. Most useful: g = graphics / charts / diagrams / illustrations ph = photograph (clinical / gross photo) x = X-ray xm = mammography xg = angiography u = ultrasound c = CT m = MRI mc = microscopy / histology p = PET Leave empty to search all image types. sp: Specialties filter. Comma-separated codes, e.g. "d" for dentistry. Full set: [b, bc, c, ca, cc, d, de, dt, e, en, f, eh, g, ge, gr, gy, h, i, id, im, n, ne, nu, o, or, ot, p, py, pu, r, s, t, u, v, vil]. Leave empty for all specialties. at: Article Type filter. Comma-separated codes from [ab, bk, bf, cr, dp, di, ed, ib, in, lt, mr, ma, ne, ob, pr, or, re, ra, rw, sr, rr, os, hs, ot]. Leave empty for all article types.
Returns: A dict with keys: query - the (English) query that was actually sent total - total number of matches Open-i reports returned - how many results are in this response api_url - the exact URL that was requested (for transparency) results - a clean list; each item has: title, image_url, thumbnail_url, summary, article_url, uid
To show a result to the user, render the image with Markdown:

and cite the source with [Source](article_url).
On failure the dict instead has:
error - a human-readable message
status - the HTTP status code if the API responded (400/500/…)
| Name | Required | Description | Default |
|---|---|---|---|
| m | No | ||
| n | No | ||
| at | No | ||
| it | No | ||
| sp | No | ||
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses no API key required, English-only index, translation requirement, result structure, error format, pagination parameters, filter options, and rendering guidance. Does not mention rate limits or destructive actions (irrelevant for search). Comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured: brief intro, prominent translation rule box, parameter list, return format. Each section earns its place. Slight verbosity but organized for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes return value (dict with keys) and error handling. Covers filtering options (image type, specialty, article type). Includes rendering instructions. No output schema, but complete for a search tool. Only missing comparison to sibling 'openi_reference', but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description compensates fully. Each parameter (query, m, n, it, sp, at) is explained with defaults, usage hints, and code lists. Adds critical translation rule for 'query' and practical advice for 'n'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Open-i for medical images, specifying resource (Open-i/NLM), verb (search), and scope (medical, clinical, graphical, dental). The sibling 'openi_reference' suggests different functionality, so this tool's purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit translation rule: translate Portuguese to English before querying. Recommends small result windows. Implicitly guides when not to use (if query is in Portuguese without translation). No direct comparison to sibling, but clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have completely different purposes: one is for looking up filter codes, the other for searching images. There is no overlap or ambiguity.
Both tools follow a consistent 'openi_verb_noun' pattern using snake_case, making them predictable.
With only 2 tools, the server feels thin for a biomedical image search engine. A couple more tools (e.g., fetching image details, listing filters) would be appropriate.
The search tool covers the primary use case, but there is no way to retrieve dynamic filter options or individual image metadata beyond what the search returns, leaving minor gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
Search biomedical literature, get article details, find related articles, and explore MeSH terms
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceProvides AI systems with access to peer-reviewed medical information from StatPearls, enabling searches for diseases and medical conditions with comprehensive, reliable content formatted in AI-friendly Markdown.1
- AlicenseBqualityDmaintenanceEnables AI assistants to search and retrieve biomedical research articles from PubMed's database of over 35 million citations, including metadata, abstracts, MeSH terms, and full-text PDFs when available.11MIT
- AlicenseBqualityDmaintenanceEnables searching and retrieving images from Wikipedia Commons with detailed metadata including licenses and authors.23910MIT
- AlicenseAqualityDmaintenanceEnables LLMs to search FDA drug labels and adverse event data via the OpenFDA API, supporting natural language queries for drug safety information.2MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LeviReisJs/mcp-openi-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server