Skip to main content
Glama

Alphanume Datasets

by com.alphanume

FDA Response Events

get_fda_response_events
Read-onlyIdempotent

Adverse FDA regulatory actions disclosed in 8-Ks: Complete Response Letters, full and partial clinical holds, and refuse-to-file letters, 2024+, each graded by an explicit severity precedence rule with the evidence flags the grade depends on served alongside it (new-trial-required, manufacturing-related, resubmission-path, hold-lifted). Follow-ups and resolutions are linked per (issuer, drug program), so an original hold row answers 'was it ever lifted, and how long did it take'.

By default only classified FDA events are returned (~196 rows); the ~1,520 audited not-an-event rows the full-text sweep also retrieved are available with include_rejects=true. The date window filters disclosed_date (the EDGAR filing date); event_letter_date is extracted with its own precision enum and days_letter_to_disclosure is the selective-disclosure measure -- on initial_disclosure rows only (on follow-ups it measures distance to the original letter). Selective disclosure is the headline caveat: a CRL disclosed only in a 10-Q, or never, is not here.

Requires an Alphanume Pro API key. A 403 PRO_SUBSCRIPTION_REQUIRED or DATE_RANGE_RESTRICTED error means the key's plan does not cover the request -- it does not mean the data is missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoSEC CIK number (digits only).
dateNoExact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
tickerNoTicker symbol filter, e.g. 'AAPL'. Case-insensitive.
date_gtNoStart of date range, exclusive (YYYY-MM-DD).
date_ltNoEnd of date range, exclusive (YYYY-MM-DD).
date_gteNoStart of date range, inclusive (YYYY-MM-DD).
date_lteNoEnd of date range, inclusive (YYYY-MM-DD).
max_rowsNoMaximum data rows to return to the client (applied after the API responds). Default 500. Use 0 for no cap. Prefer narrowing with date/ticker filters over raising this.
resolvedNotrue = events with a linked later resolution (hold lifted, approval, resubmission accepted); false = still open. NULL rows are themselves resolutions.
severityNoComma-separated severity grades: program_terminated, major_delay_new_trial_required, manufacturing_only, addressable_deficiencies, safety_signal_no_path_stated, unstated, not_restated. Rank encodes grading precedence, NOT market impact.
asset_keyNoExact normalized program key -- groups all filings about one program and audits the served linkage columns.
event_typeNoComma-separated: crl, clinical_hold_full, clinical_hold_partial, refuse_to_file, other_fda_action. (not_a_setback_event requires include_rejects=true.)
cursor_dateNoPagination: 'date' from next_cursor (send with cursor_accession).
drug_searchNoCase-insensitive substring on the drug/asset name (3+ chars).
filing_roleNoWhat the document does about the event: initial_disclosure, follow_up_update, or resolution. Counting rows without this filter overstates events ~2.4x -- one program's hold can be 3+ filings.
updated_sinceNoYYYY-MM-DD, on last_updated -- rows touched by the linkage sweep since this date.
include_rejectsNotrue = include the ~1,520 audited 'not_a_setback_event' rows (boilerplate the recall-first sweep retrieved and the labeler rejected, each with its reason). Default = real FDA events only.
cursor_accessionNoPagination: 'accession_number' from next_cursor (send with cursor_date).

Schema Changelog

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

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses default row counts, that date filters apply to disclosed_date, linkage of follow-ups/resolutions per program, the selective-disclosure limitation, and auth-related 403 meanings. No contradiction with annotations.

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 because the tool is complex, and it is front-loaded with the core purpose before caveats and auth. Every sentence carries information, but some clauses are dense and could be tightened slightly.

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 18-parameter read-only tool with no output schema, the description covers default scope, optional reject rows, date semantics, linkage model, selective-disclosure limits, and error interpretation. This is sufficient for an agent to select and invoke it correctly.

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?

Although schema coverage is 100%, the description adds cross-parameter meaning: date window semantics, days_letter_to_disclosure only on initial_disclosure rows, filing_role overstating event counts ~2.4x, and severity rank encoding precedence rather than market impact. This materially helps correct parameter selection.

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 specific verb-resource pairing: adverse FDA regulatory actions disclosed in 8-Ks, enumerating CRLs, full/partial clinical holds, and refuse-to-file letters. This clearly distinguishes it from sibling tools covering other event types like cyber incidents or SEC trading suspensions.

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 establishes the domain and scope explicitly, including a when-not caveat: CRLs disclosed only in a 10-Q or never are not present. It also explains default vs include_rejects behavior, though it does not name alternative sibling tools for out-of-scope queries.

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

All Alphanume Datasets 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.2/5.0
Disambiguation4/5

Each tool maps to a distinct dataset, and the descriptions are detailed enough to resolve most ambiguity. A few adjacent pairs (S-1 dilution vs. shelf registrations, IV-HV premium vs. IV rank, FDA votes vs. FDA adverse events) share thematic surface area and could be confused by name alone.

Naming Consistency4/5

The overwhelming majority of tools follow a clean get_<noun_phrase> snake_case pattern. The two exceptions, check_api_status and list_market_cap_tickers, are semantically appropriate utility/companion tools but break the otherwise uniform verb prefix.

Tool Count3/5

At 27 tools, the surface is heavy and spans many unrelated financial domains, making selection and prompt context more expensive. Each tool does earn its place as a distinct dataset, but the server would benefit from some consolidation or a higher-level catalog tool.

Completeness4/5

As a read-only datasets API, the surface is broadly complete: status checking, pagination, and one coverage-map companion exist where needed. Minor gaps include the absence of a global dataset catalog/coverage listing and the lack of companion list tools for most other datasets.

Resources