iposignal

IPO events calendar (premium)

get_ipo_events

Read-only

Dated IPO events across all US IPOs in a window: lock-up expiries (with lock-up length), quiet-period expiries, and listings with offer price, first-day open and close, first-day pop and close return versus the offer, and lead managers. Use it to find upcoming lock-up expiries (supply overhang), quiet-period ends (analyst initiations) or how recent deals traded on day one. Arguments: from and to as YYYY-MM-DD (default today to today + 30 days, at most 366 days), types as a subset of lockup_expiry, quiet_period_expiry, listing (default all). PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and an empty window is never charged. Same data and price as the HTTP endpoint /api/agent/ipo-events.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Window end, YYYY-MM-DD, inclusive and at most 366 days after from. Defaults to from + 30 days.
`from`	No	Window start, YYYY-MM-DD (UTC date). Defaults to today.
`types`	No	Event types to include: lockup_expiry (with lock-up length), quiet_period_expiry, listing (with first-day pop, close return and lead managers). Defaults to all three.

Output Schema

TableJSON Schema

Name	Required	Description
`to`	No	Window end, YYYY-MM-DD, inclusive.
`from`	No	Window start, YYYY-MM-DD.
`count`	No	Events returned.
`types`	No	Event types included.
`events`	No	Events in date order.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 23, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "count": {
+      "description": "Events returned.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "events": {
+      "anyOf": [
+        {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "cik": {
+                "description": "SEC Central Index Key.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "company": {
+                "description": "Registrant name.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "date": {
+                "description": "YYYY-MM-DD.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "exchange": {
+                "description": "Listing exchange.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "listing": {
+                "anyOf": [
+                  {
+                    "additionalProperties": true,
+                    "properties": {},
+                    "type": "object"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "description": "Listing events only: offer price, first-day pop, close return, lead managers."
+              },
+              "lockupDays": {
+                "description": "Lock-up length in days (lockup_expiry only).",
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "symbol": {
+                "description": "Ticker.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "type": {
+                "description": "lockup_expiry, quiet_period_expiry or listing.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Events in date order."
+    },
+    "from": {
+      "description": "Window start, YYYY-MM-DD.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "to": {
+      "description": "Window end, YYYY-MM-DD, inclusive.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "types": {
+      "anyOf": [
+        {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Event types included."
+    }
+  },
+  "type": "object"
+}

AddedSep 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds valuable behavioral disclosure beyond annotations: the tool is premium and paid per call, an unpaid call returns payment terms, and an empty window is never charged. It also clarifies the window default and maximum duration. No contradiction with annotations.

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?

The description is well-structured: first sentence defines scope and content, second gives use cases, third summarizes arguments, fourth covers payment behavior. Every sentence contributes unique information with no filler, and key facts like the premium nature are clearly flagged.

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 an output schema present, return values don't need to be explained. The description covers what the tool returns (event types and fields), how to invoke it (arguments, defaults, limits), and important commercial behavior (paid per call, unpaid call behavior, empty-window charging). It is sufficiently complete for an agent to call it correctly.

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 input schema already documents from, to, and types with defaults and enum values. The description mostly restates this information, adding only a concise summary and the 366-day cap. Since the schema does the heavy lifting, baseline 3 is appropriate.

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 states a specific verb and resource: 'Dated IPO events across all US IPOs in a window' and enumerates the concrete event types (lock-up expiries, quiet-period expiries, listings) with their data fields. This clearly distinguishes it from sibling tools like get_ipo_overview or get_ipo_snapshot, which focus on different IPO aspects.

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?

It explicitly says when to use the tool: 'Use it to find upcoming lock-up expiries (supply overhang), quiet-period ends (analyst initiations) or how recent deals traded on day one.' This provides clear use-case context, though it does not name alternative tools or state when not to use it, stopping short of full exclusion guidance.

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

All iposignal 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.