Skip to main content
Glama

openfda-mcp-server

by io.github.cyanheads

Openfda Drug Profile

openfda_drug_profile
Read-only

Resolve one drug name to its FDA identity, then fan out in parallel across the bounded per-drug openFDA endpoints and merge into one profile: identity, label highlights, adverse-event summary, recall history, Drugs@FDA approval, and shortage status. Replaces chaining openfda_get_drug_label, openfda_search_adverse_events, openfda_search_recalls, openfda_search_drug_approvals, and openfda_search_drug_shortages — and reconciles the identifier drift between endpoints that makes that chaining error-prone. Each section is best-effort: a miss returns null rather than failing the call. For deep dives into any one area, use the dedicated tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
drugYesDrug name to profile — brand or generic (e.g. "metformin", "Humira", "Glucophage"). Resolved once to canonical FDA identifiers, which then key every sub-query.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNoRequest metadata.
errorNoPresent when the call failed. Absent on success.
labelNoLabel highlights from drug/label, or null when no label matched.
noticeNoGuidance when the drug could not be resolved or upstream errors degraded the profile. Absent on a fully populated profile.
recallsNoRecent drug/enforcement recall actions (may be empty).
approvalNoDrugs@FDA approval summary, or null when no application matched.
degradedNoSub-queries that failed upstream, empty when every section resolved. A section listed here is unknown, not absent — a null section with no entry here genuinely has no FDA record.
identityNoIdentity resolved once and reused across every sub-query to avoid identifier drift.
shortageNoCurrent or most-recent drug shortage status, or null when none on record.
sectionsFoundNoHow many profile sections (label, adverse_events, recalls, approval, shortage) returned data.
adverse_eventsNoAdverse-event summary aggregated over drug/event, or null when unavailable.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation already declares readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context beyond that: fan-out in parallel, merging, best-effort sections that return null on misses, and reconciliation of identifier drift between endpoints. This goes well beyond the annotation, though it does not discuss rate limits or failure modes per sub-query, so not a 5.

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?

Four sentences, each earning its place: the core action, the alternatives it replaces, the best-effort note, and routing guidance. The most important content (what it does) is front-loaded. No fluff or repetition of schema or annotation details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool that subsumes five siblings, the description covers purpose, selection criteria, alternative routing, and behavioral expectations. It respects that an output schema exists to document return structure. Nothing an agent needs to decide whether to call it and what to expect is missing.

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% and the parameter's description already explains accepted values (brand or generic) and the resolution behavior. The tool description does not add extra parameter syntax or format details, but the schema carries the load. Baseline 3 is appropriate; there is no gap to penalize or extra value to reward.

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 states a specific verb ('Resolve... then fan out... and merge') and resource (drug profile), and enumerates the concrete sections (identity, label highlights, adverse-event summary, recall history, approval, shortage). It explicitly names the sibling tools it replaces, making it distinct from openfda_get_drug_label, openfda_search_adverse_events, etc. without needing to inspect their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says explicitly when to use this tool (for a combined profile) and when not ('For deep dives into any one area, use the dedicated tool'), and names the exact alternatives. It also flags the rationale (identifier drift) and the best-effort behavior, leaving no ambiguity about selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All openfda-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct FDA endpoint or analytic function. Search tools are separated by domain (adverse events, animal events, recalls, tobacco, etc.), and utility tools (count_values, describe_fields, dataframe_describe/query, drug_profile) serve unique purposes without overlap. An agent can clearly identify which tool to call for a given task.

Naming Consistency5/5

All tools follow a consistent openfda_<action>_<object> pattern in snake_case. Search tools use search_<domain>, while utility tools use clear verbs like get, lookup, count, describe, and query. The only slight deviation is drug_profile (a noun phrase), but it remains intuitive and fits the naming style.

Tool Count5/5

With 14 tools, the server is well-scoped for its purpose of providing access to multiple openFDA endpoints. Each tool covers a distinct resource or analytic capability, and none feel redundant. The count sits comfortably within the ideal range for a domain-specific server.

Completeness5/5

The server covers the major openFDA data categories: adverse events (human/animal), device clearances, drug approvals, shortages, recalls, tobacco, labels, and NDC lookup. It also provides robust analytics via count_values and dataframe queries, plus field discovery. There are no obvious gaps for the stated domain, and the composite drug_profile fills integration needs.

Resources