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., "@OpenFDA Drug Label MCP Server What are the adverse reactions of ibuprofen?"
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.
一个用于查询 FDA 药物标签信息的 MCP（Model Context Protocol）服务器，专为药物不良反应智能体设计。
无需安装，直接在 Cursor / Cherry Studio 的 MCP 配置中使用：
{
"mcpServers": {
"openfda": {
"command": "npx",
"args": ["-y", "bach-openfda"]
}
}
}保存配置后重启，npx 会自动从 npm 下载并运行最新版本的 bach-openfda。
包地址: https://www.npmjs.com/package/bach-openfda
Related MCP server: OpenFDA FastMCP Server
药物标签搜索: 通过药物名称、活性成分、制造商等搜索 FDA 药物标签
不良反应查询: 获取特定药物的不良反应信息
警告信息: 查询药物的警告和注意事项
适应症信息: 获取药物的适应症和用法信息
搜索 FDA 药物标签，支持复杂查询语法。
参数:
search (string): 搜索查询，如 "aspirin", "openfda.brand_name:tylenol"
count (string): 按字段统计结果
skip (number): 跳过记录数（分页）
limit (number): 返回记录数限制 (1-1000)
获取特定药物的不良反应信息。
参数:
drug_name (string, 必需): 药物名称
limit (number): 返回记录数限制 (1-100)
获取药物的警告和注意事项。
参数:
drug_name (string, 必需): 药物名称
limit (number): 返回记录数限制 (1-100)
获取药物的适应症和用法信息。
参数:
drug_name (string, 必需): 药物名称
limit (number): 返回记录数限制 (1-100)
# 安装依赖
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/openfda
cd ~/mcp-servers/openfda
# 上传项目文件（使用scp或git clone）
# 方法1: 使用git
git clone <your-repo-url> .
# 方法2: 使用scp从本地上传
# scp -r /path/to/mcp-openfda/* user@your-server:~/mcp-servers/openfda/
# 安装依赖
npm install
# 构建项目
npm run build
# 测试运行
npm start# 全局安装PM2
sudo npm install -g pm2
# 创建PM2配置文件
cat > ecosystem.config.js << 'EOF'
module.exports = {
apps: [{
name: 'mcp-openfda',
script: 'dist/index.js',
cwd: '/home/ubuntu/mcp-servers/openfda',
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-openfda# 如果需要通过网络访问，可以配置nginx反向代理
sudo apt install nginx
# 创建nginx配置
sudo tee /etc/nginx/sites-available/mcp-openfda << '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-openfda /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": {
"openfda": {
"command": "node",
"args": ["/path/to/mcp-openfda/dist/index.js"],
"env": {}
}
}
}{
"mcpServers": {
"openfda": {
"command": "ssh",
"args": [
"user@your-server-ip",
"cd ~/mcp-servers/openfda && node dist/index.js"
],
"env": {}
}
}
}// 搜索阿司匹林的信息
await searchDrugLabels({
search: "aspirin",
limit: 5,
});
// 获取布洛芬的不良反应
await getDrugAdverseReactions("ibuprofen", 3);
// 查询泰诺的警告信息
await getDrugWarnings("tylenol", 2);API 限制: OpenFDA API 有速率限制，建议合理控制请求频率
数据准确性: 返回的数据仅供参考，不应作为医疗建议
网络安全: 如果部署在公网，请确保适当的安全措施
日志监控: 建议配置日志监控以跟踪 API 使用情况
连接失败: 检查网络连接和防火墙设置
权限错误: 确保 Node.js 进程有适当的文件权限
端口冲突: 检查端口是否被其他服务占用
# PM2日志
pm2 logs mcp-openfda
# 系统日志
sudo journalctl -u nginx -fMIT License
Advanced RAG pipeline for drug safety analysis. Fetches, extracts, chunks, retrieves and summarizes FDA drug label data in one call to prevent LLM response truncation.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | Drug name to focus the analysis on. Example: 'aspirin', 'ibuprofen' | |
| query | No | Natural language query about drug safety. Example: 'cardiovascular side effects and warnings' | |
| 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. Example: 'hypertension', 'pain management' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the multi-step behavioral nature (fetch, extract, chunk, retrieve, summarize) and the intent to avoid truncation, but omits details like output format, potential external API calls, latency, or side effects. This is moderate disclosure, not rich enough for a 4 but above a 2.
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 concise, with two front-loaded sentences. The first states the core purpose, and the second elaborates with a clear list of actions and a rationale. Every clause adds value, with no fluff. It is an efficient, well-structured description.
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 tool's complexity (multi-step RAG, 5 parameters, no output schema), the description is incomplete. It does not specify the return format (summary vs. chunks vs. both), nor does it explain how the pipeline uses each parameter. An agent needs more detail to safely invoke and interpret results. The 'prevent truncation' note is helpful but insufficient.
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 baseline is 3. The description does not add any parameter-specific meaning beyond the schema. It does not explain how parameters like 'drug', 'query', or 'filters' interact, so it neither enhances nor detracts from the schema's clarity. A 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 it is an 'Advanced RAG pipeline for drug safety analysis' that 'fetches, extracts, chunks, retrieves and summarizes FDA drug label data'. This specific verb list distinguishes it from the more focused sibling tools (e.g., get_drug_warnings) by promising an end-to-end analysis in one call, making its unique purpose unambiguous.
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 when to use this tool: when a comprehensive, non-truncated analysis is needed ('in one call to prevent LLM response truncation'). It gives clear context for use but does not explicitly mention alternatives or exclusions, such as when to prefer a simpler sibling like get_drug_adverse_reactions. Thus it meets the 'clear context, no exclusions' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get adverse reactions information for a specific drug from FDA labels
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records to return | |
| drug_name | Yes | Name of the drug to search for adverse reactions |
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 only restates the tool's function and source without detailing potential multiple records, matching behavior, pagination limits (beyond the schema), or any restrictions. This leaves the agent with insufficient information about how the tool actually behaves.
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, concise sentence that front-loads the action and resource. Every word earns its place, with no superfluous information or repetition of the tool name.
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 no annotations and no output schema, the description should clarify the response format or behavioral nuances. It only says 'adverse reactions information' without specifying whether the response is a list, a structured object, or raw text, leaving the agent without adequate expectations.
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 schema already provides complete descriptions for both parameters (100% coverage), so the description adds no additional meaning. It does not explain how drug_name is matched or what limit controls in terms of output, which is acceptable given the schema's thoroughness.
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 ('Get'), the resource ('adverse reactions information'), and the specific scope ('for a specific drug from FDA labels'). This effectively distinguishes it from sibling tools like get_drug_warnings and get_drug_indications, which target different aspects of drug labels.
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 when to use the tool (when you need adverse reactions for a drug) but provides no explicit guidance on when not to use it or how it compares to alternatives like search_drug_labels or get_drug_warnings. The intended use is clear from the context, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get indications and usage information for a specific drug from FDA labels
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records to return | |
| drug_name | Yes | Name of the drug to search for indications |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the high-level purpose and does not disclose that the tool can return multiple records (as suggested by the 'limit' parameter), the structure of the response, or any error behavior. The 'from FDA labels' detail adds source context but no operational transparency.
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 communicates the core purpose without any extraneous wording. It is concise and well-structured, making it easy for an agent to quickly grasp the tool's function.
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 the tool's apparent simplicity, the absence of an output schema and annotations places a higher burden on the description. The description does not explain that the tool returns potentially multiple records (the 'limit' parameter implies this), nor does it describe the return format or any limitations. This leaves gaps for an agent trying to predict the tool's behavior.
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 both 'drug_name' and 'limit' already described in the schema. The tool description adds no additional parameter meaning beyond what the schema provides, so the baseline score of 3 applies. There is no missing parameter information that the description needs to compensate for.
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's function: 'Get indications and usage information for a specific drug from FDA labels.' The verb 'Get' is specific, the resource ('indications and usage information for a specific drug') is well-defined, and the source ('FDA labels') adds context. The tool is easily distinguishable from siblings like get_drug_adverse_reactions and get_drug_warnings, which target different data categories.
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 the tool is used when seeking indications/usage for a specific drug, but it does not explicitly state when to use this tool versus alternatives like search_drug_labels or ae_pipeline_rag. No exclusions or alternative recommendations are provided, leaving the usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get warnings and precautions for a specific drug from FDA labels
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records to return | |
| drug_name | Yes | Name of the drug to search for warnings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Get', which implies a read operation, but does not mention pagination, return limits, or potential side effects. This leaves the agent without essential behavioral context.
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 concise sentence that communicates the core purpose without unnecessary words, making it highly efficient and front-loaded.
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?
The description states the core function but does not explain the return structure or how 'limit' affects results. Since there is no output schema, the agent may be under-informed about response format, making it minimally sufficient but not 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?
The description adds no information about parameters beyond the schema, which already documents both 'drug_name' and 'limit' with 100% coverage. The schema handles parameter semantics, 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?
The description clearly states the verb 'Get' and the specific resource 'warnings and precautions' for a specific drug from FDA labels, which distinguishes it from sibling tools like get_drug_adverse_reactions and get_drug_indications.
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 the use case for a specific drug, but does not explicitly compare with alternative tools or provide exclusion criteria. It gives clear context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA drug labels using OpenFDA API. Returns drug labeling information including indications, contraindications, warnings, and adverse reactions.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of records to skip (for pagination) | |
| count | No | Field to count results by. Example: 'openfda.manufacturer_name.exact' | |
| limit | No | Maximum number of records to return (1-1000) | |
| search | No | Search query. Can search by drug name, active ingredient, manufacturer, etc. Example: 'aspirin', 'ibuprofen', 'openfda.brand_name:tylenol' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does state that the tool searches and returns labeling information including specific sections, which makes it clear this is a read-only operation and hints at output content. However, it omits details about result format, pagination/limit behavior, API constraints, or rate limits.
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 sentences, with the action and purpose front-loaded ('Search FDA drug labels using OpenFDA API') and the return content summarized immediately. Every sentence earns its place with 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?
The tool has four optional parameters, all fully described in the schema, and the description states the output content, which makes it minimally viable. However, with no output schema and no annotations, the description could have been more complete by explaining pagination/limit interplay, clarifying the response structure, or distinguishing this from sibling tools.
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 already documents all four parameters with descriptions, defaults, and examples (100% schema description coverage), including clear examples for 'search' and 'count'. The tool description itself adds no additional parameter semantics beyond indicating the general search capability, so the 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 tool's action ('Search FDA drug labels using OpenFDA API') and lists the categories of returned information (indications, contraindications, warnings, adverse reactions). However, it does not explicitly differentiate this general label search from sibling tools like get_drug_warnings or get_drug_indications, which cover similar content.
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 is provided on when to use this tool versus alternatives. Sibling tools such as get_drug_warnings, get_drug_indications, and get_drug_adverse_reactions exist but are not referenced, and there are no exclusion criteria or preferred contexts described.
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. Dates show when Glama detected each change.
v1.0.1ae_pipeline_ragget_drug_adverse_reactionsget_drug_indicationsget_drug_warningssearch_drug_labelsThe three specific getters (adverse reactions, warnings, indications) are clearly distinct, but search_drug_labels and ae_pipeline_rag both fetch broad drug label data, creating some overlap. The descriptions help distinguish them (general search vs. advanced safety pipeline), but the boundary is not entirely sharp.
Most tools follow a consistent verb_noun pattern (search_drug_labels, get_drug_adverse_reactions, get_drug_warnings, get_drug_indications). The outlier is ae_pipeline_rag, which uses an acronym and lacks a verb, making it a minor deviation from the otherwise predictable naming convention.
With 5 tools, the server is well-scoped for its purpose of querying FDA drug labels. Each tool covers a meaningful aspect (general search, specific sections, and a comprehensive pipeline) without excessive redundancy or missing core functionality.
The tool set covers the primary drug safety sections (adverse reactions, warnings, indications) and provides a full search capability. Minor gaps exist (e.g., no explicit contraindications or dosage getter), but agents can retrieve these via search_drug_labels or ae_pipeline_rag, so the surface is not severely incomplete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and export FDA drug labels by brand name, generic ingredient, or UNII code.
Search FDA safety data: drug adverse events, recalls, and device events.
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
Scrape openFDA drug recalls, enforcement reports, labels and adverse events. Pay per row.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/mcp-openfda'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
