A
licenseNot graded
qualityD
maintenanceAn MCP server that brings AI-powered search and conversation to your FHIR clinical documents.
1
MIT
rx-shortage-mcp
This server helps pharmacists and clinical teams find alternative drugs during a shortage, and re-checks each alternative against live FDA data to detect cascade shortages — preventing the trap of recommending an alternative that is also in short supply.
Tools available:
rx_health— Confirm the server is running and reachable.rx_normalize_drug— Convert messy drug names, brand names, abbreviations, or typos into standardized RxNorm RxCUI identifiers.rx_get_drug_class— Look up a drug's ATC-4 pharmacologic class(es) from RxClass (single-ingredient and combination), so the right class can be selected for finding alternatives.rx_find_alternatives— List sibling drugs within a given ATC-4 class as candidates for clinical evaluation (class membership does not imply clinical interchangeability).rx_check_shortage— Query live openFDA data to determine a drug's current U.S. shortage status, including reasons, therapeutic categories, and last updated date.Cascade shortage check — By chaining the tools (normalize → get class → find alternatives → check shortage for each alternative), the server surfaces which same-class options are also in shortage before any substitution decision is made.
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., "@rx-shortage-mcpAtorvastatin is on backorder — what could I consider instead, and are any of those also short?"
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.
Rx Shortage Alternative Finder (MCP)
A pharmacist gets the alert that metformin is on backorder, opens the drug class, and picks the next agent down the list. Two days later that order bounces too, because the alternative was on the FDA shortage list the whole time. That second shortage is the one nobody thinks to check, and it is the one this server catches.
Rx Shortage Alternative Finder is an MCP server that takes a drug in shortage, finds its same-class alternatives, and re-checks each one against live FDA data, so an LLM can answer "what else could work, and is any of it also short?" in a single pass.
Status: v1, working and tested. Five read-only tools, 22 automated tests plus a live eval, validated end to end in Claude Desktop.
Try it
Connect the server (Quickstart is right below, about two minutes), then ask Claude:
Furosemide is on backorder. What same-class options could we consider, and are any of those also short?
Watch it work the chain live. It normalizes the name through RxNorm, confirms the shortage in openFDA, pulls the loop-diuretic class from RxClass, then checks each sibling in turn. The payoff is the part no single database gives you: as of this writing it flags that bumetanide, the obvious switch, is also in shortage, while torsemide is not. Don't take that on faith. Swap in whatever drug is on your own backorder list and check it yourself.
Related MCP server: DrugWise
Quickstart
You need uv and an MCP client, either Claude Desktop or Claude Code. No API key, no database, nothing else.
git clone https://github.com/Travis-Clement-Dev/rx-shortage-mcp.git
cd rx-shortage-mcp
uv run python -m rx_shortage_mcpThe first run builds the environment and pulls dependencies on its own. The server speaks MCP over stdio, so you normally launch it through a client rather than by hand.
Connect it to Claude Desktop
Add this to claude_desktop_config.json (on macOS, ~/Library/Application Support/Claude/claude_desktop_config.json), then restart Claude Desktop:
{
"mcpServers": {
"rx-shortage": {
"command": "uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/rx-shortage-mcp", "run", "python", "-m", "rx_shortage_mcp"]
}
}
}An optional openFDA key
Everything runs keyless at roughly 240 requests a minute, plenty for interactive use. If you plan to hammer it, a free openFDA key raises the daily ceiling: copy .env.example to .env and set OPENFDA_API_KEY.
How the chain works
Four read-only tools, called in sequence: normalize, classify, find siblings, re-check each. The orchestration lives in the model's reasoning, which is the reason this ships as an MCP server instead of a script.
normalize_drug turns a messy name, brand, or typo into an RxNorm RxCUI.
get_drug_class returns the drug's candidate ATC-4 pharmacologic classes.
find_alternatives lists the same-class siblings.
check_shortage returns the openFDA shortage status for the original and every alternative.
The fan-out in step four is the whole point. Listing same-class drugs is easy. Re-checking each one against the shortage list is the part that turns a list into a decision.
What a full answer looks like
Ask about furosemide and the model returns a ranked, flagged shortlist:
Same-class option (ATC C03CA) | FDA status | Presentations affected | Updated |
furosemide (the one you asked about) | Current shortage | 33 | 06/25/2026 |
bumetanide | Current shortage | 12 | 06/25/2026 |
torsemide | No shortage reported | 0 | — |
piretanide | No shortage reported | 0 | — |
The reflexive switch from furosemide is bumetanide, and bumetanide is short too. Torsemide is the same-class option that is not. That gap is the cascade, and surfacing it before you place the order is the entire job.
(Live national data. Your numbers will differ as shortages change.)
Why this exists
FDA and ASHP tell you a drug is short. Orange Book and the vendor catalogs tell you who else makes the same molecule. Neither one tells you whether the different drug you would actually reach for is short as well. That blind spot, sitting in plain sight between three public data sources, is the reason this exists.
It is built for informatics pharmacists and clinical-data teams, the people who maintain formulary alternatives and build clinical decision support. They care how an answer was assembled as much as what it says, so every drug it names traces to a real RxNorm or RxClass identifier, and the reasoning runs in the open, one tool call at a time.
What it will not do
This is decision support, not a substitution order, and the line matters. RxClass returns every member of a class, including drugs that are the wrong route, the wrong indication, contraindicated, or pulled from the market years ago. The server cannot tell which is which, so it does not pretend to.
Every alternatives response carries a disclaimer that says exactly that. Same pharmacologic class does not mean clinically interchangeable. Route, indication, dosing, and contraindications are never checked here, and the shortage data is national, not your local shelf. A licensed professional weighs the shortlist. The tool only makes sure the shortlist is honest about supply.
Testing
uv run --extra dev pytest # offline unit, safety, and protocol tests
uv run --extra dev pytest -m live # the live eval: the full chain across 15 drugs
npx @modelcontextprotocol/inspector uv run python -m rx_shortage_mcp # poke the tools by handThe safety rule is enforced, not hoped for. A test fails the build if any tool ever frames its output as a substitution instruction or drops the disclaimer. If an import ever fails, the editable install has drifted; reset it with rm -rf .venv uv.lock && uv sync.
Built on public data
RxNorm and RxClass come from the U.S. National Library of Medicine. Shortage data comes from the FDA's openFDA.
This product uses publicly available data from the U.S. National Library of Medicine (NLM), National Institutes of Health, Department of Health and Human Services; NLM is not responsible for the product and does not endorse or recommend this or any other product.
openFDA shortage data is not intended for making decisions about medical care.
License
MIT, © 2026 Travis Clement.
Available Tools
5 toolsrx_check_shortageARead-onlyIdempotent
Check the current U.S. FDA (openFDA) shortage status of a drug.
Queries the openFDA Drug Shortages dataset by generic name and aggregates the
NDC/package-level records into a single status summary. National-level data only —
it does NOT reflect a specific pharmacy's local/regional stock.
Use this twice in the workflow: (1) to confirm the original drug is short, and
(2) to re-check EACH candidate alternative — an alternative may itself be in
shortage (the "cascade" check that is the point of this server).
Args:
drug_name: Generic/ingredient name (e.g. 'furosemide').
Returns:
ShortageResult — drug, in_shortage (bool), overall_status ('Current' /
'To Be Discontinued' / 'Resolved' / 'no_record'), statuses (list of
{status, count}), record_count, last_updated (MM/DD/YYYY or null),
therapeutic_categories, reasons, and next_step guidance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | Generic or ingredient drug name to check, e.g. 'furosemide', 'bumetanide'. Prefer the normalized ingredient name from rx_normalize_drug when you have one. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| drug | Yes | The drug name that was queried. |
| reasons | Yes | Distinct shortage reasons across the records. |
| statuses | Yes | Distinct statuses with their record counts. |
| next_step | Yes | Suggested next action for the agent orchestrating the chain. |
| in_shortage | Yes | True if any record is actively short (Current or To Be Discontinued). |
| last_updated | Yes | Most recent record update date (MM/DD/YYYY), or null. |
| record_count | Yes | Number of shortage records returned for this drug. |
| overall_status | Yes | Most severe status across records, or 'no_record' if none found. |
| therapeutic_categories | Yes | Distinct therapeutic categories across the records. |
TDQS
A4.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's behavioral transparency value is slightly lower. However, it adds important context: queries openFDA dataset, aggregates NDC-level records into summary, and details the return fields. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose sentence, then detailed paragraph, then usage workflow, then Args/Returns. Every sentence is informative and earns its place. No redundancy. Front-loaded with the core purpose.
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 1 parameter and an output schema, the description covers all necessary information. It explains the data source, aggregation, return fields comprehensively, and includes usage workflow. Completeness is high given the tool's complexity.
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 coverage is 100% with a good description. The description adds value by recommending to use the normalized ingredient name from rx_normalize_drug, providing examples (e.g., 'furosemide'), and clarifying 'generic/ingredient name' beyond the 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?
The first sentence clearly states the verb 'check' and the resource 'shortage status' of a drug. It distinguishes from siblings like rx_find_alternatives by specifying it is for shortage checking and describes a specific workflow where it is used twice, distinguishing it from other tools.
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?
Explicitly states when to use: twice in workflow to confirm original drug shortage and re-check alternatives. Also provides a when-not-to-use: 'does NOT reflect a specific pharmacy's local/regional stock.' This gives clear guidance on usage scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rx_find_alternativesARead-onlyIdempotent
List the sibling drugs in an ATC-4 pharmacologic class (RxClass members).
These are CANDIDATE alternatives for a licensed professional to evaluate — NOT a
substitution instruction. Same-class membership does NOT imply clinical
interchangeability (route, indication, contraindications, dosing, and equivalence are
not checked; some members may be withdrawn or combination products). Every response
carries a `disclaimer` that you MUST surface to the user.
After calling this, re-check EACH member's supply with rx_check_shortage to flag the
ones that are also short (the cascade check).
Args:
class_id: ATC-4 class id (e.g. 'C03CA').
Returns:
AlternativesResult — class_id, members (list of {rxcui, name, is_combination}),
count, capped (bool), disclaimer (mandatory), and next_step guidance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| class_id | Yes | An ATC-4 class id from rx_get_drug_class, e.g. 'C03CA'. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of members returned (after any cap). |
| capped | Yes | True if the class had more members than the cap and the list was truncated. |
| members | Yes | Sibling drugs in the class (candidates to evaluate, NOT substitutions). |
| class_id | Yes | The ATC-4 class whose members these are. |
| next_step | Yes | Suggested next action for the agent. |
| disclaimer | Yes | Mandatory safety disclaimer — class membership != clinical interchangeability. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds important context: the disclaimer, possibility of withdrawn/combination products, and need for cascade check. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections and front-loaded with purpose. Every sentence is informative and concise without redundancy. Fits within a reasonable length.
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?
Output schema exists and description explains return fields. Given low complexity (1 param), the description covers all necessary context: purpose, usage, warnings, and next steps. Complete for agent decision-making.
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 coverage is 100% with description for class_id. Description adds value by specifying the source (from rx_get_drug_class) and format example, which aids in correct invocation.
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 clearly states it lists sibling drugs in an ATC-4 pharmacologic class, using specific verb 'List' and resource 'sibling drugs'. It distinguishes from siblings like rx_check_shortage by mentioning the need to cascade check.
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?
Explicitly states these are candidate alternatives for evaluation, not substitution instructions. Provides when-to-use context and instructs to re-check supply with rx_check_shortage, which is a sibling tool. Also mandates surfacing the disclaimer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rx_get_drug_classARead-onlyIdempotent
Resolve a drug to its candidate ATC-4 pharmacologic classes (RxClass).
A drug commonly maps to SEVERAL ATC-4 classes (a pure single-ingredient class plus
combination-product classes). This tool returns them ALL, each flagged
`is_combination`, sorted single-ingredient-first. YOU choose the class: normally the
single-ingredient class matching the drug's main therapeutic use. Pass its `class_id`
to rx_find_alternatives.
Args:
drug_name: Drug/brand name (e.g. 'furosemide', 'Lipitor').
Returns:
DrugClassResult — drug, classes (list of {class_id, class_name, class_type,
is_combination}), count, and next_step guidance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | Drug name (generic, ingredient, or brand — brands like 'Lipitor' work) to look up the pharmacologic class for. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| drug | Yes | The drug name that was queried. |
| count | Yes | Number of ATC-4 classes returned. |
| classes | Yes | All candidate ATC-4 classes, single-ingredient classes first. |
| next_step | Yes | Suggested next action for the agent. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral details: returns all classes, flags combination status, sorting order, and user's role in selecting the class. No contradictions.
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?
Well-structured with bold, bullets, and examples. Front-loaded with main action. Every sentence provides value, though slightly verbose with multiple clauses. Could be tightened but still effective.
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?
Given one parameter, output schema exists, annotations cover safety, and sibling tools provided. Description explains output structure partially and mentions next_step guidance. Sufficient for tool complexity.
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?
Only one parameter 'drug_name' with 100% schema description coverage. Tool description adds examples (generic, ingredient, brand) and clarifies brands like 'Lipitor' work, adding value beyond 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?
The description explicitly states it resolves a drug to candidate ATC-4 pharmacologic classes, using specific verbs and resource names. It distinguishes from sibling tools by explaining the output is used as input to rx_find_alternatives.
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 clear guidance on when to use: returns all classes, each flagged is_combination, sorted single-ingredient-first, and instructs to choose the appropriate class and pass its class_id to rx_find_alternatives. Also gives example drug names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rx_healthARead-onlyIdempotent
Confirm the rx_shortage_mcp server is running and reachable.
A zero-argument connectivity check. Use it to verify the server is live
before running the shortage → alternatives → cascade-check chain.
Returns:
HealthStatus: {
"status": str, # "ok" when healthy
"server": str, # "rx_shortage_mcp"
"version": str, # package version, e.g. "0.1.0"
"next_step": str # what to call next
}
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| server | Yes | |
| status | Yes | |
| version | Yes | |
| next_step | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds return structure fields (status, server, version, next_step) and confirms zero arguments, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: first states purpose, second gives usage guidance and return fields. No redundant information, every sentence 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?
Given zero parameters, full annotation coverage, and described output schema, the description is fully adequate. It explains purpose, usage, and return format completely.
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?
No parameters exist; schema coverage 100%. Description confirms 'zero-argument' and does not need to add parameter details.
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?
Description clearly states it is a connectivity check to confirm server is live, with explicit 'zero-argument connectivity check'. Distinguishes from siblings by positioning as prerequisite before chain.
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?
Explicitly says to use to verify server is live before the chain shortage → alternatives → cascade-check. Does not mention exclusions but context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rx_normalize_drugARead-onlyIdempotent
Normalize a messy drug name/brand/typo to an RxNorm RxCUI and clean name.
This is the FIRST step of the workflow. It uses RxNorm's prescribable search
(exact-then-normalized), falling back to approximate matching for typos.
IMPORTANT: if `match_type` is 'approximate', the result is a best guess — present
the `candidates` to the user and confirm the intended drug before proceeding. Do
not silently assume the top candidate is correct.
Args:
name: The drug name as the user typed it.
Returns:
NormalizeResult — found (bool), rxcui, name (resolved RxNorm name), match_type
('exact' / 'approximate' / 'none'), candidates (ranked, for approximate matches),
and next_step guidance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A messy drug name to normalize: brand ('Lipitor'), generic, salt form ('morphine sulfate'), abbreviation ('HCTZ'), or a typo. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Resolved RxNorm name of the best match, or null. |
| found | Yes | True if any match (exact or approximate) was found. |
| rxcui | Yes | Best-match RxCUI, or null if no match. |
| next_step | Yes | Suggested next action for the agent. |
| candidates | Yes | Ranked candidates for an approximate match (empty for exact). Present these for confirmation. |
| match_type | Yes | 'exact' (confident), 'approximate' (confirm with user), or 'none'. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, safe), description details matching strategy: RxNorm's prescribable search with exact-then-normalized fallback. Discloses that approximate matches are a best guess with candidates list, requiring user confirmation. Completely transparent about behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, workflow context, important behavioral note, parameter description, return value summary. Every sentence is informative. No redundant or vague statements. Front-loaded with key action.
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?
Given tool complexity (normalization with fallback), rich annotations, and presence of output schema, the description is fully complete. It explains the return structure (NormalizeResult with fields), critical edge cases (approximate matches), and integration into a workflow. No gaps.
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 covers 100% of parameters with a good description. The tool description adds value by categorizing acceptable input types (brand, generic, salt form, abbreviation, typo) and explaining the matching behavior that affects parameter interpretation. Adds practical guidance beyond 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?
Description clearly states 'Normalize a messy drug name/brand/typo to an RxNorm RxCUI and clean name.' It positions the tool as the first workflow step, distinguishing it from sibling tools that handle shortages, alternatives, drug class, and health. Specific verb+resource with clear scope.
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?
Explicitly says 'This is the FIRST step of the workflow.' Provides critical guidance: for approximate matches, present candidates to user and confirm intent. Does not explicitly name alternatives but sibling list implies different purposes. Lacks explicit when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v0.1.0- First observed
rx_check_shortage - First observed
rx_find_alternatives - First observed
rx_get_drug_class - First observed
rx_health - First observed
rx_normalize_drug
TDQS
A4.7/5.0
Scored across 5 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: name normalization, class resolution, alternative listing, shortage checking, and health verification. No overlap exists, and the workflow is well-defined.
Naming Consistency4/5
All tools use the 'rx_' prefix and verb_noun pattern (e.g., check_shortage, find_alternatives). The exception is 'rx_health', which lacks a verb, but it is still clear and follows the overall naming scheme.
Tool Count5/5
With 5 tools, the server is well-scoped for a focused domain. Each tool serves a necessary step in the shortage-checking workflow without redundancy or bloat.
Completeness5/5
The tools cover the full intended workflow: normalize drug name, get ATC class, find alternatives, check shortage, and verify server health. No obvious gaps for the stated purpose.
Maintenance
ActivityStale
ResponsivenessNo issues
Related MCP Connectors
Hosted MCP server exposing US hospital procedure cost data to AI assistants
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
MCP-Native LLM Orchestration Agent
Related MCP Servers
- FlicenseBqualityBmaintenanceAn MCP server that provides AI-assisted clinical decision support for medication safety, integrating trusted biomedical sources to detect drug interactions and suggest therapeutic alternatives.51-
- AlicenseAqualityCmaintenanceAn MCP server that enables AI assistants to query U.S. FDA public datasets, including drug adverse events, labeling, recalls, approvals, shortages, NDC directory, and medical device regulatory information.10MIT
- FlicenseNot gradedqualityCmaintenanceAn educational healthcare assistant MCP server that provides medication information, interaction checks, symptom guidance, and health topic searches using local data and a local LLM.-