Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

openfda_drug_approvals

Read-only

Search FDA-approved drug applications by sponsor, brand, ingredient, or application number to retrieve approval history, products, and marketing status.

Instructions

Search openFDA Drugs@FDA DRUG APPROVALS — FDA-approved drug applications (NDA/ANDA/BLA) with the sponsor, application number, approved products (brand + generic/active-ingredient name, dosage form, route, marketing status), and submission/approval history (openFDA /drug/drugsfda.json; api.fda.gov). KEYLESS (optional free OPENFDA_API_KEY only raises the rate limit — ~1000 req/day keyless; NEVER throws for a missing key). Input: STRUCTURED filters — sponsorName, brandName, activeIngredient, applicationNumber — safely escaped into the openFDA search= Lucene string (NO raw passthrough), plus limit (1..100, default 25) and skip (offset ≥0). Returns { applications:[{ applicationNumber, sponsorName, products:[{ brandName, genericIngredients:[{name,strength}], dosageForm, route, marketingStatus }], submissions:[{ submissionType, submissionNumber, submissionStatus, submissionStatusDate, submissionClass }] }] } + honest _meta. HONESTY: totalAvailable is openFDA's EXACT meta.results.total (skip/limit pagination — never results.length); every scalar is null-never-empty-string; a 'Discontinued' marketingStatus is NOT an approval revocation (disclosed in _meta). ★A no-match query returns openFDA HTTP 404 → HONEST EMPTY (returned:0/total:0), NOT an error; 400 → invalid_input; 5xx → THROWS; 200 non-JSON → schema_drift. Optional key rides ONLY in &api_key= param.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNoRow offset for pagination (default 0). Page with _meta.pagination.nextOffset.
limitNoMax application records to return (default 25, max 100). Offset-paginated via skip.
brandNameNoProduct brand name (→ products.brand_name), e.g. 'lipitor'. Matched as an escaped Lucene phrase.
sponsorNameNoSponsor / applicant company name (→ sponsor_name), e.g. 'pfizer'. Matched as an escaped Lucene phrase.
activeIngredientNoActive ingredient name (→ products.active_ingredients.name), e.g. 'atorvastatin calcium'. Matched as an escaped Lucene phrase.
applicationNumberNoFDA application number (→ application_number), e.g. 'NDA050347'. Matched as an escaped Lucene phrase.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description fully discloses error handling (404 → empty, 400 → invalid_input, 5xx → throws, 200 non-JSON → schema_drift), honesty about totalAvailable (exact meta.results.total), null-never-empty-string convention, and the distinction between 'Discontinued' and revocation. This is far more than annotations provide and sets clear expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and dense, but every sentence carries unique value: purpose, endpoint, keyless behavior, filter semantics, output structure, honesty rules, and error mapping. It is not concise in the traditional sense, but it is packed with necessary information. It earns a 4 because it could be slightly tighter while preserving all crucial 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 tool with no output schema and rich behavior, the description covers the complete return object structure, pagination semantics, error mapping, and key edge cases (e.g., no-match 404 returns empty, not error). Nothing an agent needs to call it correctly and interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While schema descriptions are 100% and each parameter is described, the tool description adds crucial meaning: filters are 'STRUCTURED filters' that are 'safely escaped into the openFDA search= Lucene string (NO raw passthrough)', and pagination with limit/skip is explained. This enriches the agent's understanding of how parameters behave and are used in queries.

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 opens with a precise verb and resource: 'Search openFDA Drugs@FDA DRUG APPROVALS — FDA-approved drug applications (NDA/ANDA/BLA)...' and enumerates the exact data fields and endpoint. It clearly distinguishes this tool from siblings like openfda_enforcement or openfda_device_clearances by naming 'DRUG APPROVALS' and providing the specific /drug/drugsfda.json endpoint.

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 gives clear context on when to use this tool — for drug approval lookups — and also provides usage guidance about the optional API key and pagination (skip/limit). It does not explicitly contrast with alternative openFDA tools, but the naming and scope make the intended use obvious. The keyless behavior ('NEVER throws for a missing key') is a useful practical guideline.

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

Deploy Server

Other Tools