Kaleidoscope MCP (SEC & financial data)

IPO Screen (recent IPOs from 424B4 pricing prospectuses)

sections_ipo_screen

Read-onlyIdempotent

List recent IPOs in a date window, from 424B4 final-pricing prospectuses (the definitive 'this company went public' filing). Sections has 2020-2026 424B4 coverage (~99.9% of the catalyst_calendar IPO universe).

One row per company = its FIRST-time IPO — each CIK's EARLIEST-EVER non-SPAC 424B4 (scanned across all years, then filtered to the window). So a company that IPO'd in 2020 does NOT appear as a '2026 IPO' just because it filed a 2026 follow-on; renames of already-public companies aren't re-surfaced either. A renamed issuer carries current_company_name when it differs from the name at IPO (e.g. Classover → KIDZ AI), so it's findable both ways. For every 424B4 as a row (follow-ons + re-pricings) pass dedup_mode='per_accession'. For a CIK's full filing history use sections__get_filing.

SPACs excluded by default (SIC 6770) — pass exclude_spac=false to include them. Sorted newest-IPO-first (filing_date DESC), capped at top_n.

Filters: sector (SIC prefix, e.g. '28' pharma / '60' banks) OR sic_filter (array of exact SIC codes). Pair with sections__ipo_risk_factors to pull the classified risk factors from any of the returned IPOs' prospectuses.

Perf: ~3-4s for a ~2yr sector cut, ~17s for a full 3yr universe (per-year 424B4 metadata scroll). Narrow the window / sector to stay fast.

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": {
      "since": "<since>"
    },
    "name": "sections_ipo_screen"
  }
}

Input Schema

Name	Required	Description	Default
`since`	Yes	Window start, YYYY-MM-DD (required).
`top_n`	No	Max IPOs to return (default 50).
`until`	No	Window end, YYYY-MM-DD. Default: today.
`sector`	No	SIC prefix filter (e.g. '28' pharma/chem, '60' banks, '73' software).
`dedup_mode`	No	'per_cik' (default) = one row per company = its FIRST-time IPO (earliest-EVER non-SPAC 424B4); follow-on offerings and renames of already-public companies are NOT re-surfaced as new IPOs. 'per_accession' = every 424B4 in the window as its own row (surfaces follow-ons + re-pricings — use only if you specifically want all offering filings).	per_cik
`sic_filter`	No	Exact SIC codes (array of strings; SIC is KEYWORD-indexed). Alternative to sector.
`exclude_spac`	No	Exclude SPACs (SIC 6770). Default true.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, so the description is free to add semantics, which it does: the earliest-ever non-SPAC 424B4 scan across all years, the exclusion of renames of already-public companies, the current_company_name carry-over field, filing_date DESC ordering, and the top_n cap. It even discloses concrete performance characteristics (~3-4s sector cut vs ~17s full universe) that an agent can use to plan calls.

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?

Front-loaded with the core purpose, then behavior, then mode routing, then filters, then perf — a sensible ordering with no filler. It is on the long side and the dedup semantics are restated in both prose and the parameter discussion, which is justified only because that is the tool's main failure mode.

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 still characterizes the result shape (one row per company, current_company_name when renamed, newest-first ordering, top_n cap). For a 7-parameter filtered screen with non-obvious dedup semantics, nothing an agent needs to call it correctly 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 coverage is 100%, so the baseline is 3, but the description goes further by explaining what dedup_mode='per_cik' actually computes (first-time IPO, earliest-ever filing), giving SIC prefix examples ('28' pharma, '60' banks), and restating the SPAC/SIC 6770 default. It does not add format or edge-case detail for since/until/top_n 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?

States a specific verb+resource (list recent IPOs) and pins the source of truth (424B4 final-pricing prospectuses) with coverage years. It actively distinguishes itself from related behaviors by contrasting the default first-time-IPO row model with per_accession follow-on rows and pointing to sections__get_filing for full filing histories.

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?

Explicit when-to-use routing: use dedup_mode='per_accession' only if you specifically want all offering filings, use sections__get_filing for a CIK's history, pass exclude_spac=false to include SPACs, and pair with sections__ipo_risk_factors for risk factors. It also gives narrowing advice (window/sector) tied to runtime, which is actionable usage guidance rather than generic description.

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

All Kaleidoscope MCP (SEC & financial data) 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?