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 MCP Server Search for adverse events related to aspirin"
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.
A comprehensive Model Context Protocol (MCP) server that provides access to the U.S. Food and Drug Administration's public datasets through the openFDA API. This server enables querying of drug adverse events, product labeling, recalls, approvals, shortages, NDC directory information, and medical device regulatory data including 510(k) clearances, classifications, and adverse events.
Developed by Augmented Nature
search_drug_adverse_events: Search FDA Adverse Event Reporting System (FAERS) data
search_drug_labels: Search drug product labeling information
search_drug_ndc: Query the National Drug Code (NDC) directory
search_drug_recalls: Find drug recall enforcement reports
search_drugs_fda: Search the Drugs@FDA database for approved products
search_drug_shortages: Query current drug shortages
search_device_510k: Search FDA 510(k) device clearances
search_device_classifications: Search FDA device classifications
search_device_adverse_events: Search FDA device adverse events (MDR)
search_device_recalls: Search FDA device recall enforcement reports
Comprehensive Search: Advanced filtering by drug name, manufacturer, indication, dates, and more
Rate Limiting: Built-in awareness of FDA API rate limits (1,000 requests/hour without API key)
Error Handling: Robust error handling with meaningful error messages
Formatted Results: Clean, structured JSON responses with relevant metadata
Optional API Key: Supports FDA API key for higher rate limits (120,000 requests/hour)
Related MCP server: OpenFDA MCP Server
The server is already built and configured in your MCP settings
Optionally set an FDA API key for higher rate limits:
# Set FDA_API_KEY environment variable for higher rate limits
export FDA_API_KEY="your_api_key_here"To get an FDA API key:
Sign up for an API key
Add it to your MCP settings or environment
Search for adverse events related to aspirin that occurred in the United States in 2023Find labeling information for diabetes medications manufactured by Novo NordiskLook up NDC information for ibuprofen tabletsFind all Class I drug recalls from 2023 involving contaminationFind all FDA-approved drugs sponsored by Pfizer with injection dosage formFind current drug shortages for antibioticsAll tools return structured JSON with:
search_criteria: The parameters used for the search
total_results: Total number of matching records in FDA database
results_shown: Number of results returned in this response
[data_type]: Array of formatted results (e.g., adverse_events, drug_labels)
api_usage: Information about API key status and rate limits
Without API Key: 1,000 requests per hour
With API Key: 120,000 requests per hour
The server automatically handles rate limit errors and provides helpful messages
The server is built with a modular architecture:
/src/index.ts: Main server setup and tool registration
/src/handlers/drug-handlers.ts: All drug-related tool implementations
/src/handlers/device-handlers.ts: All device-related tool implementations
/src/utils/api-client.ts: HTTP client with error handling and rate limiting
/src/types/fda.ts: TypeScript interfaces for all FDA data structures
drug_name: Name of the drug or medication
brand_name: Brand/trade name
generic_name: Generic name
manufacturer: Manufacturer name
reaction: Adverse reaction or side effect
serious_only: Only return serious adverse events
patient_sex: Patient sex (1=Male, 2=Female)
country: Country where event occurred
date_from/date_to: Date range filters
count: Group results for counting
limit: Maximum results (1-100)
skip: Pagination offset
brand_name: Brand/trade name of the drug
generic_name: Generic name
manufacturer: Manufacturer name
active_ingredient: Active ingredient name
indication: Medical indication or condition
route: Route of administration
product_type: Product type
Plus standard pagination and counting parameters
product_ndc: Product NDC number
package_ndc: Package NDC number
proprietary_name: Brand name
nonproprietary_name: Generic name
labeler_name: Manufacturer/labeler name
dosage_form: Dosage form (tablet, capsule, etc.)
route: Route of administration
substance_name: Active substance name
Plus standard pagination and counting parameters
product_description: Product description
recalling_firm: Name of recalling firm
classification: Recall classification (Class I, II, III)
status: Recall status
state/country: Geographic filters
reason_for_recall: Reason for recall
date_from/date_to: Date range filters
Plus standard pagination and counting parameters
sponsor_name: Sponsor/applicant name
application_number: FDA application number
brand_name: Brand/trade name
generic_name: Generic name
active_ingredient: Active ingredient
dosage_form: Dosage form
marketing_status: Marketing status
Plus standard pagination and counting parameters
product_name: Product name
generic_name: Generic name
brand_name: Brand name
active_ingredient: Active ingredient
shortage_status: Current shortage status
shortage_designation: Shortage designation (Yes/No)
dosage_form: Dosage form
Plus standard pagination and counting parameters
device_name: Name of the medical device
applicant: Applicant company name
contact: Contact information
product_code: FDA product code
clearance_type: Type of 510(k) clearance
decision_date_from/decision_date_to: Decision date range filters
Plus standard pagination parameters
device_name: Name of the medical device
device_class: Device class (1, 2, 3)
medical_specialty: Medical specialty
product_code: FDA product code
regulation_number: FDA regulation number
Plus standard pagination parameters
device_name: Name of the medical device
brand_name: Brand name of the device
manufacturer: Device manufacturer name
product_code: FDA product code
event_type: Type of adverse event
patient_sex: Patient sex (F=Female, M=Male)
date_from/date_to: Event date range filters
Plus standard pagination parameters
product_description: Product description or name
recalling_firm: Name of the recalling firm
classification: Recall classification (Class I, II, III)
status: Recall status
product_code: FDA product code
date_from/date_to: Recall initiation date range filters
Plus standard pagination parameters
The server architecture supports easy extension with additional FDA endpoints:
Device Tools: 510(k) clearances, classifications, adverse events, recalls
Food Tools: Adverse events, recall enforcement reports
Other Tools: Substance data, UNII, tobacco reports, historical documents
The server provides comprehensive error handling for:
Invalid search parameters
API rate limiting
Network connectivity issues
FDA API service unavailability
Malformed responses
Built with:
TypeScript: Type-safe development
MCP SDK: Model Context Protocol implementation
Axios: HTTP client with interceptors
Node.js: Runtime environment
This project is open source and available under standard licensing terms.
For issues or questions about the FDA API MCP Server:
Check the FDA API documentation: https://open.fda.gov/apis/
Review rate limiting and authentication requirements
Ensure proper JSON formatting in search parameters
This MCP server provides access to public FDA datasets. Always consult healthcare professionals for medical decisions and drug information.
Search FDA 510(k) device clearances
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | No | Name of the medical device | |
| applicant | No | Applicant company name | |
| contact | No | Contact information | |
| product_code | No | FDA product code | |
| clearance_type | No | Type of 510(k) clearance | |
| decision_date_from | No | Start date for decision date range (YYYYMMDD format) | |
| decision_date_to | No | End date for decision date range (YYYYMMDD format) | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'Search'. It does not disclose any behavioral traits such as authentication needs, rate limits, response format, or pagination behavior, leaving the agent underinformed.
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 with no wasted words. It is appropriately sized for a simple search tool, though it could be front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description is too minimal. It does not explain what a 510(k) clearance is, how to best use the filters, or what the results look like, leaving gaps in understanding.
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 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions, so no additional value.
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 'Search' and the resource 'FDA 510(k) device clearances', which is specific and distinguishes it from sibling tools like search_device_adverse_events or search_device_recalls.
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 alternatives, no context on prerequisites or typical use cases. The description lacks any when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA device adverse events (MDR)
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | No | Name of the medical device | |
| brand_name | No | Brand name of the device | |
| manufacturer | No | Device manufacturer name | |
| product_code | No | FDA product code | |
| event_type | No | Type of adverse event | |
| patient_sex | No | Patient sex (F=Female, M=Male) | |
| date_from | No | Start date for event date range (YYYYMMDD format) | |
| date_to | No | End date for event date range (YYYYMMDD format) | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It only says 'Search', implying a read operation, but doesn't disclose any API quirks, rate limits, required fields (all optional), or pagination behavior. The behavior with no parameters is unclear.
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. However, conciseness comes at the cost of providing necessary details. It earns a 4 for being clearly structured but not 5 due to missing 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 10 parameters and no output schema, the description is insufficient. It does not explain terms like MDR, how to effectively use filters, or what the output contains. The sibling tools provide context but the description itself is incomplete.
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 parameters. The description adds no extra meaning beyond what's in the schema, thus baseline 3.
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 'Search FDA device adverse events (MDR)', indicating the verb and resource. It distinguishes from sibling tools like search_device_510k, but lacks specificity on the scope of MDR data.
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, such as when to search adverse events vs. recalls or classifications. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA device classifications
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | No | Name of the medical device | |
| device_class | No | Device class (I, II, III) | |
| medical_specialty | No | Medical specialty | |
| product_code | No | FDA product code | |
| regulation_number | No | FDA regulation number | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
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 does not state whether the operation is read-only, destructive, or requires authentication. Although a search is typically read-only, this is not explicitly communicated.
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 extremely concise (four words), but it is front-loaded and conveys the core purpose. However, it may be too brief at the expense of helpful details.
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 has 7 parameters and no output schema, the description is insufficient. It fails to explain what 'device classifications' are, how the results look, or how to effectively use the parameters like limit/skip for pagination.
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 has 100% description coverage, so the baseline is 3. The description 'Search FDA device classifications' does not add any extra meaning or usage context to the parameters beyond what the schema already provides.
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 'Search FDA device classifications' clearly states the tool's action and resource, but it does not differentiate it from sibling tools like search_device_510k or search_device_recalls, which also search FDA device-related data.
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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives, nor are there any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA device recall enforcement reports
| Name | Required | Description | Default |
|---|---|---|---|
| product_description | No | Product description or name | |
| recalling_firm | No | Name of the recalling firm | |
| classification | No | Recall classification (Class I, Class II, Class III) | |
| status | No | Recall status | |
| product_code | No | FDA product code | |
| date_from | No | Start date for recall initiation (YYYYMMDD format) | |
| date_to | No | End date for recall initiation (YYYYMMDD format) | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the tool searches reports but doesn't mention if it is read-only, pagination behavior, or what happens on errors. Schema hints at filtering but description lacks 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 sentence, which is too minimal for a 9-parameter tool. It lacks structure and does not earn its place by providing useful context beyond 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?
Despite 9 parameters and no output schema, the description is only one line. It does not explain return values, result structure, or how to combine filters. The description is insufficient for the tool's complexity.
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 description does not need to add parameter details. The description adds no additional meaning beyond the schema, so a 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 is for searching FDA device recall enforcement reports. It uses a specific verb ('Search') and resource, and the name differentiates it from siblings like search_device_510k or search_device_adverse_events, though no explicit comparison is made.
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 (e.g., search_device_adverse_events). There is no context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA drug adverse event reports (FAERS)
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | No | Name of the drug or medication | |
| brand_name | No | Brand/trade name of the drug | |
| generic_name | No | Generic name of the drug | |
| manufacturer | No | Manufacturer name | |
| reaction | No | Adverse reaction or side effect | |
| serious_only | No | Only return serious adverse events | |
| patient_sex | No | Patient sex (1=Male, 2=Female) | |
| country | No | Country where event occurred | |
| date_from | No | Start date for date range (YYYYMMDD format) | |
| date_to | No | End date for date range (YYYYMMDD format) | |
| count | No | Field to group results by for counting (e.g., "patient.drug.openfda.brand_name.exact") | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. However, it only states the basic purpose with no details on pagination, rate limits, query behavior, or response format. This is insufficient for an agent to understand the tool's behavior.
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.
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 (13 parameters, no annotations, no output schema), the description is severely lacking. It does not explain how to effectively search, interpret results, or handle pagination. The agent would be left without critical usage information.
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?
All 13 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds no parameter-level context beyond the schema, so it remains at 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?
The description clearly states the tool's function: 'Search FDA drug adverse event reports (FAERS)'. It uses a specific verb ('Search') and identifies the resource (FDA drug adverse event reports) and database (FAERS), distinguishing it from sibling tools like search_drug_labels or search_drug_recalls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or how it relates to sibling tools. The context of sibling tools suggests differentiation by report type, but the description itself is silent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA drug product labeling information
| Name | Required | Description | Default |
|---|---|---|---|
| brand_name | No | Brand/trade name of the drug | |
| generic_name | No | Generic name of the drug | |
| manufacturer | No | Manufacturer name | |
| active_ingredient | No | Active ingredient name | |
| indication | No | Medical indication or condition | |
| route | No | Route of administration (e.g., ORAL, TOPICAL) | |
| product_type | No | Product type (e.g., HUMAN PRESCRIPTION DRUG) | |
| count | No | Field to group results by for counting | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits (e.g., read-only vs. mutating, authentication, rate limits, response format). The agent has no insight into tool effects.
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, which is concise but lacks necessary detail for an agent to use effectively. It is not structured to highlight key aspects.
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 10 parameters and no output schema or annotations, the description is extremely sparse. It does not explain what 'labeling information' includes, how search results are returned, or any pagination 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?
While schema description coverage is 100%, the description adds no additional meaning beyond parameter names and types. Baseline 3 is lowered because the description does not enhance understanding of how parameters interact or are used in search.
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 searches FDA drug product labeling information. However, it does not differentiate from sibling tools like search_drugs_fda, which may also return labeling-related data.
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 alternatives such as search_drug_adverse_events or search_drug_recalls. The agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search National Drug Code (NDC) directory
| Name | Required | Description | Default |
|---|---|---|---|
| product_ndc | No | Product NDC number | |
| package_ndc | No | Package NDC number | |
| proprietary_name | No | Proprietary/brand name | |
| nonproprietary_name | No | Nonproprietary/generic name | |
| labeler_name | No | Labeler/manufacturer name | |
| dosage_form | No | Dosage form (e.g., TABLET, CAPSULE, INJECTION) | |
| route | No | Route of administration | |
| substance_name | No | Active substance name | |
| count | No | Field to group results by for counting | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description does not disclose behavioral traits such as whether partial matches are allowed, default pagination, or result structure. The description carries the full burden and fails to provide sufficient detail.
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, concise and front-loaded. It contains no unnecessary words, but may be too brief for a tool with many parameters.
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 11 parameters and no output schema, the description is insufficient. It does not explain how parameters interact, required fields, or the meaning of 'count' and pagination fields.
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?
All 11 parameters have descriptions in the input schema (100% coverage), so the description adds no additional semantic meaning. The schema already explains the parameters adequately.
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 searches the National Drug Code (NDC) directory, distinguishing it from sibling tools focused on devices or other drug-related searches. However, it does not specify the exact type of information returned.
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 like search_drugs_fda or search_drug_labels. The description lacks context for selecting this tool over related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search drug recall enforcement reports
| Name | Required | Description | Default |
|---|---|---|---|
| product_description | No | Product description or name | |
| recalling_firm | No | Name of the recalling firm | |
| classification | No | Recall classification (Class I, Class II, Class III) | |
| status | No | Recall status | |
| state | No | State where recall occurred | |
| country | No | Country where recall occurred | |
| reason_for_recall | No | Reason for the recall | |
| date_from | No | Start date for recall initiation (YYYYMMDD format) | |
| date_to | No | End date for recall initiation (YYYYMMDD format) | |
| count | No | Field to group results by for counting | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Search,' which implies a read operation. It does not disclose any behavioral traits such as pagination, data freshness, rate limits, or whether the results are sorted or filtered.
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, but given the tool has 12 parameters and no output schema, it could benefit from more context. It is adequately sized but not optimally informative.
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 12 parameters, no output schema, and no annotations, the description lacks completeness. It doesn't explain the response format, how parameters combine (e.g., AND vs OR logic), or any limitations.
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 100%, so all parameters have descriptions in the input schema. The description adds no additional meaning beyond what is already in the schema, meeting the baseline expectation.
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 'Search' and the resource 'drug recall enforcement reports'. It differentiates from sibling tools like search_device_recalls by specifying drug recalls, though it doesn't explicitly mention alternatives.
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 its siblings. The description does not mention when to use it (e.g., to find recall enforcement data) or when not to use it (e.g., for device recalls).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Drugs@FDA database for approved drug products
| Name | Required | Description | Default |
|---|---|---|---|
| sponsor_name | No | Sponsor/applicant name | |
| application_number | No | FDA application number (NDA, ANDA, BLA) | |
| brand_name | No | Brand/trade name of the drug | |
| generic_name | No | Generic name of the drug | |
| active_ingredient | No | Active ingredient name | |
| dosage_form | No | Dosage form | |
| marketing_status | No | Marketing status | |
| count | No | Field to group results by for counting | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'search,' omitting details on pagination, result format, error handling, or any constraints. The bare minimum is not met.
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, which is concise but overly minimal. It lacks structure or front-loading of key information beyond the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, all optional, and no output schema, the description is too sparse. It doesn't explain how to effectively use the search or what results to expect, leaving the agent under-informed.
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 adds no additional meaning beyond the schema's parameter descriptions, but it doesn't need to since the schema is self-explanatory.
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 searches the Drugs@FDA database for approved drug products. It uses a specific verb and resource, and while it doesn't explicitly differentiate from sibling tools like search_drug_labels, the name and scope are sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_drug_adverse_events or search_drug_labels. The description lacks any context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current drug shortages reported to FDA
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | No | Product name | |
| generic_name | No | Generic name | |
| brand_name | No | Brand name | |
| active_ingredient | No | Active ingredient name | |
| shortage_status | No | Current shortage status | |
| shortage_designation | No | Shortage designation | |
| dosage_form | No | Dosage form | |
| count | No | Field to group results by for counting | |
| limit | No | Maximum number of results to return (1-100) | |
| skip | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'search current drug shortages.' It omits pagination behavior, grouping via 'count' parameter, or output format.
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, front-loaded with key information. It could be slightly more structured (e.g., bullet-like) but is 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?
For a tool with 10 parameters, no output schema, and multiple siblings, the description lacks details on return values, grouping, and differentiation from other drug search 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?
Schema description coverage is 100%, so the tool description adds no extra meaning to parameters. The baseline of 3 applies as no additional semantics are provided.
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 'Search current drug shortages reported to FDA,' using a specific verb and resource. This distinguishes it from sibling tools like search_drug_recalls or search_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?
No guidance on when to use this tool vs. alternatives is provided. There is no mention of prerequisites, exclusions, or context for selection.
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.
v0.1.0search_device_510ksearch_device_adverse_eventssearch_device_classificationssearch_device_recallssearch_drug_adverse_eventssearch_drug_labelssearch_drug_ndcsearch_drug_recallssearch_drug_shortagessearch_drugs_fdaEach tool targets a distinct FDA dataset (e.g., 510k clearances, drug labels) with no overlap in resource type or dataset, ensuring clear differentiation.
All tools follow a uniform 'search_' prefix followed by a descriptive noun phrase (e.g., search_device_adverse_events), providing a predictable pattern.
10 tools is well-scoped for a public FDA data server, covering major device and drug datasets without being excessive or insufficient.
The set covers key FDA data categories for devices (clearances, adverse events, classifications, recalls) and drugs (adverse events, labels, NDC, recalls, approvals, shortages), with no obvious gaps for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OpenFDA MCP — wraps the openFDA API (free, no auth required)
FDA MCP — US Food and Drug Administration public API (free, no auth)
Hosted MCP server for finding authoritative primary data sources and official portals.
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Augmented-Nature/OpenFDA-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
