Skip to main content
Glama

Alphanume Datasets

by com.alphanume

FDA Advisory Committee Votes

get_advisory_committee_votes
Read-onlyIdempotent

FDA advisory-committee (AdCom) votes: every drug/biologic advisory committee meeting from 2024 forward, with the committee's exact vote tallies extracted from the official minutes PDFs (verified against the PDFs) -- one row per (meeting, vote question). The tally (vote_yes/vote_no/vote_abstain), the verbatim question, which answer was the product-favorable one, and whether the favorable side won; plus sponsor, drug, indication, committee, center, meeting status, and links to the minutes/transcript/briefing materials so any number can be checked at the source.

A meeting with no tally is still a row -- vote_evidence says why (minutes not posted yet vs discussion-only vs not held), which is the difference between 'no data' and 'no vote'. Minutes land MONTHS after meetings, so recent meetings sit at minutes_not_posted until FDA publishes; rows re-label automatically when materials change. The forward calendar (scheduled meetings) is included. AdCom votes precede FDA decisions by weeks-to-months and FDA usually -- not always -- follows them.

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. Note: meetings are sparse (a few per month), so short date windows are often legitimately empty.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoExact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
drugNoCase-insensitive substring on the drug/asset name (2-100 chars).
centerNoOwning FDA center: CDER, CBER, or OC (Office of the Commissioner).
date_gtNoStart of date range, exclusive (YYYY-MM-DD).
date_ltNoEnd of date range, exclusive (YYYY-MM-DD).
sponsorNoCase-insensitive substring on the sponsor company (2-100 chars).
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.
asset_keyNoExact normalized asset key -- the group-by for 'every AdCom appearance of this asset' and the linkage audit key.
committeeNoCommittee abbreviation (e.g. ODAC, VRBPAC, PDAC) or name substring. Matches joint meetings via the full committee list, so PDAC finds meetings where it co-sat.
has_tallyNotrue = only rows with a numeric vote tally; false = only placeholder/no-tally rows.
applicationNoSubstring on the application identifiers (NDA/BLA/sNDA numbers as stated in the materials).
meeting_keyNoExact meeting page slug -- all vote rows of one meeting.
updated_sinceNoYYYY-MM-DD, on last_updated -- rows re-projected after FDA posted new materials (minutes land months late).
vote_evidenceNoWhy a row does/doesn't carry numbers: minutes_tally (real tally), minutes_no_tally, no_vote_held (discussion-only), minutes_not_posted (FDA hasn't published minutes yet), meeting_not_held.
meeting_statusNoheld, scheduled, postponed, or cancelled. 'scheduled' rows are the forward calendar.
meeting_topic_typeNoproduct_specific, compounding_nominations, strain_selection, safety_review, or policy_or_class_review.
vote_outcome_favorableNotrue = the product-favorable side won; false = it lost. Ties and strain-selection votes are NULL and excluded by either value.

Schema Changelog

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

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses important behaviors: rows re-label when FDA materials change, no-tally rows carry vote_evidence explaining why, the forward calendar is included, and tallies are verified against official PDFs. It also explains the real-world latency around minutes publication. 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.

Conciseness5/5

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

The description is long but dense and front-loaded: the first sentence establishes scope and data source, followed by row semantics, update behavior, and operational caveats. Each paragraph earns its place by explaining a distinct aspect of the data an agent needs to call and interpret the tool correctly.

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 19 optional parameters, no output schema, and read-only annotations, the description is unusually complete: it states the row model, the meaning of placeholders, update timing, auth requirements, error interpretation, and the sparse-data caveat. An agent can both invoke the tool and interpret results without major blind spots.

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 already documents all 19 parameters with 100% description coverage, so the baseline is 3. The description adds useful semantic context around the data model, such as vote_evidence distinguishing 'no data' from 'no vote,' but it does not meaningfully elaborate on individual parameter formats or constraints beyond what the schema already provides.

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 names a specific resource (FDA advisory-committee votes) and a precise scope (every drug/biologic AdCom meeting from 2024 forward), with the row unit defined as one row per meeting/vote question. It also specifies the exact data provenance: tallies extracted and verified against official minutes PDFs. This clearly differentiates it from generic FDA or market-data siblings.

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 provides practical usage context: minutes arrive months later, recent rows may be minutes_not_posted, short date windows can be legitimately empty, and 403 errors indicate plan limitations rather than missing data. It stops short of naming sibling alternatives or explicitly saying when to prefer another tool, so it does not reach 5.

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