Skip to main content
Glama

Openfda Lookup Ndc

openfda_lookup_ndc
Read-only

Look up drugs in the NDC (National Drug Code) Directory. Identify drug products by NDC code, find active ingredients, packaging details, or manufacturer info. Pair with openfda_get_drug_label using the returned brand_name or set_id to read the package insert.

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: listing_expiration_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 grows with its packaging list, so a product with many package configurations is several times the size of one with a single package.
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.
searchYesopenFDA search query. Examples: product_ndc:"0363-0218", brand_name:"aspirin", generic_name:"metformin", openfda.manufacturer_name:"walgreen", active_ingredients.name:"ASPIRIN". 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 lookup 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.
resultsNoNDC directory records — product_ndc, brand_name, generic_name, labeler_name, dosage_form, route, marketing_category, active_ingredients[], packaging[], listing_expiration_date.
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 NDC records in the dataset
effectiveQueryNoSearch filter applied to the NDC lookup, as submitted to openFDA

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a useful integration hint (pairing with get_drug_label) and mentions output fields, but does not disclose additional behavioral traits beyond what annotations and the schema (pagination, limits) already describe. A 3 is the appropriate baseline.

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?

Three sentences with no wasted words: first states the core purpose, second lists searchable attributes, third gives a practical integration hint. The key 'look up drugs in NDC Directory' is front-loaded, making it instantly scannable.

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 the rich schema (all parameters documented) and an output schema, the description provides all necessary high-level context, including a pointer to a related tool for further steps. Pagination, sort, and other details are covered schematically, so nothing essential is omitted.

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 all six parameters have detailed descriptions. The description adds no extra parameter-level meaning; only mentions output fields (brand_name, set_id) which is fine. Baseline 3 applies because the schema does the heavy lifting.

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 tool looks up drugs in the NDC Directory and enumerates the specific identifiers it can find (NDC code, active ingredients, packaging, manufacturer). This differentiates it from siblings like openfda_search_adverse_events or openfda_get_drug_label without needing to inspect schemas.

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?

It provides a concrete use case (identify drug products) and explicitly suggests pairing with openfda_get_drug_label using returned fields, which is actionable. However, it does not explicitly mention when not to use this tool or contrast with similar options like openfda_drug_profile, so it misses the full 'when-not/alternatives' guidance.

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.