A
license-
qualityC
maintenanceEnables querying FDA medical device regulatory databases including 510(k) clearances, PMA approvals, recalls, and adverse events through natural language.
Last updated
MIT
enforcement-database
by ai.argushq
Server Details
Search Argus HQ public FDA enforcement data: warning letters, recalls, approvals, 483s.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A3.8/5.0
Tool DescriptionsA
Average 3.6/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation4/5
Tools are generally distinct, but get_company_history and search_enforcement both return warning letters and recalls, which could cause confusion if an agent needs a single record type. However, the entry points (company slug vs. keyword search) reduce ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., get_company_history, list_recent_actions), using underscores and descriptive verbs like get, list, and search.
Tool Count5/5
5 tools is well-scoped for a domain specializing in FDA enforcement data; each tool covers a clear use case without redundancy.
Completeness3/5
The set covers company history, recall by lot, warning letter lookup, recent list, and search, but lacks dedicated tools for direct recall by recall number or specific approval lookups, leaving minor gaps.
Available Tools
5 toolsget_company_historyGet a company's full FDA enforcement historyAInspect
Every FDA warning letter, recall, approval, and 483 citation Argus HQ has recorded for a given company, by its Argus HQ company slug (e.g. "pfizer-inc").
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Argus HQ company slug, e.g. "pfizer-inc" |
Tool Definition Quality
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, authentication, rate limits, data freshness). For a tool returning potentially large histories, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff. Efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain the return format (e.g., list of objects, pagination). For a tool that returns multiple record types, this is insufficient for an agent to parse results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the sole parameter with a description. The description simply restates the slug example, adding no extra meaning. Baseline score is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the full FDA enforcement history (warning letters, recalls, approvals, 483s) for a company using a unique slug. Differentiates from sibling tools that are more specific (e.g., get_recall_by_lot) or broader search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies the tool is for getting the complete history for a specific company. It does not explicitly compare with alternatives, but the context of sibling tools makes it clear. Could be improved by stating when not to use (e.g., for single documents).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recall_by_lotLook up a recall by lot numberAInspect
Finds every FDA recall record that references a specific product lot number.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lot_number | Yes | The lot number printed on the product/packaging |
Tool Definition Quality
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states it finds 'every' record referencing the lot number, but omits details like output format, pagination, rate limits, or behavior when no records exist. The description is clear but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word is necessary and there is no redundancy. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no output schema, and no annotations, the description is minimal. It covers the basic purpose but lacks details on output behavior, error handling, or limitations. For a simple lookup, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema's parameter description ('The lot number printed on the product/packaging'). No additional context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Finds', the resource 'every FDA recall record', and the specific criterion 'references a specific product lot number'. It distinguishes this tool from siblings like get_company_history or search_enforcement by focusing on lot number lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a lot number is known but gives no explicit guidance on when not to use this tool or mention alternatives like get_company_history. Without exclusions or context, the agent must infer the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_warning_letterLook up an FDA warning letter by reference numberAInspect
Direct lookup of an FDA warning letter. Accepts either the FDA reference number printed in the letter itself (e.g. "320-26-65") or the fda.gov URL slug ID for the letter.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wl_number | Yes | FDA warning letter reference number (e.g. "320-26-65") or fda.gov URL slug ID |
Tool Definition Quality
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions accepted input formats but does not disclose whether it is read-only, authentication needs, rate limits, or what the return format looks like. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose, the second adds input details. Concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description sufficiently explains the input format. It could mention that the result is the full warning letter content, but given the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains the parameter. The description adds a concrete example ('320-26-65') and clarifies 'printed in the letter itself', which provides mild additional context but does not substantially improve understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Direct lookup of an FDA warning letter' and specifies the two accepted input formats (reference number or URL slug ID). This distinguishes it from sibling tools like search_enforcement (search) or get_company_history (history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific identifier, but does not explicitly state when not to use it or mention alternatives among sibling tools. Usage context is only implied by contrast with sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_actionsList recent FDA enforcement actionsAInspect
The most recent published FDA warning letters, recalls, approvals, and 483 citations across all streams.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many trailing days to include (default 7) |
Tool Definition Quality
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It says 'most recent' and 'across all streams' but omits ordering, pagination, result limits, or return format. It does not indicate whether the tool is readonly or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema, the description is adequate for purpose but lacks behavioral details (e.g., return structure, limit on results). The sibling list provides context, but the description could be more complete regarding result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the one parameter ('days') with a clear explanation. The tool description does not add further meaning to the parameter beyond 'across all streams', which is already implied. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool lists recent FDA enforcement actions including warning letters, recalls, approvals, and 483 citations. It uses a specific verb ('list') and resource ('recent FDA enforcement actions'), and the broad scope distinguishes it from siblings like get_warning_letter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting a broad recent overview, but it does not explicitly state when to use this tool versus the siblings (e.g., get_company_history for a specific company). 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.
search_enforcementSearch FDA enforcement recordsAInspect
Full-text search across all 1,000+ Argus HQ FDA enforcement pages (warning letters, recalls, approvals, 483 inspections) by keyword, product name, or company name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text -- company name, product, or keyword |
Tool Definition Quality
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions search across 1,000+ pages but lacks disclosure on pagination, rate limits, result format, or limitations such as maximum results. Does not convey behavioral traits beyond core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core action and resource, no redundant information. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, description is reasonable but missing details on result handling (e.g., pagination, count limits). Adequate but not fully complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter 'query' with description. Description adds value by clarifying usage for 'keyword, product name, or company name', enriching the semantic understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'search' and resource 'FDA enforcement pages' with specific categories (warning letters, recalls, approvals, 483 inspections). Distinguishes from sibling tools which target specific record types (e.g., get_warning_letter) by offering general full-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for broad keyword search but does not explicitly state when to use versus dedicated siblings. No guidance on scenarios where specific tools like get_recall_by_lot are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Flicense-qualityDmaintenanceEnables searching FDA food recalls and adverse event reports through natural language, supporting filters and pagination.Last updated
- Alicense-qualityAmaintenanceQuery FDA data on drugs, food, devices, and recalls via openFDA. Provides 12 tools for searching adverse events, drug labels, recalls, and more.Last updated9734Apache 2.0
- Flicense-qualityDmaintenanceEnables AI agents to query and analyze FDA adverse events, drug labels, medical device clearances, and other public health datasets through natural language commands.Last updated13