Alphanume Datasets

Pre-Market Drop Risk

get_premarket_drop_risk

Read-onlyIdempotent

Pre-market drop risk: model-estimated probability of an intraday decline in US microcaps, published each morning before the open.

Each trading morning, by ~09:25 ET and ahead of the 09:30 open, a RandomForestClassifier scores every microcap that actually traded in the pre-market session and this dataset serves the names ranked by modeled drop risk. Features are cut at a fixed 09:00 ET pre-market cutoff. prob_drop is P(intraday open->close return <= -5%); one row per (date, ticker), ordered by rank_for_date (1 = the highest-probability name that day). It measures the subset the model flags, not everything that moved overnight, and is built for researchers and traders analyzing pre-market activity in US microcaps.

Requires an Alphanume Pro API key. There is no date clamp on this route: a Pro key sees the whole history, whatever dates it asks for.

Sub-$1 names are featured, not filtered. Every row the model flags is published, each carrying a sub_dollar flag: pass min_price=1 for the legacy '$1 and up' screen, sub_dollar=1 (or max_price=1) to isolate the penny cohort, max_rank=5 for the day's top five.

History before go-live (2026-08-31) is walk-forward simulated: generated retrospectively by re-running the walk-forward loop (train on strictly-prior rows only, then score that date). There is no look-ahead in the features or the training window, but rows dated before go-live are not a real-time publication record; rows from go-live onward are published live each morning before the open.

Outcomes fill in late, never early. intraday_return_pct lands the same evening; return_lead_1d / return_lead_5d / return_lead_30d only once 1 / 5 / 20 NYSE sessions have elapsed -- NULL means not yet mature, or no exchange print existed at maturity (halts and delistings, which this microcap universe produces regularly). Three documented quirks kept for continuity with the training set: return_lead_30d is 20 trading sessions rather than 30 calendar days; return_lag_1m uses the 21-session price change over the price 252 sessions back (a legacy denominator quirk, so it is not a clean 1-month return); and the t_0..t_9 pre-market return grid is 0-filled, not NULL, when no print exists at or before that clock mark.

Borrow and locate costs are NOT modeled. Shorting a sub-$1 microcap needs a locate that may be expensive or simply unavailable, and no number served here carries that cost. sub_dollar and min_price are the levers for filtering toward borrowable names.

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

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	Exact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
`ticker`	No	Ticker symbol filter, e.g. 'AAPL'. Case-insensitive.
`date_gt`	No	Start of date range, exclusive (YYYY-MM-DD).
`date_lt`	No	End of date range, exclusive (YYYY-MM-DD).
`date_gte`	No	Start of date range, inclusive (YYYY-MM-DD).
`date_lte`	No	End of date range, inclusive (YYYY-MM-DD).
`max_rank`	No	Only rows with rank_for_date <= this value (>= 1). max_rank=5 gives the top five names per day.
`max_rows`	No	Maximum 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.
`min_prob`	No	Only rows with prob_drop >= this value, range [0, 1]. 0.7 keeps the model's higher-conviction names.
`max_price`	No	Only rows with px_at_trading <= this value (USD, >= 0). max_price=1 isolates the sub-$1 cohort. Must be >= min_price.
`min_price`	No	Only rows with px_at_trading >= this value (USD, >= 0). min_price=1 reproduces the legacy '$1 and up' screen.
`sub_dollar`	No	'1' = only names priced under $1 at the 09:00 ET cutoff, '0' = only names at $1 or above. Convenience equivalent of min_price/max_price around $1.
`cursor_date`	No	Pagination: the 'date' value from the previous response's next_cursor. Must be sent together with cursor_rank.
`cursor_rank`	No	Pagination: the 'rank_for_date' value from the previous response's next_cursor. Must be sent together with cursor_date.

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses publication timing (before the open, ~09:25 ET), walk-forward simulated history with a go-live date, later-filling outcome columns, NULL semantics, and known quirks in return fields. It also documents the 50,000-row pagination cap and cursor mechanics.

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, but it is front-loaded with a one-sentence summary and organized into topic paragraphs (timing, authentication, simulation, outcome maturity, caveats, pagination). A small amount of repetition exists around pre-market publication and sub-$1 filtering, but the density is justified by the tool's complexity and lack of an output schema.

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 14-parameter, no-output-schema tool, this is exceptionally complete: it names the key output fields (prob_drop, rank_for_date, intraday_return_pct, return_lead_*), explains their timing and NULL meaning, covers historical simulation, auth, filtering levers, and pagination. An agent has everything needed to call this tool correctly and interpret results.

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?

While the schema already documents all 14 parameters (100% coverage), the description adds relational meaning: min_price=1 reproduces the legacy screen, sub_dollar=1 or max_price=1 isolates the penny cohort, and max_rank=5 returns the day's top five. It also explains cursor_date/cursor_rank pagination beyond the schema's 'must be sent together' note.

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 statement: 'model-estimated probability of an intraday decline in US microcaps,' then defines prob_drop as P(intraday open->close return <= -5%). It also distinguishes the dataset from generic movers by saying 'It measures the subset the model flags, not everything that moved overnight.'

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 clearly says the data is 'built for researchers and traders analyzing pre-market activity in US microcaps' and spells out the Pro API key requirement. It also defines what the tool is not for ('Borrow and locate costs are NOT modeled'), though it never names sibling tools as alternatives.

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

All Alphanume Datasets tools Inspect

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

Need Help?