Skip to main content
Glama
Sign In

Alphanume Datasets

by com.alphanume
OverviewDiscussionsAdmin

Spin-Off Calendar

get_spinoffs
Read-onlyIdempotent

Spin-off calendar: US spin-offs registered on Form 10 since 2015 -- the new company's ticker, the parent's ticker before and after, the distribution ratio, record and distribution dates, and the first regular-way trading day of the new shares, each key value stamped with the time it first became public on EDGAR.

Built for the spin-off pair trade (e.g. long the parent, short the spun-off company) and for point-in-time backtests. One row per spin-off; spin_id is the spun-off company's SEC CIK. date filters apply to first_trade_date.

first_trade_date is the first REGULAR-WAY session of the new shares. first_trade_basis says how firm it is: 'stated' (a filing gives the date), 'estimated' (the session after the distribution date -- about a third of spin-offs instead start trading ON the distribution date), 'confirmed' (the first daily bar actually printed). first_trade_confirmed_at is the UTC time the live pipeline first saw it trade (NULL for history loaded before launch). ratio = new shares per ONE parent share as the filing states it (0.5 = one for every two; before any reverse split the parent does at the spin). when_issued_date and child_wi_symbol / parent_wi_symbol describe the when-issued lines (lowercase 'w' symbols such as MSGRw), which trade thinly in the days before regular-way.

parent_listing says whether parent_ticker is a US line verified to trade before the spin ('us_listed'), or why there is none: 'foreign_only' (see parent_home_ticker, e.g. a Tel Aviv or Johannesburg listing), 'not_listed' (e.g. a non-traded REIT).

Point-in-time: registered_at (Form 10 first public), child_ticker_first_seen_at, ratio_first_seen_at and trade_date_first_seen_at are EDGAR acceptance times (UTC) of the first filing that stated the value now served. A press release can lead EDGAR by a few days. Confidential draft filings are never used.

Scope and limits: spin-offs registered on Form 10 / Form 20-F only (about 97% of spin-offs that created a new ticker since 2016); split-offs and separations registered on S-1/S-4 (e.g. tracking-stock reorganizations) are not covered. About 1 spin-off in 7 has no trading date until it trades.

Default order: the forward calendar first (registered / scheduled, nearest expected first trade first), then everything else, most recent first trade first.

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

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_spinoffs"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoExact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
statusNoComma-separated statuses: registered (Form 10 public, no trade date yet), scheduled (a first trade date is stated or estimated), completed (the new shares traded regular-way), withdrawn, inactive (no trade 10+ days past the expected date, or no filing for 18 months); or the shorthands 'all' (default) and 'upcoming' (registered + scheduled).
tickerNoSymbol matched against the spun-off company (child_ticker), the parent before the spin (parent_ticker) and the parent after it (parent_ticker_after), so any side works.
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.
updated_sinceNoOnly rows updated at or after this date/datetime (YYYY-MM-DD or YYYY-MM-DD HH:MM:SS) -- for incremental syncs.

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?

Beyond readOnly/idempotent annotations, the description discloses the point-in-time model (EDGAR acceptance timestamps per field, with the caveat that press releases can lead EDGAR), the confidence tiers behind first_trade_basis, the ratio convention per one parent share before reverse splits, the meaning of parent_listing values, and the default ordering. It also flags the API-key requirement and the absence of a date clamp.

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 core identity and intended use are front-loaded, then field semantics, then scope limits. It is long and dense, but essentially every sentence carries decision-relevant information for a tool with no output schema. Slightly over-packed for a single read, which keeps it off a 5.

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?

With no output schema, the description takes on the burden of explaining return fields and does so thoroughly: row granularity (one per spin-off), spin_id as the SEC CIK, first_trade_basis tiers, when-issued lines, and parent_listing enumeration. Coverage limits (roughly 97% of new-ticker spin-offs, one in seven lacking a trade date until it trades) and default ordering complete the picture an agent needs.

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 coverage is 100%, so the parameter descriptions carry most of the load and baseline is 3. The description adds one genuinely important semantic the schema omits: all date filters apply to first_trade_date, not to registration or distribution dates. Ratio and ticker-side conventions are also clarified, though these are about returned fields rather than inputs.

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 first sentence states a specific resource (US spin-offs registered on Form 10 since 2015) and enumerates the payload fields, including the ticker pair, ratio, and dates. An agent can tell immediately this is the spin-off event dataset and distinguish it from sibling calendars like get_buybacks, get_reverse_splits, or get_de_spac_events without opening the schema.

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 names the intended use cases ('spin-off pair trade' and 'point-in-time backtests') and closes with explicit when-not boundaries: S-1/S-4 split-offs and separations are not covered, and only Form 10/20-F registrations are included. It stops short of pointing to an alternative tool for the excluded cases, so 4 rather than 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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources