一个用于查询RxNav API的MCP（Model Context Protocol）服务器，专为药物术语标准化和药名归一化设计。
药物名称搜索: 通过药物名称搜索获取RxNorm标准化信息
通用名转换: 实现商品名与通用名的相互转换
ATC分类查询: 获取药物的ATC分类代码和层级信息
成分查询: 获取药物的活性成分信息
Related MCP server: mcp-dailymed
通过药物名称搜索RxNorm概念信息。
参数:
drug_name (string, 必需): 药物名称
limit (number): 返回记录数限制 (1-50)
获取药物的通用名信息。
参数:
drug_name (string, 必需): 药物名称或RxCUI
获取通用名对应的商品名列表。
参数:
generic_name (string, 必需): 通用名
获取药物的ATC分类代码。
参数:
drug_identifier (string, 必需): 药物名称或RxCUI
获取药物的活性成分信息。
参数:
drug_identifier (string, 必需): 药物名称或RxCUI
# 安装依赖
npm install
# 开发模式运行
npm run dev
# 构建
npm run build
# 生产模式运行
npm start# 更新系统
sudo apt update && sudo apt upgrade -y
# 安装Node.js 18+
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
# 验证安装
node --version
npm --version# 创建项目目录
mkdir -p ~/mcp-servers/rxnav
cd ~/mcp-servers/rxnav
# 上传项目文件（使用scp或git clone）
# 方法1: 使用git
git clone <your-repo-url> .
# 方法2: 使用scp从本地上传
# scp -r /path/to/mcp-rxnav/* user@your-server:~/mcp-servers/rxnav/
# 安装依赖
npm install
# 构建项目
npm run build
# 测试运行
npm start# 全局安装PM2
sudo npm install -g pm2
# 创建PM2配置文件
cat > ecosystem.config.js << 'EOF'
module.exports = {
apps: [{
name: 'mcp-rxnav',
script: 'dist/index.js',
cwd: '/home/ubuntu/mcp-servers/rxnav',
instances: 1,
autorestart: true,
watch: false,
max_memory_restart: '1G',
env: {
NODE_ENV: 'production'
}
}]
}
EOF
# 启动服务
pm2 start ecosystem.config.js
# 设置开机自启
pm2 startup
pm2 save
# 查看状态
pm2 status
pm2 logs mcp-rxnav# 如果需要通过网络访问，可以配置nginx反向代理
sudo apt install nginx
# 创建nginx配置
sudo tee /etc/nginx/sites-available/mcp-rxnav << 'EOF'
server {
listen 80;
server_name your-domain.com; # 替换为你的域名或IP
location / {
proxy_pass http://localhost:3000; # 如果MCP服务器监听3000端口
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
}
}
EOF
# 启用站点
sudo ln -s /etc/nginx/sites-available/mcp-rxnav /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx在客户端机器上创建SSH隧道：
# 创建SSH隧道，将本地端口转发到服务器
ssh -L 3000:localhost:3000 user@your-server-ip
# 然后在MCP客户端配置中使用 localhost:3000如果需要通过网络直接访问，需要修改MCP服务器以支持网络传输：
// 在src/index.ts中添加网络传输支持
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";
// 替换stdio传输为网络传输
const transport = new SSEServerTransport("/message", response);# 创建Dockerfile
cat > Dockerfile << 'EOF'
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist/ ./dist/
COPY src/ ./src/
EXPOSE 3000
CMD ["npm", "start"]
EOF
# 构建和运行
docker build -t mcp-openfda .
docker run -d -p 3000:3000 --name mcp-openfda-server mcp-openfda在Claude Desktop的配置文件中添加：
{
"mcpServers": {
"rxnav": {
"command": "node",
"args": ["/path/to/mcp-rxnav/dist/index.js"],
"env": {}
}
}
}{
"mcpServers": {
"rxnav": {
"command": "ssh",
"args": [
"user@your-server-ip",
"cd ~/mcp-servers/rxnav && node dist/index.js"
],
"env": {}
}
}
}# 构建项目
npm run build
# 运行集成测试
node test/integration.test.js# 运行使用示例
node examples/usage-examples.js// 搜索阿司匹林的信息
const result = await search_drug_by_name({
drug_name: "aspirin",
limit: 5
});
// 返回结果示例:
{
"query": "aspirin",
"drugs": [
{
"rxcui": "1191",
"name": "Aspirin",
"termType": "IN"
},
{
"rxcui": "243670",
"name": "Aspirin 325 MG Oral Tablet",
"termType": "SCD"
}
],
"total_found": 2
}// 获取Advil的通用名
const result = await get_generic_name({
drug_identifier: "Advil"
});
// 返回结果示例:
{
"query": "Advil",
"rxcui": "5640",
"generic_names": [
{
"rxcui": "5640",
"name": "ibuprofen",
"termType": "IN"
}
],
"total_found": 1
}// 查询布洛芬的商品名
const result = await get_brand_names({
generic_name: "ibuprofen"
});
// 返回结果示例:
{
"query": "ibuprofen",
"generic_rxcui": "5640",
"brand_names": [
{
"rxcui": "209387",
"name": "Advil",
"termType": "BN"
},
{
"rxcui": "209459",
"name": "Motrin",
"termType": "BN"
}
],
"total_found": 2
}// 获取阿司匹林的ATC分类
const result = await get_atc_classification({
drug_identifier: "aspirin"
});
// 返回结果示例:
{
"query": "aspirin",
"rxcui": "1191",
"atc_codes": [
{
"code": "N02BA01",
"level": 5,
"name": "Chemical substance"
},
{
"code": "B01AC06",
"level": 5,
"name": "Chemical substance"
}
],
"total_found": 2
}// 查询泰诺的活性成分
const result = await get_drug_ingredients({
drug_identifier: "Tylenol"
});
// 返回结果示例:
{
"query": "Tylenol",
"rxcui": "202433",
"ingredients": [
{
"rxcui": "161",
"name": "acetaminophen",
"termType": "IN"
}
],
"total_found": 1
}RXNAV_DEBUG: 设置为 true 启用详细日志记录
API限制: RxNav API有速率限制，建议合理控制请求频率
数据准确性: 返回的数据仅供参考，不应作为医疗建议
网络安全: 如果部署在公网，请确保适当的安全措施
日志监控: 建议配置日志监控以跟踪API使用情况
错误处理: 服务器包含完整的错误处理和重试机制
连接失败: 检查网络连接和防火墙设置
权限错误: 确保Node.js进程有适当的文件权限
端口冲突: 检查端口是否被其他服务占用
# PM2日志
pm2 logs mcp-openfda
# 系统日志
sudo journalctl -u nginx -fMIT License
Advanced RAG pipeline for drug terminology analysis. Fetches, extracts, chunks, retrieves and summarizes RxNav drug terminology data in one call to prevent LLM response truncation.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | Drug name to focus the analysis on. Example: 'aspirin', 'metformin' | |
| query | No | Natural language query about drug terminology. Example: 'ATC classification and generic names' | |
| top_k | No | Number of most relevant text chunks to return (1-10) | |
| filters | No | Additional filters for data retrieval | |
| condition | No | Medical condition context for drug classification. Example: 'diabetes', 'cardiovascular' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the multi-step nature (fetch→extract→chunk→retrieve→summarize) and the truncation-prevention behavior, but omits whether calls are read-only, latency/cost implications of a chained pipeline, external API dependencies (RxNav), or failure modes. Significant gaps for an unannotated multi-stage tool.
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 sentences, front-loaded with the tool's identity and scope, then the operational rationale. Zero waste and efficiently sized for the tool's complexity.
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?
For a 5-param, nested-schema, no-output-schema, no-annotation pipeline tool, the description covers purpose and motivation but is thin on behavioral details: no return shape, no error handling, no resource/latency expectations. The schema covers parameters, but the behavioral gap leaves an agent with unanswered operational questions.
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 100%, so the schema already documents all five parameters with examples and ranges; baseline would be 3. The description adds pipeline-level context about how parameters feed the fetch/retrieve stages, marginally exceeding the 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?
States a specific verb chain (fetches, extracts, chunks, retrieves, summarizes) and a specific resource (RxNav drug terminology data) with a stated rationale (prevent LLM response truncation). It distinguishes itself from siblings by being a multi-step pipeline rather than a single lookup, though it doesn't explicitly name the siblings it supersedes.
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 comprehensive drug terminology analysis and explains the truncation-avoidance rationale, but offers no explicit when-to-use vs. when-to-call a sibling like search_drug_by_name. No exclusions or routing guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ATC (Anatomical Therapeutic Chemical) classification codes for a given drug name or RxCUI. Returns WHO ATC classification hierarchy information.
| Name | Required | Description | Default |
|---|---|---|---|
| drug_identifier | Yes | Drug name (brand or generic) or RxCUI to get ATC classification for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that the operation is a lookup that returns WHO ATC hierarchy information, which hints at read-only behavior and return content, but it never states that no data is mutated, what happens when a drug name or RxCUI is not found, or whether multiple ATC codes can be returned.
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 short sentences with the action front-loaded and no filler. The second sentence adds some authority context (WHO) but is close to redundant with the first, keeping it just short of a 5.
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?
For a one-parameter lookup with no output schema, the description covers the basic purpose and hints at the return content, but it omits any detail about the shape of the returned hierarchy or failure behavior. Adequate for a simple tool but with clear gaps an agent could hit.
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 100%, and the single parameter is fully documented in the schema as accepting a brand/generic name or RxCUI. The description only restates that same range ('given drug name or RxCUI'), adding no format, ambiguity-resolution, or matching-behavior detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ('Get ATC classification codes') and expands the ATC acronym, so the purpose is unambiguous. It does not differentiate itself from siblings like get_drug_ingredients or get_generic_name, but the operated-on resource (ATC hierarchy) is distinctive enough that misselection is unlikely.
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?
There is no when-to-use guidance, no statement of when an alternative sibling (e.g., get_drug_ingredients, get_generic_name) would be preferable, and no prerequisites or input-quality caveats. The agent must infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get brand names for a given generic drug name. Returns all commercial brand names associated with the generic drug.
| Name | Required | Description | Default |
|---|---|---|---|
| generic_name | Yes | Generic drug name to find brand names for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that all matching brand names are returned, saying nothing about read-only semantics, whether a miss returns empty vs. error, or any rate/auth constraints.
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?
Front-loaded and short, but the second sentence largely restates the first ('Returns all commercial brand names' vs. 'Get brand names'), costing a little redundancy.
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?
For a one-parameter read tool with no output schema, the definition is minimally sufficient but omits the return shape (flat list of strings?) and any failure behavior, leaving an agent guessing about edge cases.
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 100% with a single well-documented parameter, so the schema already does the work. The description mirrors it ('for a given generic drug name') without adding format or normalization 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?
States a specific verb (Get) and resource (brand names) plus the input it operates on (generic drug name). It is distinguishable from get_generic_name, its inverse sibling, though the description never names or contrasts with any sibling.
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?
Usage is implied: call it when you hold a generic name and want its commercial brand names. There is no explicit when-to-use framing, no exclusions, and no routing to alternatives such as search_drug_by_name or get_generic_name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active ingredients for a given drug name or RxCUI. Returns ingredient information including strength and dosage form details.
| Name | Required | Description | Default |
|---|---|---|---|
| drug_identifier | Yes | Drug name (brand or generic) or RxCUI to get ingredients for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose what is returned (ingredient information, strength, dosage form), which is useful context, but it says nothing about behavior on an unknown drug, whether the lookup is case-sensitive, or whether RxCUI and name inputs behave differently. Adequate but thin for a zero-annotation tool.
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 tight sentences: the first front-loads the action and accepted identifier, the second adds the return contents. No filler or redundancy.
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?
For a single-parameter lookup with no output schema, the description covers both the input form and the shape of the result, which is most of what an agent needs. A brief note on no-match behavior would complete it.
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 100%, and the schema already documents drug_identifier as accepting 'Drug name (brand or generic) or RxCUI'. The description restates the same accepted input forms without adding format, casing, or disambiguation rules, so baseline 3 applies.
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?
States a specific verb+resource: 'Get active ingredients for a given drug name or RxCUI', which is clearly distinct from the resources handled by siblings like get_generic_name or get_atc_classification. It never explicitly names a sibling or routing condition, so it stops short of the 5 bar.
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?
Usage is implied — an agent needing ingredient composition would naturally reach for this tool — but the description gives no explicit when/when-not guidance and never references the sibling tools (get_generic_name, get_brand_names) that sound superficially related. No prerequisites or lookup-failure behavior is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the generic name(s) for a given drug name or RxCUI. Converts brand names to their corresponding generic names.
| Name | Required | Description | Default |
|---|---|---|---|
| drug_identifier | Yes | Drug name (brand or generic) or RxCUI to get generic name for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states the conversion but says nothing about whether the lookup hits a cache/database, what happens if the drug is not found, whether multiple generics can be returned, or the return format. This is a substantial gap for an unannotated lookup tool.
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 short sentences with no waste, front-loading the operation. Slightly redundant since the second sentence largely restates the first.
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?
For a lookup tool with no annotations and no output schema, the description should clarify edge cases (unknown identifiers, multiple matches) and return shape. It leaves return behavior entirely undefined, which is a significant shortfall given the absence of structured behavior signals.
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 100% – the drug_identifier parameter is already documented as accepting a drug name (brand or generic) or RxCUI. The description repeats the accepted input types without adding syntax, format, or validation details beyond the schema. Baseline 3 is correct.
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?
States a specific verb and resource: converting a drug name or RxCUI into its generic name(s). The conversion direction is clear. Sibling differentiation is partial – get_brand_names is the inverse operation and is implied but not named.
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 brand-to-generic conversion but gives no explicit when-to-use or when-not-to-use guidance and does not name the alternative tools (get_brand_names, search_drug_by_name) that overlap in scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for drug information by name using RxNav API. Returns RxNorm concept information including RXCUI and related drug details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| drug_name | Yes | Name of the drug to search for. Can be brand name, generic name, or ingredient name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that this is an external API-backed read that returns RxNorm concept information including RXCUI, which is useful beyond structured fields. It omits rate limits, authentication needs, and matching behavior, leaving clear gaps.
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 two tight sentences with no wasted words. It front-loads the action and follows with the return shape, making efficient use of the space.
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?
For a low-complexity, two-parameter search tool with 100% schema coverage and no output schema, the description is nearly complete: it identifies the action, data source, and return fields. It falls short only by not addressing when to prefer this tool over its more specialized siblings.
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 100%, so the schema already documents both drug_name and limit fully. The description adds only that the search is 'by name' and does not elaborate on accepted name forms, the limit parameter, or result ordering. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states a clear verb and resource: 'Search for drug information by name using RxNav API.' It also names the return domain (RxNorm concept information including RXCUI). However, it does not explicitly distinguish itself from the other specific sibling tools like get_generic_name or get_brand_names, so it stops short of a 5.
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?
There is no explicit when-to-use guidance or mention of alternatives. The phrase 'by name' implies the input condition, but the agent receives no direction on when to choose this general search over the more targeted sibling tools. This matches the calibration for descriptions with no routing guidance.
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.1ae_pipeline_ragget_atc_classificationget_brand_namesget_drug_ingredientsget_generic_namesearch_drug_by_nameScored across 6 tools
Five lookup tools target distinct attributes (search, generic, brand, ATC, ingredients) with clear boundaries. The ae_pipeline_rag tool overlaps as a bulk RAG superset of those lookups, but its one-call summarization role is sufficiently differentiated.
Five tools use predictable snake_case verb_noun naming (search_drug_by_name, get_generic_name, get_brand_names, get_atc_classification, get_drug_ingredients). The final tool ae_pipeline_rag breaks the verb_noun pattern and uses a noun/prefix convention, a minor inconsistency.
Six tools is well-scoped for a drug terminology lookup server; each tool covers a distinct facet or workflow without bloat.
Covers name lookup, generic/brand conversion, ATC classification, ingredients, and a bulk RAG pipeline. Minor gaps remain for common RxNav operations like drug-drug interactions or related-concept expansion.
RxNorm MCP — wraps the NLM RxNav REST API (free, no auth)
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
Search and export FDA drug labels by brand name, generic ingredient, or UNII code.
Live US drug acquisition costs (CMS NADAC) for AI assistants. Free, no auth, weekly data.
