IPO deal terms, SEC filings, AI research and sentiment, plus live valuation metrics for US stocks.
Scored across 8 tools
Most tools target distinct resources (financials vs. metrics, IPO events vs. profile), but the pairs get_ipo_overview/get_ipo_snapshot and get_ipo_sentiment/get_ipo_social_sentiment have similar names and overlapping purposes. Descriptions do separate them clearly by depth and scope.
All tools follow a consistent verb_noun snake_case pattern, nearly all using the get_ prefix. The lookup_companies_with_financials exception still uses a verb_noun structure, so the overall convention remains predictable.
Eight tools is a well-scoped surface for an IPO and company financial data server. Each tool covers a distinct data need without redundancy or bloat.
The server covers the core IPO lifecycle well: overview, full profile, financials, valuation metrics, dated events, and two sentiment angles. A missing general IPO/company search beyond the financials directory is a minor gap, but agents can still use events and identifiers.
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. 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.
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_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_dateMarket data, fundamentals, SEC filings, insider, 13F and congressional trades, and private markets.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
SEC filings, insider trades, and earnings data
Market data, financial statements, valuation, research, and news for investment workflows.
Add one secure layer between your agents and this server.
