Skip to main content
Glama

Openfda Search Drug Approvals

openfda_search_drug_approvals
Read-only

Search the Drugs@FDA database for drug application approvals (NDAs and ANDAs). Returns application details, sponsor info, and full submission history. Pair with openfda_get_drug_label to read the approved label, or openfda_count_values to aggregate by sponsor_name, product_type, or route.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNoNumber of records to skip for pagination (default 0). openFDA caps pagination at 25000 records; a higher value returns a pagination_limit_reached error.
sortNoSort expression — a field path optionally suffixed with :asc or :desc; comma-separate for multi-field sort. Example: submissions.submission_status_date:desc. Field paths take only letters, digits, underscores, and dots; anything else is rejected before the request. A well-formed but non-sortable field still causes a query error — use a documented field name.
limitNoMaximum number of records to return (1-1000, default 10). Serialized record size varies by three orders of magnitude across openFDA endpoints, so the page is also bounded by a 24000-byte serialized budget: a page that would overrun it returns fewer records than requested and reports the cut on page_omitted. Whenever any record matched, at least one comes back, however large it measures. A record carries its application's whole submission history, so a long-running application is an order of magnitude larger than a recent one.
stageNoStage the matched set on a DataCanvas for SQL analysis with openfda_dataframe_query. Default false — the call returns one page for one upstream request. When true, records are also drained onto a canvas table up to a size budget (staged_rows reports how many reached it). Staging is for record-level SQL over a bounded slice; for a distribution over everything that matched, openfda_count_values aggregates server-side in one request. Requires CANVAS_PROVIDER_TYPE=duckdb.
searchNoopenFDA search query. Examples: openfda.brand_name:"humira", sponsor_name:"PFIZER", submissions.submission_type:"ORIG" AND submissions.review_priority:"PRIORITY". Exact quoted values can be case-sensitive on some fields — sponsor_name is stored uppercase, so use sponsor_name:"PFIZER" (a lowercase quoted value returns no matches). Omit to browse recent. Double quotes, parentheses, and range brackets must balance, and the query must not end on a backslash — each is rejected before the request.
canvas_idNoDataCanvas session id from a prior call. Passing one stages this search onto that canvas (same effect as stage=true) so result sets accumulate for cross-table joins. Omit to stage onto a fresh canvas.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNoResponse metadata
errorNoPresent when the call failed. Absent on success.
noticeNoCanvas staging disclosure when the call staged, the byte-budget disclosure and the routes to the withheld records when the inline page was bounded, and guidance when results are empty — how to broaden filters or correct field names.
resultsNoDrug application records — application_number, sponsor_name, openfda block (brand_name, generic_name, route, product_type, substance_name), products[] (active_ingredients, dosage_form, marketing_status), submissions[] (submission_type, submission_status, submission_status_date, review_priority).
spilledNoTrue when this call staged its matched set on the canvas — use canvas_id with openfda_dataframe_query for SQL. Absent when staging was not requested.
canvas_idNoDataCanvas session id for the staged result set. Present when this call staged. Pass to openfda_dataframe_query / openfda_dataframe_describe, or back into this tool to accumulate more tables on the same canvas.
truncatedNoTrue when fewer rows reached the canvas than matched upstream — staging stopped at its size budget or openFDA's 25000-row pagination ceiling. Narrow the query (filters, date range) for a complete set.
page_bytesNoSerialized size of results in this response, in bytes. Present only when the 24000-byte inline budget bounded the page; larger than the budget only when a single record exceeds it on its own.
staged_rowsNoRows written to the canvas table. Compare with meta.total: a smaller value means staging stopped at its size budget and the table holds only the first staged_rows records.
canvas_tableNoCanvas table holding the staged rows. Present when rows were staged; reference it in SQL FROM clauses.
page_omittedNoRecords dropped from the requested limit/skip window so the page fit the inline byte budget. Present only when the page was bounded. Read them by re-calling with skip advanced by the number of records returned, lower limit for a smaller page, or pass stage=true to query a bounded drain of the match with openfda_dataframe_query.
totalResultsNoTotal matching drug approval records in the dataset
effectiveQueryNoSearch filter applied to the Drugs@FDA query, as submitted to openFDA

TDQS

A4.1/5.0
Behavior3/5

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

The annotation readOnlyHint=true already conveys the read-only nature, lowering the burden on the description. The description adds that it returns 'application details, sponsor info, and full submission history', which is marginally beyond the annotation but not deeply behavioral (e.g., pagination, errors are left to the schema). No contradictions with annotations found.

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 exactly two sentences: the first front-loads the core purpose, and the second provides concise pairing guidance. Every phrase adds value; no redundancy or filler exists.

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?

Given an output schema exists and the parameter schema fully documents all 6 optional parameters, the description covers the essential usage context. It explains where the data comes from, what it returns, and how to extend the workflow with complementary tools. Nothing critical for an agent to call the tool correctly 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?

The input schema has 100% coverage with detailed descriptions for each of the 6 parameters, including pagination limits, sort syntax, staging behavior, and search examples. The description does not need to add parameter-level detail, so a baseline score of 3 is appropriate. It even hints at aggregatable fields (sponsor_name, product_type, route) which complements the 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?

The description states a specific verb ('Search'), resource ('Drugs@FDA database'), and scope ('drug application approvals (NDAs and ANDAs)'), making the tool's purpose unambiguous. It also distinguishes from siblings like openfda_search_adverse_events by focusing on approvals, and mentions the return content (application details, sponsor info, submission history).

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?

The description explicitly recommends pairing with openfda_get_drug_label to read approved labels and openfda_count_values for aggregation, providing clear workflow guidance. It implies when to use this tool versus alternatives by naming the database and approval focus, though it does not explicitly exclude other search tools. The purpose is distinct enough that an agent can infer when to choose this tool.

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

Try in Browser

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.