Skip to main content
Glama

Openfda

by io.github.pipeworx-io

Fda Applications By Cik

fda_applications_by_cik
Read-onlyIdempotent

Find ALL Drugs@FDA applications for a company by SEC CIK, ticker, or company name — without needing to know its FDA sponsor_name spelling. Drugs@FDA has no company-ID field: sponsor_name is free text, and one company routinely files under several forms (e.g. Eli Lilly appears as "LILLY", "ELI LILLY AND CO", "ELI LILLY CO", "LILLY RES LABS" — its own SEC-registered name "ELI LILLY AND COMPANY" matches ZERO of them in fda_drug_approvals). This resolves the company via SEC (same identity as the edgar pack), derives its most distinctive name token, and searches Drugs@FDA for every sponsor_name variant containing it in one call — returning the combined application list plus a sponsor_name_forms breakdown showing exactly which spellings were found. Use this INSTEAD of guessing sponsor_name strings for fda_drug_approvals when you have (or can resolve) the company's CIK/ticker. For a subsidiary or operating name that isn't itself SEC-listed, resolve to the parent first with edgar's sponsor_to_filer, then pass that CIK here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax applications to return (1-200, default 100).
cik_or_tickerYesSEC CIK (e.g. "59478"), stock ticker (e.g. "LLY"), or exact SEC-listed company name (e.g. "Eli Lilly and Co").

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds significant context beyond that. It explains why the tool exists (no FDA company-ID field, free-text sponsor_name variants), how it resolves identities (SEC lookup plus distinctive token matching), and what it returns (combined application list plus sponsor_name_forms).

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 longer than average but front-loaded with the core action and every sentence earns its place. The Eli Lilly spelling example is not padding; it concretely motivates the identity-matching problem the tool solves.

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?

The description covers what the tool does, why it is necessary, when to use it instead of fda_drug_approvals, how it matches sponsor names, and what the high-level return shape is. With both parameters fully documented in the schema and safety expressed in annotations, nothing needed to select or invoke the tool correctly is missing.

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?

The schema already documents both parameters fully, so the baseline is 3. The description adds useful parameter-level guidance by explaining that cik_or_ticker is resolved via SEC as the same identity used by the edgar pack and by telling the agent to pass a parent CIK for subsidiaries that are not themselves SEC-listed.

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 opens with a specific verb and resource: 'Find ALL Drugs@FDA applications for a company by SEC CIK, ticker, or company name.' It also names the core value proposition — removing the need to know FDA sponsor_name spelling — and explicitly contrasts itself with fda_drug_approvals, so an agent can distinguish it from siblings.

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?

This is an explicit routing rule: 'Use this INSTEAD of guessing sponsor_name strings for fda_drug_approvals when you have (or can resolve) the company's CIK/ticker.' It also gives a concrete alternative for subsidiaries or unlisted operating names: resolve to the parent first with edgar's sponsor_to_filer, then pass that CIK.

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

All Openfda 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
Disambiguation4/5

Most tools have distinct names and purposes, but the large number of meta-tools (e.g., ask_pipeworx variants, deep_research) and overlapping research/scanning tools (entity_profile, compare_entities, recent_changes) could cause confusion. An agent may need to carefully read descriptions to choose correctly.

Naming Consistency3/5

Snake_case is prevalent but not universal. FDA tools are consistently named with 'fda_' prefix, but there are single-word verbs (remember, recall), camelCase is absent, and some tool names are long and descriptive (scan_competitor_ai_presence). The mix of patterns is readable but not highly consistent.

Tool Count3/5

43 tools is high and includes both dedicated tools and meta-tools that can access thousands more. There is redundancy (e.g., FDA data can be retrieved via fda_drug_approvals or ask_pipeworx). The scope is broad, but many tools could be consolidated. Count feels borderline excessive for the apparent purpose.

Completeness4/5

FDA coverage is excellent with tools for approvals, labels, events, recalls, shortages, warning letters, etc. Other domains (financial, betting, npm) are covered by meta-tools, providing breadth. However, dedicated non-FDA tools are sparse, and the server relies heavily on the universal query tools for completeness.

Resources