Skip to main content
Glama
signal8ai

Signal8 MCP Server

Official

Get Recent Uplistings

get_recent_uplistings
Read-only

Retrieve same-day OTC-to-exchange uplistings recorded by FINRA for companies under a specified market-cap ceiling, including resolved ticker, venue, and confirmation status.

Instructions

Get OTC-to-exchange uplistings that FINRA recorded on a given US market day, for companies under a market-cap ceiling. Each row carries the old OTC symbol, the resolved new exchange symbol (or null), a confirmed flag, the destination venue (NASDAQ / NYSE / NYSE American / ARCA), company name, effective date, market cap and float in SHARES. 🔴 THIS IS A SAME-DAY READ AND THERE IS NO FORWARD-LOOKING VERSION. FINRA records an uplisting at roughly 01:45 ET ON the day it becomes effective, and the source table has no scheduled/announced column at all. So there is nothing to publish the night before, and dayOffset exists for catch-up reads of past days, NOT for forecasting — a positive offset returns nothing. Never frame these as upcoming, tomorrow, or expected; they have already happened. 🔴 newSymbol: null IS A FIRST-CLASS PUBLISHED STATE, NOT A MISSING FIELD. FINRA's row names only the OLD OTC symbol; the new ticker is resolved by company-name match against Nasdaq SymDir and sometimes cannot be resolved. A guessed or wrong ticker would name a company that did not uplist, so an unresolved row is published naming the OLD symbol and saying the new one was not resolved. DO NOT infer, guess, look up, or fill in a null newSymbol, and do not drop the row. confirmed: false means the symbol resolution is PROVISIONAL — render it as provisional, keep it out of any headline, and do not assert the new ticker as fact. Only confirmed: true is a confirmed resolution. 🔴 capUnknownCount IS A WITHHOLDING COUNT, NOT A ZERO — rows that cleared every other filter but have NO measured market cap, so they cannot be asserted to sit under the stated ceiling. It does not mean those companies have no cap. Disclose the count if you publish a cap-bracketed framing. AN EMPTY uplistings ARRAY IS THE NORMAL, EXPECTED RESULT ON MOST DAYS — uplistings run roughly 6.6 per month across ALL market caps, so the large majority of days genuinely have none. It is NOT an error, NOT an outage, and NOT evidence that uplisting activity has stopped. Publish nothing rather than publishing an empty-list framing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayOffsetNoDay offset from the US market day (default 0 = today). Negative values read past days. A positive value returns nothing — there is no forward-looking uplisting data.
maxMarketCapNoExclusive market-cap ceiling in USD (default 300000000). Rows with NO measured market cap are excluded and counted in capUnknownCount, never assumed to be under the ceiling.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only state readOnlyHint=true. The description adds substantial behavioral context: FINRA records around 01:45 ET, there is no scheduled/announced column, newSymbol:null is a first-class published state that must not be guessed, confirmed:false is provisional, capUnknownCount is a withholding count, and an empty array is normal. These go well beyond the annotation and prevent serious misinterpretation.

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 and heavily emphasized, but every section targets a real operational pitfall, and the structure front-loads the core purpose before the warnings. Some redundancy with the schema and internal repetition exist, but the density is justified by the number of edge cases an agent could get wrong.

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?

Given the output schema exists and annotations are minimal, the description fully compensates by explaining the dangerous output states: null newSymbol, provisional confirmed:false, capUnknownCount as a withholding count, and the expected empty-array case. It covers the operational ambiguities an agent needs to correctly interpret and publish results.

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%, and the description mostly restates what the schema already communicates about dayOffset and maxMarketCap (positive offset returns nothing, rows without measured market cap are counted in capUnknownCount). It does add emphasis about not using dayOffset for forecasting, but this is not net-new semantic meaning beyond 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?

The description opens with a specific verb and resource: 'Get OTC-to-exchange uplistings that FINRA recorded on a given US market day, for companies under a market-cap ceiling.' It clearly identifies the data source, the scope, and the filtering dimension, and it differentiates the tool from the many get_* siblings by its unique subject matter (uplistings) and same-day read nature.

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

Usage Guidelines5/5

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

The description explicitly says this is a same-day read, that no forward-looking version exists, and that dayOffset is for catch-up reads only, with positive offsets returning nothing. It also instructs the agent never to frame results as upcoming or expected and to treat an empty array as a normal outcome rather than an error. This is clear when-to-use and when-not-to-use guidance.

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

Deploy Server

Other Tools