Skip to main content
Glama

Get Price Performance After Each Split

get_split_performance
Read-only

Get how one ticker's price moved in the N calendar days after each stock split it already executed (forward or reverse), newest first, up to 30 splits, in one call. Past executed splits only: upcoming, approved or pending splits are not included. Each split row carries executionDate, ratio ("1-for-12" = 12 old shares became 1), kind (reverse | forward | other), lastPreSplitDate, firstPostSplitDate, firstPostSplitCloseAsTraded, windowEndDate, windowEndCloseAsTraded, sessionsInWindow, changeFromFirstPostSplitClosePct (first post-split close to the last close in the window), changeFromLastPreSplitClosePct (the last pre-split close moved onto the post-split basis by the split ratio, so the split itself is not counted as a move), lowestLowVsFirstClosePct and highestHighVsFirstClosePct. Basis: the response field basis states it. Each row is on that split's own post-split basis (daily bars as traded); prices are not adjusted onto today's basis, so % moves are comparable across rows and prices are not. A null value means not measured; it does not mean 0 or "no move". Causes: a missing bar, a bar print Signal8 refused as implausible, or a window that reaches a later split (anotherSplitInWindow: true, its % withheld). notMeasured on a row names the reason per null field; dataGap = no daily bar within 7 days after the split. Stock dividends, spin-off price factors and consolidations under 1.5x that the vendor files as splits are not splits: they are listed in nonSplitAdjustments (kind, meaning), never measured or counted, and a split window containing one has its % withheld (nonSplitAdjustmentInWindow: true). An empty splits array means no executed split is on record in Signal8 split history, which is not evidence that none occurred. splitsMeasured and fellInWindow count only measured rows. asOf is the latest window-end bar date. These are past price moves, not a forecast and not investment advice. Included in Signal8 Pro: an HTTP 403 FEATURE_NOT_AVAILABLE means the API key's account is not on Pro, and the response then carries no price data for the company.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "get_split_performance"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMost recent executed splits to measure, 1 to 30 (default 20).
tickerYesUS stock ticker, e.g. "TOPS".
windowDaysNoCalendar days after each split to measure, 1 to 365 (default 30).

Output Schema

NameRequiredDescriptionDefault
dataNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations cover only read-only safety, yet the description discloses a great deal beyond them: null means not measured rather than zero, notMeasured names the per-field reason, dataGap means no bar within 7 days, windows hitting a later split or a non-split adjustment have percentages withheld, empty splits array is not evidence of no split, and an HTTP 403 means the account lacks Pro. These are exactly the traps an agent would otherwise misread.

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?

The core scope is front-loaded well in sentence one, but the remainder is a single dense paragraph enumerating roughly a dozen response fields. Since an output schema exists, much of that field-by-field exposition duplicates structured data and makes the text hard to scan. The content is accurate but not economically organized.

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 tool with derived, gap-prone measurements, the description covers the failure modes an agent must interpret: cross-basis comparability, withheld percentages, non-split adjustments, empty results, and entitlement errors. Combined with the existing output schema, nothing material is missing for correct selection and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents ticker, limit and windowDays including defaults and bounds. The description reinforces the semantics of windowDays ('N calendar days after each split') and the 30-split cap, but adds no format or edge-case detail about the parameters themselves. Baseline 3 is appropriate given the schema does the work.

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 verb and resource: how one ticker's price moved in the N calendar days after each executed split, newest first, capped at 30. It also disambiguates from split-listing siblings by scoping to already-executed splits with measured post-split performance, so an agent can distinguish it from get_split_history or get_reverse_splits_list without opening schemas.

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?

Explicitly states the when-not condition: 'Past executed splits only: upcoming, approved or pending splits are not included,' which implicitly routes those needs to the upcoming/reverse-split siblings. It also flags the Pro entitlement gate and the 403 FEATURE_NOT_AVAILABLE outcome. It stops short of naming the alternative tool for upcoming splits, so it is clear context rather than full routing guidance.

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.