Skip to main content
Glama

Alphanume Datasets

Lock-Up Expiration Calendar

get_lockup_expirations
Read-onlyIdempotent

Lock-up expiration calendar: when insider and pre-offering shares become eligible for sale after a US IPO or follow-on offering, past and UPCOMING, with the size of the locked block versus the offering float.

One row per lock-up tranche per offering, sourced from the final prospectus (SEC Form 424B4 / 424B1) filed the day after pricing. date (also served as expiration_date) = the lock-up anchor (normally the prospectus date) plus the lock-up length in calendar days; shares_sellable_from is the first NYSE session on or after it. A plain 180-day lock-up is one row (tranche_seq 1 of 1); a staggered release is several rows sharing accession_no with tranche_pct. lockup_type separates operating-company IPOs (typically 180 days) from follow-on offerings by already-public issuers (typically 60-90 days). Blank-check (SPAC) IPOs are excluded. History from 2021.

Sizing: locked_shares is the prospectus-stated locked count where given, otherwise shares outstanding after the offering minus shares offered. float_shares_at_offering = shares sold in the offering (plus the over-allotment when its exercise is stated); locked_to_float_ratio = locked / float, so 3.0 means three times the offering float unlocks on date. locked_pct_of_outstanding is the same block as a share of total shares outstanding.

Requires an Alphanume Pro API key. There is no date clamp on this route: a Pro key sees full history and the forward calendar.

Honest limits, stated plainly. Early-release clauses are common in recent IPOs (a release tied to the first earnings announcement, a price-based release, or staged tranches); the row carries early_release_type and the verbatim early_release_terms, but v1 does not compute the earlier date -- treat date as the contractual outside date when early_release_type is not 'none'. The over-allotment exercise is unknown at prospectus time, so the float can be understated by up to 15%. ticker may be NULL for a few days on a brand-new IPO; first_trade_date is IPO-only (NULL on follow-ons); market_cap_at_offering is NULL until the cap history covers the ticker; rows are never dropped for missing enrichment. confidence (0-1) is a per-row quality signal for the extracted terms; 0.9 means every term was resolved by the deterministic parser. first_seen_at is when our pull first observed the prospectus (synthetic = filing time for rows backfilled before launch).

Default order: upcoming expirations first, nearest to today first, then already-expired rows most recent first -- so the first page is the calendar of what happens next.

Pagination: results are capped at 50,000 rows per request; when the response has has_more=true, pass next_cursor's cursor_date, cursor_ticker and cursor_id back to fetch the next page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoExact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
statusNoRow status as of the last nightly sweep (ET).
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.
upcomingNo'true' = only lock-ups expiring today or later (the forward calendar); 'false' = only already-expired lock-ups. Omit for both.
cursor_idNoPagination: the 'cursor_id' value from the previous response's next_cursor.
cursor_dateNoPagination: the 'cursor_date' value from the previous response's next_cursor. Send with cursor_ticker and cursor_id.
lockup_typeNo'ipo' = operating-company initial public offerings (typically 180-day lock-ups); 'follow_on' = offerings by already-public issuers (typically 60-90 days).
cursor_tickerNoPagination: the 'cursor_ticker' value from the previous response's next_cursor (may be an empty string).
early_releaseNo'true' = only lock-ups with an early-release clause (earnings-, price-based or staggered); 'false' = plain fixed-period lock-ups only.
updated_sinceNoOnly rows updated at or after this date/datetime (YYYY-MM-DD or YYYY-MM-DD HH:MM:SS) -- for incremental syncs.
min_confidenceNoOnly rows with extraction confidence >= this value (0-1). Regex-resolved rows carry 0.9; LLM-assisted rows carry the model's own estimate.
min_locked_to_floatNoOnly rows whose locked block is at least this multiple of the shares sold in the offering (e.g. 2 = locked shares >= 2x the offering float).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the safe-read profile, but the description goes well beyond: Pro API key requirement, no date clamp on this route, 50,000-row cap, cursor mechanics, NULL behavior for ticker/first_trade_date/market_cap_at_offering, rows never dropped for missing enrichment, float possibly understated by up to 15%, and the honest early-release limitation. This is exactly the extra context annotations cannot supply.

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?

It is long but deliberately structured into purpose, sizing, limits, ordering, and pagination blocks, with the most decision-relevant content (what the tool is, what it returns) front-loaded. A few sentences (e.g. the first_seen_at/synthetic aside) are closer to trivia than actionable guidance, keeping it just below maximal conciseness.

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 17-parameter read tool with no output schema and no required params, the description supplies the return-field semantics, sizing definitions, auth requirement, ordering guarantees, pagination contract, and known data-quality caveats. An agent has everything needed to invoke it correctly and interpret the response.

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?

Schema description coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: what `date` represents as an anchor plus lock-up length, how tranche_seq/tranche_pct encode staggered releases, what confidence values mean, and the filter semantics of early_release and min_locked_to_float. It stops short of covering every one of the 17 parameters individually.

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 states a precise verb+resource (a calendar of when insider/pre-offering shares become sellable after a US IPO or follow-on) and names the source documents (424B4/424B1). It is easily separable from close siblings like get_shelf_registrations or get_dilution_filings, and even enumerates what is excluded (blank-check/SPAC IPOs, history before 2021).

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 gives strong operational context: the default ordering puts the forward calendar first, `upcoming` toggles forward vs expired, `early_release`/`min_confidence` select row quality, and pagination is explained. What it lacks is explicit routing versus alternative sibling tools (e.g. when to prefer get_shelf_registrations), so no exclusions/alternatives are named.

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.

Resources