API Ninjas

getIpoCalendar

Read-only

Returns a list of IPO records matching the supplied filters. With no parameters, returns IPOs with listing dates between today and 30 days from now. All parameters are optional; combine them to narrow results by ticker, CIK, date range, status, deal type, exchange, or industry.

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": "getIpoCalendar"
  }
}

Input Schema

Name	Required	Description	Default
`cik`	No	SEC Central Index Key, numeric only (padded or unpadded; e.g., 0001713445 or 1713445).
`date`	No	Single date in YYYY-MM-DD format. Cannot be combined with date_start or date_end.
`limit`	No	Maximum number of results to return. Must be between 1 and 1000 (inclusive). Default is 50.
`offset`	No	Number of results to skip for pagination. Must be a non-negative integer.
`status`	No	Comma-separated list of statuses to filter by. Values: filed, amended, priced, listed, withdrawn.
`ticker`	No	Company ticker symbol (e.g., RDDT). Returns IPO records for that specific company.
`date_end`	No	Range end in YYYY-MM-DD format. Defaults to today + 30 days.
`exchange`	No	U.S. exchange code.
`sic_code`	No	SEC Standard Industrial Classification code (up to 4 digits).
`deal_type`	No	Comma-separated list of deal types to filter by. Values: ipo, spac_ipo, direct_listing.
`date_field`	No	Which date the range filter applies to.	listing_date
`date_start`	No	Range start in YYYY-MM-DD format. Defaults to today. Free-tier users cannot query earlier than 24 months ago.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds genuine behavioral context beyond that: the default date window when no parameters are supplied. It does not cover pagination behavior or the free-tier restriction noted in the schema, but the default-window disclosure is meaningful added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences with the default-window behavior front-loaded and the filter overview second. No wasted words and the most actionable fact (default behavior) comes first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter all-optional list tool with full schema coverage and readOnlyHint annotations, the description covers purpose, default behavior, and filter dimensions adequately. The absence of an output schema is not a gap since a list-of-records return is self-evident, though return shape and pagination are not described.

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 all 12 parameters thoroughly. The description enumerates the filterable dimensions (ticker, CIK, date range, status, deal type, exchange, industry) but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 (returns) and resource (IPO records) with qualifying detail about filtering. It is clearly distinguishable from siblings like getEarningsCalendar and getShortInterestCalendar, though it does not name those siblings explicitly.

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?

Clearly explains the default behavior (no params returns IPOs listing today through +30 days) and tells the agent that all params are optional and combinable to narrow results. It gives good context for calling the tool but does not name when to prefer an alternative tool.

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

All API Ninjas 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?