Skip to main content
Glama

Alphanume Datasets

Short Locates

get_short_locates
Read-onlyIdempotent

Short-locate costs: what it costs to locate (borrow for shorting) shares of every hard-to-borrow US stock, observed twice a day -- point-in-time, never revised.

One row per (date, slot, ticker). Each sweep prices every listed US stock the broker marks NOT easy-to-borrow (~7,500 names). Served per row: date (US/Eastern trading date of the sweep), slot (am / pm), snapshot_time_utc (when the sweep ran, UTC to the minute, e.g. '2026-10-15 11:45' -- every row of a sweep shares it), ticker, status, price_per_share (USD per share), cost_per_100 (USD to locate 100 shares) and available_qty (shares that can be located right now). price_per_share and cost_per_100 are NULL unless status is 'offered'; available_qty is NULL unless a quote came back (0 for 'no_shares').

Typical uses: the borrow cost of a short idea on a given morning, names whose locate cost spiked or whose availability dried up, threshold-list membership over time, and the cost side of a short-selling backtest from 2026-10-08 onward.

Requires an Alphanume Pro API key. There is no date clamp on this route.

Honest limits, stated plainly. These are one broker's (Alpaca's) locate quotes for its own inventory, not a market-wide borrow rate -- another broker can quote the same name 2x higher or lower. Names the broker lends freely (easy-to-borrow) are not in the dataset. History starts 2026-10-08 and there is no backfill: locate quotes only exist live. Two sweeps a day, so intraday moves between sweeps are not captured.

Default order: newest date first, pm before am, then ticker, so the first page is the latest sweep. One sweep is ~7,500 rows: filter by ticker, date, slot or status to keep results small.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoExact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
slotNoWhich daily sweep: 'am' (11:45 UTC; 07:45 ET in summer, 06:45 ET in winter) or 'pm' (17:30 UTC; 13:30 ET in summer, 12:30 ET in winter).
statusNoWhat the broker answered: 'offered' (shares can be located; price and availability set); 'no_shares' (none available right now); 'threshold' (on the Reg SHO threshold list, cannot be located); 'unavailable' (no quote); 'corporate_action' (cannot be quoted due to a corporate action); 'error' (other refusal).
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.
cursor_dateNoPagination: the 'cursor_date' value from the previous response's next_cursor. Send with cursor_slot and cursor_ticker.
cursor_slotNoPagination: the 'cursor_slot' value from the previous response's next_cursor.
cursor_tickerNoPagination: the 'cursor_ticker' value from the previous response's next_cursor.
min_cost_per_100NoOnly rows whose cost to locate 100 shares is at least this many US dollars (e.g. 5 for $5 per 100 shares). Unpriced rows are excluded whenever this is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, so this description goes well beyond them: it discloses the data source (one broker's inventory, not market-wide), history start with no backfill, twice-daily gaps, NULL semantics tied to status, default ordering, the 50k pagination cap, and the no-date-clamp behavior. This is rich behavioral context an agent could not infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Front-loaded with purpose and heavily structured, but it's long and somewhat sprawling for an agent-facing description, with several sentences that overlap with schema-provided detail (e.g. re-stating cursor fields, re-listing statuses/labels already documented per-parameter). Earns its length but could be tighter.

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 13-parameter, no-output-schema, high-complexity financial dataset, the description covers provenance, temporal coverage, NULL/status rules, default ordering, pagination mechanics and known limitations. Nothing critical to correct invocation 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?

Schema description coverage is 100%, so baseline is 3, but the description adds real value on top: it explains row semantics (date/slot/snapshot_time_utc/ticker/status/price_per_share/cost_per_100/available_qty), the NULL rules, and reiterates pagination cursor behavior. It complements rather than repeats the schema.

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?

States a specific verb+resource: short-locate (borrow) costs for hard-to-borrow US stocks, observed twice daily. The scope ('hard-to-borrow', 'twice a day', 'point-in-time, never revised') makes it unmistakably distinct from any sibling such as get_historical_market_cap or get_optionable_tickers.

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 explicit typical uses: morning borrow cost of a short idea, cost spikes, availability changes, threshold-list membership, and short-selling backtest cost. It doesn't name a specific alternative sibling to route to, but the domain is narrow enough that no sibling overlaps.

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