DilutionScan

Get Ended Reverse Splits

get_ended_reverse_splits

Read-only

Reverse-split episodes across companies that ended without the split taking effect, from Signal8's SEC-filing tracker: outcome "vote_failed" (shareholders did not approve), "abandoned" (the company said it will not proceed), "authority_expired" (an approval lapsed unused past its stated deadline) or "postponed_indefinitely". Splits that did happen are not in this list, and it is cross-company rather than one company's full history. Newest end first. Each row is the Reverse Splits page row (ticker, companyName, hasPage, ratio / ratioMin / ratioMax, trackerState, meetingDate, approvedDate, exchange, securityType, marketCapUsd, cik, approvalPath, domicile, splitAuthority, authorityTerms, verification) plus sourceUrl / sourceAccession and sourceDocuments (every document behind the episode, each with accession or URL) and an "ended" block: outcome, outcomeLabel, endedOn, endedOnBasis, closedReason (the tracker's own note, verbatim), voteDate, closingAccession / closingUrl (the filing that closed it, when one did). endedOnBasis says what endedOn is: "vote_date" or "meeting_date" = the vote as stated; "authority_expiry" = the stated last day of the authority; "closing_filing" = the ET day of the filing that closed it; "recorded" = none of those, the day the tracker recorded the close, which can be later than the event. Null means not measured or not stated. An empty list is what the tracker has on file for the window, not evidence that no company abandoned a split; completeness "tracked_episodes" = what the tracker has read from filings since it started, not every company. boundReached: true = the window held more episodes than one read returns (a narrower from / to window returns the rest). Locked rows are withheld, not absent. The facts are part of Signal8 Pro: a key not owned by a Pro account gets rows with locked: true and only ticker, companyName, hasPage and exchange (access "preview", lockedCount); a locked row means the facts were withheld from this caller. outcome, from and to are Pro-only filters: on a non-Pro key they apply to unlocked rows only and locked rows are left out (filtersLimitedToUnlocked: true). exchange applies to every row. Paging uses limit and the nextCursor of the previous response (null = last page). available: false (reason "tracker_not_enabled") = the tracker is switched off; an HTTP 503 FEATURE_DISABLED = the Reverse Splits page is switched off. In both cases the response says nothing about any company. The data describes what is on file and carries no view on the company, its price, or what anyone should do.

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_ended_reverse_splits"
  }
}

Input Schema

Name	Required	Description
`to`	No	Latest endedOn, YYYY-MM-DD (default: today, US Eastern).
`from`	No	Earliest endedOn, YYYY-MM-DD (default: 365 days before "to").
`limit`	No	Rows per page, 1 to 200 (default 50).
`cursor`	No	nextCursor from the previous page. Omit for the first page.
`outcome`	No	Outcomes to keep: vote_failed, abandoned, authority_expired, postponed_indefinitely. Empty = all four.
`exchange`	No	Listing venues to keep: NASDAQ, NYSE, AMEX (NYSE American), OTC, or not_measured. Empty = every row.

Output Schema

Name	Required	Description	Default
`data`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well past the readOnly/openWorld/non-destructive annotations: it discloses Pro entitlement gating (locked rows, preview access, lockedCount), that outcome/from/to filters silently apply only to unlocked rows on non-Pro keys (filtersLimitedToUnlocked), cursor pagination semantics, and failure modes (available:false tracker_not_enabled, HTTP 503 FEATURE_DISABLED) plus the important caveat that an empty list is not evidence no split was abandoned.

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 the purpose sentence, which is good, but it then becomes a dense run-on enumerating every row field even though an output schema exists, burying the crucial access-gating and empty-list caveats mid-block. Several clauses (row field list, sourceDocuments enumeration) duplicate the output schema and do not earn their place.

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 cross-company tracked-episode endpoint with entitlement gating and multiple failure modes, the description covers scope, completeness ('tracked_episodes'), pagination, locking, filters, and disabled-feature cases. Combined with the output schema handling return shape, an agent has everything needed to call it and interpret an empty or partial result correctly.

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 baseline is 3, but the description adds real meaning the schema does not: it defines each outcome value in plain language, explains endedOnBasis interpretations tied to dated fields, and clarifies that exchange applies to every row while outcome/from/to are Pro-limited. Only limit/cursor behavior is redundant with the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb/resource and scope: reverse-split episodes that ended without taking effect, cross-company, newest end first. It also distinguishes negatively ('Splits that did happen are not in this list... it is cross-company rather than one company's full history'), but never names the sibling tools (get_reverse_splits_list, get_upcoming_reverse_splits, get_reverse_split_lifecycle) it is being separated from, leaving the agent to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than prescribed: it tells you the tool covers ended episodes and that a narrower from/to window returns the remainder when boundReached is true. There is no explicit 'use X instead when' routing to the lifecycle or upcoming-splits siblings, so the agent must reason about which reverse-split tool to pick.

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

All DilutionScan tools Inspect

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

Need Help?