IPO deal terms, SEC filings, AI research and sentiment, plus live valuation metrics for US stocks.
Scored across 10 tools
Most tools target distinct resources/actions, but there are a few confusable pairs: get_ipo_overview vs get_ipo_snapshot (free teaser vs premium full profile), get_company_financials vs get_company_metrics (statements/ratios vs valuation multiples), and get_ipo_sentiment vs get_ipo_social_sentiment (market-wide vs per-company X reading). The descriptions do a good job of drawing the lines (e.g. overview explicitly says 'before buying the full profile with get_ipo_snapshot'), so misselection risk is low but not zero.
Names are consistently snake_case and almost all use a get_ verb_noun pattern grouped by domain (get_ipo_*, get_company_*). The single lookup_companies_with_financials breaks the get_ prefix convention, a minor deviation.
Ten tools is well within the ideal 3-15 range for an IPO research data server, and each tool maps to a distinct data product (filings, pipeline, events, snapshot, financials, metrics, sentiment). No obvious redundancy or filler.
The surface covers the IPO lifecycle well: discovery (pipeline, overview, lookup directory), filings, deal terms (snapshot), events, financials, valuation, and both market and social sentiment. Minor gaps remain, e.g. no direct document retrieval (only links) and no peer-comparison/benchmark tool, but these are workable around.
Retrieve full SEC iXBRL financial statements for a company we cover, pre- and post-IPO, with derived margins, growth, leverage and return ratios per period. Interim periods carry annualized figures alongside the reported ones. Provide a symbol. PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and a not-found is never charged. Same data and price as the HTTP endpoint /api/agent/financials/by-symbol/{symbol}.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote. |
| Name | Required | Description |
|---|---|---|
| cik | No | SEC Central Index Key. |
| symbol | No | Ticker. |
| company | No | Registrant name. |
| fetchedAt | No | When the statements were last extracted from SEC. |
| symbolNote | No | Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served. |
| preIpoPeriods | No | Periods reported in the registration statement, before listing. |
| postIpoPeriods | No | Periods from 10-K/10-Q/20-F filings after listing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: premium payment per call, unpaid calls return payment terms, not-found is never charged, and interim periods carry annualized figures. It also mentions the symbolNote from the schema. It does not contradict annotations and adds useful details beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then details and payment. The structure is clear, but the mention of the HTTP endpoint adds a bit of extra info that could be considered non-essential, though it's relevant for parity. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. It covers the data scope, payment behavior, and symbol handling. It also notes the company coverage limitation. It could mention authentication requirements beyond payment, but payment is covered. It is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a thorough description of the symbol parameter, including case-insensitivity and the potential symbolNote. The description only repeats 'Provide a symbol,' adding no new meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (Retrieve), a resource (full SEC iXBRL financial statements), and gives scope details (pre- and post-IPO, derived margins, growth, leverage, return ratios). This distinguishes it from sibling tools like get_company_metrics (likely metrics-focused) and lookup_companies_with_financials (likely discovery-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: use this to retrieve financial statements for a given symbol. It also mentions the premium payment model, which is a key usage constraint. However, it does not explicitly compare to alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live valuation metrics for any US-listed company (not just IPOs), computed from primary sources: SEC XBRL companyfacts TTM fundamentals (revenue, net income, EBITDA, debt, cash, shares) plus the latest market close. Returns multiples (P/E, P/S, EV/Revenue, EV/EBITDA), derivations (PEG, earnings/sales/EBITDA yields, net-debt/EBITDA), margins, and YoY growth — the same data IPOSignal's valuation pipeline uses for peer benchmarking, with the computation convention stated in the response. Provide exactly one of symbol (any SEC-mapped ticker) or companyName (resolves Nasdaq/NYSE listings). PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and a not-found is never charged. Same data and price as the HTTP endpoint /api/agent/company-metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Any SEC-mapped US ticker, e.g. AAPL. Provide exactly one of symbol or companyName. | |
| companyName | No | Company name, used when the ticker is unknown. Resolves Nasdaq/NYSE listings only. |
| Name | Required | Description |
|---|---|---|
| listing | No | ticker, name, exchange, cik. |
| profile | No | Margins and YoY growth. |
| sources | No | Where each input came from. |
| valuation | No | marketCap, enterpriseValue, P/E, P/S, EV/Revenue, EV/EBITDA, PEG, yields, net-debt/EBITDA. |
| convention | No | How the figures were computed. |
| priceClose | No | Latest market close, USD. |
| fundamentalsTtm | No | Trailing-twelve-month revenue, net income, EBITDA, FCF, debt, cash, shares outstanding (and sharesSource), from SEC XBRL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description reveals meaningful behavioral details: data is computed from SEC XBRL companyfacts and the latest market close, the response includes the computation convention, and payment semantics are disclosed (paid per call, unpaid calls return payment terms, not-found is never charged). These details materially help an agent understand side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, data source, return content, parameter rule, pricing behavior, and HTTP equivalence. It is front-loaded with the core action and scope, then proceeds logically through outputs, usage, and operational details. There is no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values, and it covers source, computation, pricing, parameter constraints, and endpoint parity. It is slightly short on explicit sibling-tool selection guidance, such as when to prefer get_company_financials for raw statements, but the 'not just IPOs' contrast and the valuation-specific output list make the intended use clear. An agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters well. The description adds the critical 'exactly one of symbol or companyName' constraint, which the schema does not enforce, and clarifies that symbol covers any SEC-mapped ticker while companyName resolves Nasdaq/NYSE listings. This is meaningful semantic guidance beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get live valuation metrics for any US-listed company (not just IPOs)', which clearly states the verb, resource, and scope while distinguishing it from IPO-focused siblings. It further specifies the exact outputs (P/E, EV/Revenue, margins, growth, etc.), making it unambiguous what the tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when live valuation metrics for any US-listed company are needed, and explicitly says it is not limited to IPOs. It also explains the mutually exclusive input choice between symbol and companyName, the premium pricing behavior, and parity with the HTTP endpoint. It does not explicitly name sibling tools as alternatives or state when not to use it, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
FREE. One company's SEC filing timeline as we hold it, newest first: form type (S-1, S-1/A, F-1, F-1/A, EFFECT, 424B4, RW, 8-K, ...), filing date, and the link to the document on sec.gov. Use it to follow a registration from first S-1 through amendments to the final prospectus, or to confirm a withdrawal (RW). Covers the filings our SEC syncs collected for the company, not every filing it ever made. Provide exactly one of companyId, symbol, or cik.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042. | |
| symbol | No | US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote. | |
| companyId | No | IPOSignal company id (24-character hex), as returned by other IPOSignal responses. |
| Name | Required | Description |
|---|---|---|
| cik | No | SEC Central Index Key. |
| symbol | No | Ticker. |
| company | No | Registrant name. |
| filings | No | SEC filings we hold, newest first. |
| symbolNote | No | Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds value with the data-coverage caveat ('Covers the filings our SEC syncs collected for the company, not every filing it ever made'), the newest-first ordering, and the free-tier note. It omits pagination/row-limit behavior, which is the remaining unknown for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the most decision-relevant token ('FREE'), then scope, then usage, then the identifier rule. Efficient overall, though the enumeration of return fields partially duplicates the parameter/return schema and costs a little length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations cover safety, the schema covers all three parameters, and an output schema exists so return values needn't be restated. The description closes the remaining gaps (coverage limitation, exclusivity rule). Only pagination/limit behavior for potentially long filing timelines is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3. The description exceeds that by stating an exclusivity constraint the schema does not encode (zero required params, no oneOf), i.e. exactly one of companyId, symbol, or cik must be supplied. That prevents an invalid multi-identifier call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (one company's SEC filing timeline) plus the exact scope, ordering (newest first), and the form types returned (S-1, S-1/A, F-1, EFFECT, 424B4, RW, 8-K). This is clearly distinguishable from siblings like get_ipo_events or get_ipo_overview, which cover different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete use cases: follow a registration from first S-1 through amendments to the final prospectus, or confirm a withdrawal (RW). It also states the identifier rule ('Provide exactly one of companyId, symbol, or cik'). It does not name a sibling tool as an alternative for closely related questions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. The public facts of an IPO: company, ticker, CIK, exchange, listing date, shares offered, price range, final offer price when the deal has priced, and gross proceeds. Use it to identify a deal before buying the full profile with get_ipo_snapshot. Provide exactly one of companyId, symbol, or cik.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042. | |
| symbol | No | US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote. | |
| companyId | No | IPOSignal company id (24-character hex), as returned by other IPOSignal responses. |
| Name | Required | Description |
|---|---|---|
| cik | No | SEC Central Index Key, 10 digits. |
| venue | No | Listing exchange. |
| symbol | No | Ticker. |
| company | No | Registrant name. |
| premium | No | What get_ipo_snapshot adds. |
| ipoDetails | No | Public deal facts: date, exchange, shares offered, priceRange, offerPrice (final terms only), offerSize (gross proceeds). No valuation. |
| symbolNote | No | Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: the tool is FREE, returns only public facts, and notes that final offer price appears only 'when the deal has priced', which is a meaningful conditional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first presents the value and scope, the second gives the routing guidance, and the third states the parameter constraint. Every sentence earns its place and is front-loaded with the key 'FREE' signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, clear annotations, output schema, and explicit sibling differentiation, the description provides everything an agent needs to select and invoke the tool correctly. It covers cost, scope, alternatives, and input constraints without needing to restate return values that the output schema already documents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a solid description, so the baseline is 3. The description adds value beyond the schema by stating the exclusivity requirement ('exactly one of companyId, symbol, or cik'), which the schema does not enforce since no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: retrieving the public facts of an IPO, and enumerates the specific fields (company, ticker, CIK, exchange, listing date, shares, price range, final offer price, gross proceeds). It also distinguishes itself from get_ipo_snapshot by framing this as the free identification step before buying the full profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the usage context: use this tool to identify a deal before buying the full profile with get_ipo_snapshot. It also states the input constraint clearly ('Provide exactly one of companyId, symbol, or cik'), giving an agent actionable selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. The US IPO pipeline: operating companies that have filed with the SEC but are not trading yet (status upcoming), or deals that were withdrawn or postponed. Each row has company, ticker when assigned, CIK, exchange, expected trading date when one is scheduled, the date of the latest status change, price range, shares offered, Nasdaq's deal size, and a link to the latest SEC filing. Status is the one the iposignal.xyz calendar shows, so SPACs and other vehicles are excluded. Use it to see what is coming to market or what was pulled; follow up with get_ipo_filings for one company's filing history or get_ipo_snapshot for the full deal profile. Arguments: status (upcoming, withdrawn or postponed; default upcoming), since as YYYY-MM-DD for withdrawn/postponed (default one year ago), limit (default 100, max 500). Upcoming deals sort by expected date, undated last.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum deals to return, 1-500. Defaults to 100. | |
| since | No | Withdrawn/postponed only: earliest status date to include, YYYY-MM-DD. Defaults to one year ago. | |
| status | No | upcoming (filed, not trading yet), withdrawn, or postponed. Defaults to upcoming. | upcoming |
| Name | Required | Description |
|---|---|---|
| count | No | Deals returned. |
| deals | No | Deals: upcoming by expected date, others newest first. |
| since | No | For withdrawn/postponed: earliest status date included, YYYY-MM-DD. Null for upcoming. |
| status | No | upcoming, withdrawn or postponed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real value beyond them: the FREE tier, the exact status semantics tied to an external calendar, SPAC exclusion, and the sort order (expected date, undated last). Only auth/rate-limit behavior is unstated, which is minor for a free read-only listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads 'FREE' and the core scope, then fields, exclusions, follow-ups, and arguments in a logical order. Dense but each sentence carries information; the field enumeration is slightly long, though it substitutes for output-schema reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, exclusion rules, status values, defaults, sorting, and escalation paths, and an output schema already handles return structure. An agent has everything needed to call it correctly and interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 restating defaults (status=upcoming, since=one year ago, limit=100/max 500) and clarifying that since only applies to withdrawn/postponed. It also adds ordering behavior that the schema does not express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb/resource and scope: operating companies that filed with the SEC but aren't trading yet, plus withdrawn/postponed deals. It distinguishes itself from siblings by naming get_ipo_filings and get_ipo_snapshot as follow-ups, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('see what is coming to market or what was pulled') plus a clear exclusion (SPACs and other vehicles are excluded because it mirrors the iposignal.xyz calendar) and named alternatives for deeper dives. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Access IPOSignal's proprietary market sentiment score — a daily signal quantifying how well recent IPOs are being received by investors. Ranges from -100 (extreme bearish) to +100 (extreme bullish) with trend data for the last N days. Use it to identify favorable IPO windows, time investment entries, and assess overall market appetite for new listings. PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and a not-found is never charged. Same data and price as the HTTP endpoint /api/agent/ipo-sentiment.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Trend window in days, 1-90. Defaults to 14. |
| Name | Required | Description |
|---|---|---|
| trend | No | Daily readings, newest first. |
| current | No | Latest daily reading. |
| summary | No | One-line reading of level and direction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the premium payment model (paid per call over x402), the unpaid call behavior (returns payment terms), and the not-found never being charged. It also mentions the data is the same as the HTTP endpoint. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the core purpose. It includes important usage context and payment terms. The sentence about premium payment is a bit long but necessary. Overall, every sentence earns its place, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter set (1 optional param), an output schema exists, and annotations cover safety. The description covers the key behavioral aspects: premium pricing, unpaid call behavior, and the HTTP endpoint equivalence. It's complete enough for an agent to call correctly, though it doesn't describe the output structure in detail (but the output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the 'days' parameter with its range and default. The description mentions 'trend data for the last N days' which aligns with the parameter, but doesn't add much beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: accessing IPOSignal's proprietary market sentiment score, a daily signal quantifying how well recent IPOs are received. It specifies the range (-100 to +100), trend data, and use cases. It distinguishes itself from siblings by focusing on market sentiment, not company financials or IPO events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: identify favorable IPO windows, time investment entries, and assess overall market appetite. It also mentions the premium payment model and the HTTP endpoint alternative. However, it doesn't explicitly state when to use this over get_ipo_social_sentiment, which is a sibling that might seem similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a complete IPO company profile — deal terms, pricing range, expected market cap, SEC registration and prospectus details, offering structure, lifecycle timeline, and IBKR indicative borrow fee rate when available. When available, includes AI-generated research with valuation models, competitor benchmarking, underwriter ratings, board analysis, and risk factors. Provide exactly one of companyId, symbol, or cik. PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and a not-found is never charged. Same data and price as the HTTP endpoint /api/agent/ipo/{id} or /api/agent/ipo/by-symbol/{symbol}.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042. | |
| symbol | No | US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote. | |
| companyId | No | IPOSignal company id (24-character hex), as returned by other IPOSignal responses. |
| Name | Required | Description |
|---|---|---|
| cik | No | SEC Central Index Key, 10 digits. |
| sec | No | SEC company data. |
| venue | No | Listing exchange. |
| symbol | No | Ticker. |
| company | No | Registrant name. |
| offering | No | Offering structure from the prospectus; termsAreFinal is true only for a final 424B* prospectus. |
| research | No | AI-generated research: valuation models, competitors, underwriters, board, risks. Figures are sourced from filings. |
| borrowFee | No | Latest IBKR indicative borrow fee (annualized %), when available. |
| updatedAt | No | ISO timestamp of the last update to this record. |
| ipoDetails | No | Deal facts: date, exchange, shares offered, priceRange, offerPrice (final terms only), marketCap (post-IPO economic shares × offer price), offerSize (gross proceeds), and the source of each. |
| symbolNote | No | Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served. |
| registration | No | SEC registration statement: form type and filing URL. |
| freedom24News | No | Freedom24 articles about the deal. |
| lifecycleEvents | No | Dated status history: filed, priced, listed, withdrawn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already establish that this is a safe read operation, and the description adds meaningful behavioral context beyond that: it is a premium paid-per-call tool, unpaid calls return payment terms, not-found lookups are never charged, and it maps to specific HTTP endpoints. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the purpose and main content areas before moving to identifier rules and payment terms. The list of profile contents is long, but each item adds meaningful selection-relevant information, and the payment section is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the data surface is broad, the presence of an output schema reduces the need to describe return values. The description covers identifier constraints, premium pricing behavior, endpoint equivalence, and the conditional availability of research fields, making the tool reasonably complete for an agent to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all three parameters fully, giving formats, examples, and the symbolNote caveat. The description adds the material constraint that exactly one of companyId, symbol, or cik must be supplied, which is not reflected in the schema's required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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, 'Retrieve a complete IPO company profile', and enumerates concrete content areas: deal terms, pricing range, prospectus details, lifecycle timeline, and borrow fee. It implicitly distinguishes itself from sibling tools by positioning itself as the comprehensive snapshot rather than a focused events, sentiment, or financials tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides invocation guidance, 'Provide exactly one of companyId, symbol, or cik', but gives no guidance about when to choose this tool over get_ipo_overview, get_ipo_events, or get_company_financials. No alternative or exclusion criteria is mentioned, so the agent is left to infer routing decisions from the description and sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get IPOSignal's X/Twitter social-sentiment reading for a specific IPO — an aggregate of how investors are discussing the stock on X, scored from -1 (bearish) to +1 (bullish) with a label, post tallies, and a one-line summary. The reading is taken once, before listing, and not refreshed: ageDays says how old it is and reliable is false when too few posts back it. Returns the aggregate signal only, not the underlying posts. Provide exactly one of companyId, symbol, or cik. PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and a not-found is never charged. Same data and price as the HTTP endpoint /api/agent/social-sentiment.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042. | |
| symbol | No | US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote. | |
| companyId | No | IPOSignal company id (24-character hex), as returned by other IPOSignal responses. |
| Name | Required | Description |
|---|---|---|
| label | No | Bullish, Neutral or Bearish. |
| score | No | -1 (bearish) to +1 (bullish). |
| symbol | No | Ticker. |
| ageDays | No | Days since the reading. Readings are taken before listing and not refreshed. |
| company | No | Registrant name. |
| summary | No | One-line summary. |
| reliable | No | False when too few posts back the reading. |
| postCount | No | Posts the reading is based on. |
| analyzedAt | No | ISO timestamp of the reading. |
| symbolNote | No | Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served. |
| negativeHits | No | Posts scored negative. |
| positiveHits | No | Posts scored positive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the reading is a static snapshot taken before listing and not refreshed, ageDays indicates age, reliable is false with insufficient posts, and it returns only the aggregate signal, not underlying posts. It also explains unpaid call behavior and that not-found is never charged. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by data specifics, usage constraint, and premium details. Every sentence contributes useful information without redundancy. It is longer than minimal but each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return fields, but it still clarifies key aspects like the aggregate nature, ageDays and reliable fields, and the premium payment behavior. It provides enough for an agent to call the tool correctly, though it doesn't address alternative tool selection, which is covered under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (100% coverage). The description adds the critical constraint that exactly one of companyId, symbol, or cik must be provided, which is not enforced by the schema (required parameters: 0). It also mentions that symbol may carry a symbolNote, which is already in the schema but is reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an X/Twitter social-sentiment reading for a specific IPO, with specifics about scoring, label, post tallies, and summary. It is specific about the resource and the aggregate nature, but it does not explicitly differentiate itself from the sibling get_ipo_sentiment tool, so it doesn't fully meet the 'distinguishes from siblings' bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage instruction that exactly one of companyId, symbol, or cik must be provided, and it notes the premium per-call cost, implying use only when sentiment data is needed. However, it does not mention when to prefer this over the sibling get_ipo_sentiment tool or when to avoid it, so guidance on alternatives is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Directory of companies we hold SEC iXBRL financial statements for, optionally filtered by ticker or company name. Returns ticker, company, CIK, latest reported period and pre/post-IPO period counts — use it to find which tickers get_company_financials can return. Paged: limit (default 200, max 500) and offset; the response carries total and nextOffset (null on the last page).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1-500. Defaults to 200. | |
| query | No | Filter by ticker or company name (case-insensitive substring). Omit to list every covered company. | |
| offset | No | Rows to skip. Pass the previous response's nextOffset to fetch the next page. |
| Name | Required | Description |
|---|---|---|
| data | No | Companies we hold SEC iXBRL financials for. |
| count | No | Rows in this page. |
| limit | No | Page size. |
| total | No | Rows matching the query across all pages. |
| offset | No | Rows skipped. |
| nextOffset | No | Offset of the next page, or null on the last page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds non-redundant behavioral context: 'FREE', pagination mechanics with limit/offset, and that the response carries total and nextOffset (null on the last page). This gives the agent confidence in paging and cost expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler. The front-loading is excellent: 'FREE' and the core purpose come first, followed by return fields and the sibling routing, then pagination details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only directory lookup with all parameters optional, complete schema descriptions, and an output schema present, the description fully covers what an agent needs to call it correctly. It explains the return fields, filtering, paging, and the relationship to get_company_financials. There are no notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described in detail (limit defaults, offset semantics, query case-insensitive substring). The description does not add new meaning beyond the schema; it mostly restates the pagination pattern that the offset schema already documents ('Pass the previous response's nextOffset...'). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Directory of companies we hold SEC iXBRL financial statements for...' and enumerates the exact return fields. It also distinguishes itself from the sibling get_company_financials by explaining it is the discovery tool for which tickers are available. This is exactly what an agent needs to differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says, 'use it to find which tickers get_company_financials can return,' giving a direct when-to-use instruction tied to a named alternative. This is clear routing with no ambiguity about when to invoke this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_ipo_filingsget_ipo_pipelineget_company_financials1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "cik": {
+ "description": "SEC Central Index Key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "company": {
+ "description": "Registrant name.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetchedAt": {
+ "description": "When the statements were last extracted from SEC.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "postIpoPeriods": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/properties/preIpoPeriods/anyOf/0/items"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Periods from 10-K/10-Q/20-F filings after listing."
+ },
+ "preIpoPeriods": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "annualizedMetrics": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Interim periods only: flow items annualized to 12 months."
+ },
+ "currency": {
+ "description": "Reporting currency.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "derived": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Computed ratios: margins, growth, leverage, returns."
+ },
+ "durationMonths": {
+ "description": "Length of the period in months.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fxToUsd": {
+ "description": "Multiply by this to convert to USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "metrics": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Tagged line items as reported (revenue, net income, cash, debt, ...)."
+ },
+ "periodEndDate": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periodStartDate": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periodType": {
+ "description": "Annual or interim, as filed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Periods reported in the registration statement, before listing."
+ },
+ "symbol": {
+ "description": "Ticker.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbolNote": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served."
+ }
+ },
+ "type": "object"
+}get_company_metrics1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "convention": {
+ "description": "How the figures were computed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fundamentalsTtm": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Trailing-twelve-month revenue, net income, EBITDA, FCF, debt, cash, shares outstanding (and sharesSource), from SEC XBRL."
+ },
+ "listing": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "ticker, name, exchange, cik."
+ },
+ "priceClose": {
+ "description": "Latest market close, USD.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "profile": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Margins and YoY growth."
+ },
+ "sources": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Where each input came from."
+ },
+ "valuation": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "marketCap, enterpriseValue, P/E, P/S, EV/Revenue, EV/EBITDA, PEG, yields, net-debt/EBITDA."
+ }
+ },
+ "type": "object"
+}get_ipo_events1 field 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"
+}get_ipo_overview1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "cik": {
+ "description": "SEC Central Index Key, 10 digits.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "company": {
+ "description": "Registrant name.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ipoDetails": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Public deal facts: date, exchange, shares offered, priceRange, offerPrice (final terms only), offerSize (gross proceeds). No valuation."
+ },
+ "premium": {
+ "description": "What get_ipo_snapshot adds.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "description": "Ticker.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbolNote": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served."
+ },
+ "venue": {
+ "description": "Listing exchange.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}get_ipo_sentiment1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "current": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "computedAt": {
+ "description": "ISO timestamp.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "date": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "direction": {
+ "description": "bullish, bearish or neutral.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reliable": {
+ "description": "False when the sample is too small to trust.",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "sampleSize": {
+ "description": "IPOs the score is computed from.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "description": "-100 (extreme bearish) to +100 (extreme bullish).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "strength": {
+ "description": "weak, moderate or strong.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Latest daily reading."
+ },
+ "summary": {
+ "description": "One-line reading of level and direction.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trend": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/properties/current/anyOf/0"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Daily readings, newest first."
+ }
+ },
+ "type": "object"
+}get_ipo_snapshot1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "borrowFee": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Latest IBKR indicative borrow fee (annualized %), when available."
+ },
+ "cik": {
+ "description": "SEC Central Index Key, 10 digits.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "company": {
+ "description": "Registrant name.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "freedom24News": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Freedom24 articles about the deal."
+ },
+ "ipoDetails": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Deal facts: date, exchange, shares offered, priceRange, offerPrice (final terms only), marketCap (post-IPO economic shares × offer price), offerSize (gross proceeds), and the source of each."
+ },
+ "lifecycleEvents": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Dated status history: filed, priced, listed, withdrawn."
+ },
+ "offering": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Offering structure from the prospectus; termsAreFinal is true only for a final 424B* prospectus."
+ },
+ "registration": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "SEC registration statement: form type and filing URL."
+ },
+ "research": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "AI-generated research: valuation models, competitors, underwriters, board, risks. Figures are sourced from filings."
+ },
+ "sec": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "SEC company data."
+ },
+ "symbol": {
+ "description": "Ticker.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbolNote": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served."
+ },
+ "updatedAt": {
+ "description": "ISO timestamp of the last update to this record.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "venue": {
+ "description": "Listing exchange.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}get_ipo_social_sentiment1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "ageDays": {
+ "description": "Days since the reading. Readings are taken before listing and not refreshed.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "analyzedAt": {
+ "description": "ISO timestamp of the reading.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "company": {
+ "description": "Registrant name.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "label": {
+ "description": "Bullish, Neutral or Bearish.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "negativeHits": {
+ "description": "Posts scored negative.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "positiveHits": {
+ "description": "Posts scored positive.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "postCount": {
+ "description": "Posts the reading is based on.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "reliable": {
+ "description": "False when too few posts back the reading.",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "score": {
+ "description": "-1 (bearish) to +1 (bullish).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "summary": {
+ "description": "One-line summary.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbol": {
+ "description": "Ticker.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "symbolNote": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served."
+ }
+ },
+ "type": "object"
+}lookup_companies_with_financials1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "description": "Rows in this page.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "data": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "cik": {
+ "description": "SEC Central Index Key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "company": {
+ "description": "Registrant name.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latestPeriodEnd": {
+ "description": "End date of the latest reported period, YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "postIpoCount": {
+ "description": "Reporting periods after the IPO.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "preIpoCount": {
+ "description": "Reporting periods before the IPO.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "symbol": {
+ "description": "Ticker.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Companies we hold SEC iXBRL financials for."
+ },
+ "limit": {
+ "description": "Page size.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "nextOffset": {
+ "description": "Offset of the next page, or null on the last page.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "offset": {
+ "description": "Rows skipped.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total": {
+ "description": "Rows matching the query across all pages.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}get_ipo_eventsget_company_financials1 field changedInput schema / properties / symbol / descriptionAdded value: +"US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote."get_company_metrics2 fields changedInput schema / properties / companyName / descriptionAdded value: +"Company name, used when the ticker is unknown. Resolves Nasdaq/NYSE listings only."Input schema / properties / symbol / descriptionAdded value: +"Any SEC-mapped US ticker, e.g. AAPL. Provide exactly one of symbol or companyName."get_ipo_overview3 fields changedInput schema / properties / cik / descriptionAdded value: +"SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042."Input schema / properties / companyId / descriptionAdded value: +"IPOSignal company id (24-character hex), as returned by other IPOSignal responses."Input schema / properties / symbol / descriptionAdded value: +"US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote."get_ipo_sentiment1 field changedInput schema / properties / days / descriptionAdded value: +"Trend window in days, 1-90. Defaults to 14."get_ipo_snapshot3 fields changedInput schema / properties / cik / descriptionAdded value: +"SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042."Input schema / properties / companyId / descriptionAdded value: +"IPOSignal company id (24-character hex), as returned by other IPOSignal responses."Input schema / properties / symbol / descriptionAdded value: +"US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote."get_ipo_social_sentiment3 fields changedInput schema / properties / cik / descriptionAdded value: +"SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042."Input schema / properties / companyId / descriptionAdded value: +"IPOSignal company id (24-character hex), as returned by other IPOSignal responses."Input schema / properties / symbol / descriptionAdded value: +"US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote."lookup_companies_with_financials3 fields changedInput schema / properties / limit / descriptionAdded value: +"Page size, 1-500. Defaults to 200."Input schema / properties / offset / descriptionAdded value: +"Rows to skip. Pass the previous response's nextOffset to fetch the next page."Input schema / properties / query / descriptionAdded value: +"Filter by ticker or company name (case-insensitive substring). Omit to list every covered company."lookup_companies_with_financials2 fields changedInput schema / properties / limitAdded value: +{
+ "default": 200,
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "minimum": 0,
+ "type": "integer"
+}get_ipo_overviewlookup_companies_with_financialsget_company_financialsget_company_metricsbatch_update_ipo_datesfind_ipos_missing_dateget_ipo_social_sentimentlookup_ipo_datebatch_update_ipo_datesfind_ipos_missing_dateget_ipo_sentimentget_ipo_snapshotlookup_ipo_dateSEC filings, company financials, holdings, earnings calls, stock prices, options and macro data.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
Value investing for US stocks: SEC filings, 13F guru holdings, intrinsic value, AI briefings.
SEC filings, insider trades, and earnings data
Add one secure layer between your agents and this server.
