Click on "Deploy 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., "@medlineplus-mcp look up metformin for patient education"
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.
Open-source Model Context Protocol server for MedlinePlus Connect, the U.S. National Library of Medicine service for linking clinical codes and medication names to patient-friendly health information.
This server gives an AI agent narrow tools for looking up public MedlinePlus education links. It is intentionally not a medical-record server and does not store patient data.
Agents working near health records need trustworthy reference material, but they should not invent medication side effects, lab explanations, or condition summaries from memory.
medlineplus-mcp keeps the privacy boundary simple:
Send generic lookup terms or codes to MedlinePlus, such as metformin, an RXCUI, an NDC, a LOINC code, an ICD-10-CM code, a CPT code, or a SNOMED CT code.
Keep private chart context local in your own agent or application.
Merge public education links with private patient context only after the lookup result comes back.
Related MCP server: MCP Healthcare Server
lookup_medicationLook up medication education links using:
name: English medication name fallback, such as metformin
rxcui: RxNorm Concept Unique Identifier
ndc: National Drug Code
language: en or es
Spanish medication responses generally require RXCUI or NDC.
lookup_diagnosisLook up diagnosis/problem education links using:
code: ICD-10-CM, ICD-9-CM, or SNOMED CT code
codeSystem: icd10cm, icd9cm, or snomedct
name: optional display name
language: en or es
lookup_lab_testLook up lab-test education links using:
loinc: LOINC code
name: optional display name
language: en or es
lookup_procedureLook up procedure education links using:
code: CPT or SNOMED CT code
codeSystem: cpt or snomedct
name: optional display name
language: en or es
medlineplus_connectLow-level escape hatch for supported MedlinePlus Connect request types.
git clone https://github.com/chrisvo/medlineplus-mcp.git
cd medlineplus-mcp
npm install
npm testnpm startExample MCP config:
{
"mcpServers": {
"medlineplus": {
"command": "node",
"args": ["/absolute/path/to/medlineplus-mcp/src/server.mjs"],
"cwd": "/absolute/path/to/medlineplus-mcp",
"env": {
"MEDLINEPLUS_CACHE_TTL_MS": "43200000"
}
}
}
}MEDLINEPLUS_CACHE_TTL_MS defaults to 12 hours.
MEDLINEPLUS_CACHE_DIR defaults to .cache/medlineplus-mcp; set it to off to disable persistent disk caching.
The server uses two cache layers:
in-memory cache for repeated lookups during the current process,
filesystem cache so repeated lookups survive process restarts.
By default cache files are written under .cache/medlineplus-mcp/ in the server working directory. Cache keys are SHA-256 hashes of the MedlinePlus Connect request URL, and cached payloads contain only the public response from MedlinePlus plus the generic lookup request.
For a different cache folder:
MEDLINEPLUS_CACHE_DIR=/var/cache/medlineplus-mcp npm startTo disable disk caching:
MEDLINEPLUS_CACHE_DIR=off npm startTool responses are JSON text payloads:
{
"request": {
"type": "drug",
"codeSystem": "ndc",
"code": "",
"name": "metformin",
"language": "en"
},
"query_url": "https://connect.medlineplus.gov/service?...",
"attribution": "U.S. National Library of Medicine",
"updated": "2026-07-18T03:05:36Z",
"total_results": 1,
"entries": [
{
"title": "Metformin",
"url": "https://medlineplus.gov/druginfo/meds/a696005.html",
"summary": "",
"source": "American Society of Health-System Pharmacists, Inc."
}
]
}Do not send private chart notes, diagnoses, full medication administration records, names, MRNs, dates of birth, or free-form patient narratives to this server unless you are intentionally sending them to MedlinePlus Connect.
Prefer generic lookups:
Good: metformin
Good: rivaroxaban
Good: 4548-4 for a LOINC lookup
Bad: an entire hospital progress note
MedlinePlus says Connect requests should stay under 100 requests per minute per IP address and recommends caching results for 12-24 hours. This server includes in-memory and disk caching by request URL.
See the official docs:
MedlinePlus content is patient education, not a clinical decision engine. Agents using this MCP should:
cite returned MedlinePlus links,
separate public general education from patient-specific interpretation,
avoid telling users to stop, start, or change medications,
suggest questions for the care team when private clinical context matters.
MIT
Look up MedlinePlus health-topic links for ICD-10-CM, ICD-9-CM, or SNOMED CT diagnosis/problem codes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Diagnosis/problem code. | |
| name | No | Human-readable diagnosis name for context. | |
| language | No | Response language. English supports name fallback for medication queries; Spanish generally needs codes. | en |
| codeSystem | No | icd10cm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('look up') and resource ('MedlinePlus health-topic links'), but does not disclose what happens if the code is not found, any rate limits, or the structure of the returned links. It is minimally transparent.
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?
A single, well-formed sentence that conveys the core purpose without extraneous words. It is front-loaded with the action and specific code systems, making it efficient for quick scanning.
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 the absence of an output schema, the description could be more explicit about the return format (e.g., list of links, titles). However, for a straightforward lookup tool, the mention of 'health-topic links' provides sufficient context for an agent to understand the general outcome. It is reasonably complete.
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 description coverage is 75%, meaning the schema already documents most parameters well. The description adds context that the 'codeSystem' parameter includes ICD-10-CM, ICD-9-CM, or SNOMED CT, which aligns with the schema enum. However, it does not significantly enhance understanding beyond the schema.
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 looks up MedlinePlus health-topic links for diagnosis codes, specifying three code systems (ICD-10-CM, ICD-9-CM, SNOMED CT). This distinguishes it from sibling tools like lookup_medication or lookup_lab_test, which target different medical entities.
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?
While no explicit 'when to use' or 'when not to use' guidance is given, the tool name and description make it obvious that it is intended for diagnosis codes. The context of sibling tools implies alternative tools for medications, labs, procedures, and general MedlinePlus connections, providing indirect usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up MedlinePlus lab-test information using a LOINC code.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Human-readable lab-test name for context. | |
| loinc | Yes | LOINC code. | |
| language | No | Response language. English supports name fallback for medication queries; Spanish generally needs codes. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, side effects, rate limits, prerequisites, or error handling. The description carries the full burden but adds no behavioral context beyond the basic lookup action.
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?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose. Every word is necessary, and there is no redundancy or trivial content.
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 no output schema, the description lacks information about the return format (e.g., plain text, structured data, links). Although the task is simple, the description could be more complete by clarifying what the output contains. The current version is adequate but has clear gaps.
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?
The input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond the schema; it only mentions using a LOINC code. Since schema coverage is high, baseline score of 3 is appropriate.
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 verb 'look up', the resource 'MedlinePlus lab-test information', and the method 'using a LOINC code'. It distinguishes this tool from siblings like lookup_medication, lookup_diagnosis, lookup_procedure, and medlineplus_connect by specifying the type of information and the required identifier.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies that this tool is for lab tests with LOINC codes, but does not mention alternatives or situations where other siblings might be better. Usage context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up medication education links from MedlinePlus Connect using RXCUI, NDC, or an English medication name.
| Name | Required | Description | Default |
|---|---|---|---|
| ndc | No | National Drug Code. | |
| name | No | Medication name, used for English lookup fallback when no code is available. | |
| rxcui | No | RxNorm Concept Unique Identifier. | |
| language | No | Response language. English supports name fallback for medication queries; Spanish generally needs codes. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses source (MedlinePlus Connect) and acceptable inputs, but lacks details on failure modes, data freshness, or behavior if multiple identifiers are provided. Adequate but not 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?
Single sentence conveys purpose, source, and input methods with no wasted words. Front-loaded and efficient.
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?
No output schema, yet description doesn't explain return format or provide examples. Lacks details on error handling or network requirements. For a simple lookup, it's adequate but leaves gaps for an agent.
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 covers all 4 params with descriptions (100% coverage). Description adds context: 'English name fallback' and that the tool uses codes or name. This extra clarity about fallback behavior justifies above baseline.
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?
Description clearly states verb 'look up', resource 'medication education links from MedlinePlus Connect', and acceptable identifiers (RXCUI, NDC, name). Distinguishes from sibling tools (lookup_diagnosis, etc.) by focusing solely on medications.
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?
Implies usage for medication lookups but offers no explicit guidance on when to use vs alternatives, when not to use, or prerequisites. The purpose alone differentiates from siblings, but no exclusions or decision tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up MedlinePlus information for CPT or SNOMED CT procedure codes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Procedure code. | |
| name | No | Human-readable procedure name for context. | |
| language | No | Response language. English supports name fallback for medication queries; Spanish generally needs codes. | en |
| codeSystem | No | cpt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention that the tool is read-only, any authentication requirements, or the nature of the output (e.g., what information is returned). This is insufficient for safe agent invocation.
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?
The description is a single sentence with no superfluous words. It is front-loaded with the action and resource. Every part earns its place.
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?
Despite having no output schema and sparse annotations, the description does not explain what the tool returns (e.g., full MedlinePlus entry, summary, links) or any limitations (e.g., rate limiting, required codes). A lookup tool with only input specs is incomplete for effective agent use.
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?
The input schema provides descriptions for 3 of 4 parameters (75% coverage). The description adds context about MedlinePlus and code systems but does not elaborate on parameter semantics beyond what the schema states. No additional format or syntax guidance.
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 action ('Look up'), the resource ('MedlinePlus information'), and the specific input types ('CPT or SNOMED CT procedure codes'). It distinguishes itself from sibling tools (lookup_medication, lookup_diagnosis, etc.) by focusing on procedure codes.
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 implies usage for procedure code lookups via the input schema and mentions of CPT/SNOMED CT. However, it lacks explicit guidance on when to use this tool over siblings or specific prerequisites (e.g., requiring an authenticated session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Low-level MedlinePlus Connect lookup for supported type/code-system combinations.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| name | No | ||
| type | Yes | ||
| language | No | Response language. English supports name fallback for medication queries; Spanish generally needs codes. | en |
| codeSystem | Yes | drug: rxcui|ndc; diagnosis: icd10cm|icd9cm|snomedct; lab: loinc; procedure: cpt|snomedct |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states it is a 'lookup', implying a read-only operation, but lacks detail on authentication, rate limits, or any potential side effects. The brevity leaves ambiguity.
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?
The description is a single sentence, making it concise. It is front-loaded with the essential verb and object. However, it could benefit from a bit more detail without sacrificing brevity.
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?
With 5 parameters and no output schema, the description should provide more context about the lookup process and expected results. It is too minimal to fully inform an agent about how to invoke the tool correctly.
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 coverage is only 40% (language and codeSystem have descriptions). The description adds no additional meaning to the parameters; it merely echoes 'type/code-system combinations' without clarifying the roles of 'code' and 'name' or how they interact with 'type' and 'codeSystem'.
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 performs a low-level lookup for supported type/code-system combinations. This distinguishes it from the more specific sibling tools (lookup_medication, etc.) by emphasizing its generic nature.
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?
No guidance on when to use this tool versus the more specific siblings. The description does not specify prerequisites, when not to use it, or provide any explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0lookup_diagnosislookup_lab_testlookup_medicationlookup_proceduremedlineplus_connectScored across 5 tools
The four specific lookup tools (medication, diagnosis, lab test, procedure) have clearly distinct purposes. However, medlineplus_connect is a low-level utility that overlaps with all of them, potentially causing confusion if an agent chooses it over the more specific tool.
Four tools use a consistent 'lookup_' prefix, but medlineplus_connect breaks this pattern with a different naming style. The inconsistency is noticeable but not chaotic.
Five tools is a reasonable number for the domain, covering the main clinical code systems (RXCUI, ICD, LOINC, CPT, SNOMED). The count is not excessive and fits the scope well.
The tools cover the major MedlinePlus lookup categories (medication, diagnosis, lab, procedure). The general medlineplus_connect tool fills potential gaps, though a dedicated health-topic search tool might be missing.
Diagnoses, drugs & lab codes: ICD-11, SNOMED, LOINC, RxNorm, MeSH, ATC, CID-10. 33 tools, MIT.
Connect AI clients to biomedical data and tools.
NIH Clinical Tables: ICD-10/9, RxTerms, LOINC, NPI, conditions search. Keyless.
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
