US insider trades, 13F, 13D/G, Form 144, politician trades, financials and short interest. Free.
Scored across 19 tools
Most tools target clearly distinct resources or actions (stock overview, financials, insider trades, institutional holdings, short interest, politicians). A few domain pairs overlap—get_insider_trades vs. get_insider_lists, get_ownership_filings vs. get_major_holders, and get_institution vs. get_stock_13f_holders—but the detailed descriptions clearly separate their purposes, so misselection is unlikely.
All tool names use snake_case with a predictable verb_noun pattern (get_, list_, screen_, search). The semantic distinction between get_ for entity-specific retrieval and list_ for market-wide ranked lists is consistently maintained, with no mixing of conventions.
19 tools is on the higher side, but the server covers a very broad domain: financial statements, filings, insider trades, institutional holdings, superinvestors, politicians, short interest, screening, and search. Each tool has a distinct role, though a few could conceivably be consolidated with mode parameters.
The surface is broad and includes search plus a dedicated data-coverage tool, covering most ownership, insider, political, short-interest, and financial-statement workflows. A minor gap is the lack of a tool to retrieve filing text or full 13D/G content, which requires fetching SEC URLs externally; niche datasets like proxy statements or ETF holdings are also absent.
What data Livermore has and how fresh it is: the Form 4 filing-date range, the 13F quarters loaded (with the number of filers), the latest complete 13F quarter, the number of curated superinvestors, the Schedule 13D, 13G and Form 144 filing-date ranges, the filing-date range of politicians' trade reports (the congress field: reports by members of the U.S. Congress), the date ranges of company filings (10-K, 10-Q, 8-K), FINRA short interest, daily short volume, weekly ATS volume and SEC fails-to-deliver, the number of companies with financial statements, and the number of companies with a market cap with the newest close date used (market_caps); each of these is null until loaded and has its own last_updated. Also the last successful data updates (ISO 8601 UTC), the update schedule and the usage limits of this server. Call it to check whether a date or quarter is covered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| f13 | Yes | |
| form4 | Yes | |
| limits | Yes | |
| filings | Yes | |
| sources | Yes | |
| website | Yes | |
| congress | Yes | |
| docs_url | Yes | |
| ownership | Yes | |
| ats_weekly | Yes | |
| financials | Yes | |
| market_caps | Yes | |
| llms_txt_url | Yes | |
| short_volume | Yes | |
| short_interest | Yes | |
| superinvestors | Yes | |
| update_schedule | Yes | |
| fails_to_deliver | Yes | |
| last_successful_update | Yes |
Financial statements of one company from the XBRL data in its 10-K, 10-Q, 20-F and 40-F filings (SEC companyfacts), newest period first: income statement (revenue, cost_of_revenue, gross_profit, operating_expenses, rd_expense, sga_expense, operating_income, interest_expense, tax_expense, net_income, eps_basic, eps_diluted, shares_basic, shares_diluted), balance sheet (cash_and_equivalents ... total_assets, total_liabilities, total_equity including minority interest), cash flow (operating_cash_flow, capex, free_cash_flow = operating cash flow minus capex, dividends_paid, share_buybacks, ..., depreciation_amortization, stock_based_compensation) and the cover-page shares outstanding (shares, with change_1y_pct). period=annual gives fiscal years (FY), quarterly gives single fiscal quarters (Q1-Q4). IMPORTANT: amounts are in the company's reporting currency (currency, for example TWD for TSMC), not US dollars; for other currencies usd_rate gives US dollars per unit: multiply income statement and cash flow amounts by usd_rate.average and balance sheet amounts by usd_rate.period_end. EPS is in that currency per share. Each period has its filing (form, filed_date, accession, sec_url), reported_date (the earnings 8-K, Item 2.02), margins (gross, operating and net margin, stock-based compensation as a percent of revenue) and yoy_pct (growth against the same fiscal period a year earlier). Numbers are as filed in each period's original report or its amendment. Known gaps: foreign companies (20-F, 40-F) have annual statements only; EPS and share counts are not adjusted for stock splits (stock_splits lists the splits in the range); for ADRs EPS is per ordinary share, not per ADS; Q4 and single-quarter cash flows are mostly derived by subtraction (listed in derived); banks' revenue may be interest income only; companies with several share classes may have no EPS or cover-page share count. note explains what applies to this company, including why there are no statements (ETFs and funds have none). No stock prices are returned and no valuation ratios are computed; get_stock has the company's market cap in USD (convert foreign-currency statements with usd_rate before comparing).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of periods, newest first: default 5 for annual, 8 for quarterly, at most 40. | |
| period | No | annual = fiscal years (default); quarterly = single fiscal quarters. | annual |
| ticker | Yes | Stock ticker, e.g. AAPL or BRK.B (share classes use a dot; BRK-B also works). | |
| statements | No | Which parts to return: income, balance, cash_flow, shares (cover-page shares outstanding). Default all, e.g. ["income"]. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| period | Yes | |
| company | Yes | |
| periods | Yes | |
| coverage | Yes | |
| currency | Yes | Reporting currency of the latest period (ISO 4217). Amounts are in this currency, not USD. |
| statements | Yes | |
| stock_splits | Yes | |
| shares_outstanding | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations (readOnly/idempotent/non-destructive/closed-world): it discloses non-USD reporting currency and the usd_rate.average vs period_end conversion rules, filing/amendment provenance, Q4/single-quarter cash flows being derived by subtraction, unadjusted split/EPS caveats, ADR per-ordinary-share EPS, bank revenue caveats, multi-class share gaps, and the meaning of `note`.
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 and information-dense, but the long parenthetical enumerations of individual line items (many with ellipses) are heavy and partially redundant given an output schema exists. A tighter description could carry the same semantic load with less bulk.
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 complex, quirky data tool the description covers the gaps that matter: currency conversion, derived periods, split/ADR/bank/multi-class exceptions, amendments, and when no statements exist. Since an output schema exists, return-value shape needn't be re-explained, and nothing an agent needs to interpret results is missing.
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 adds real meaning: it spells out that period=annual yields fiscal years and quarterly yields single fiscal quarters, what each `statements` value contains, and the currency semantics that govern how returned values must be interpreted.
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+scope: financial statements of one company sourced from XBRL in 10-K/10-Q/20-F/40-F SEC companyfacts. It names the concrete sections (income, balance, cash flow, shares) and explicitly distinguishes itself from get_stock for prices/valuation, so an agent can identify it without opening the schema.
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 clear operating context: period=annual vs quarterly semantics, statements selection, and explicitly routes the agent elsewhere for market cap ('get_stock has the company's market cap in USD'). It stops short of explicit when-not-to-use-it exclusions beyond the note about ETFs/funds having no statements, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Form 144 notices of proposed sales of restricted or control stock by insiders (officers, directors, large holders), newest first, like livermore.club/en/ownership/144. A notice is a plan to sell, not a completed sale. Notices replaced by a Form 144/A are left out. Filter by ticker (one company's whole history), seller_cik, query (seller or company name, or a ticker) and filing dates. Without ticker or seller_cik the query is market-wide and limited to 365 days of filings (default: the last 30 days), and notices whose market value is clearly misreported are left out, as on the website; with ticker or seller_cik they are listed with value_outlier true. A notice is flagged when the price per share its market value implies is far above the company's reference prices from Form 4 trades and 13F holdings around the planned sale date; values that are too low are not flagged. Each row has the company, the seller and their relationships to it, shares_to_sell, market_value_usd, shares_outstanding, approx_sale_date, plan_adoption_date (a Rule 10b5-1 plan, when given), the broker, and links to livermore.club and the SEC filing. Coverage: XML notices since 2023 (required since 2023-04-13); call get_data_coverage for the loaded date range. At most 200 rows per call; use page for more.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest filing date, YYYY-MM-DD, inclusive. | |
| from | No | Earliest filing date, YYYY-MM-DD (US Eastern). | |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| limit | No | Maximum rows to return (1-200, default 25). | |
| query | No | Seller or company name contains this text, or a ticker for that company's notices (like the search box on livermore.club/en/ownership/144). | |
| ticker | No | Only notices for this company (all share classes; Form 144 has no CUSIP), whole history. | |
| seller_cik | No | Only notices by this seller, whole history. Sellers use the same CIK as their Form 4 filings. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| limit | Yes | |
| scope | Yes | |
| stock | Yes | |
| seller | Yes | |
| filters | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, but the description adds substantial behavior: value_outlier suppression and flagging logic, which notices are excluded (superseded by Form 144/A), the 200-row pagination cap, and the XML coverage start date. This is far beyond what annotations provide.
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?
Dense but front-loaded: purpose first, then exclusion rules, then flagging rationale, then filter behavior, then row shape and limits. It is long, but nearly every clause carries operational information; only the intermediate flagging-mechanism detail could be trimmed.
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 an output schema exists, the description needn't enumerate return values, yet it does helpfully list row fields, plus pagination, coverage caveats, and filtering edge cases. Nothing an agent needs to call this correctly is missing.
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 meaningfully augments it – 'whole history' semantics for ticker/seller_cik, the query matching seller or company name, and the market-wide 365-day/default-30-day behavior tied to date params. These add semantics the schema does not.
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 (Form 144 notices of proposed sales of restricted/control stock by insiders) with a clear scope and ordering ('newest first'). It also distinguishes the concept semantically from completed trades ('a notice is a plan to sell, not a completed sale') which separates it from siblings like get_insider_trades.
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 describes when to use ticker vs seller_cik vs query vs bare date filtering, and what happens in each case (whole history vs market-wide, 365-day cap, default 30 days). It also routes to get_data_coverage for the loaded range, naming an alternative for coverage questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ready-made insider trading screens, the same lists as livermore.club/en/insiders: cluster-buys (companies where 3 or more different insiders bought on the open market in the last 30 days, ranked by total value; returned in companies), ceo-cfo-buys (CEO or CFO open-market purchases of $25,000 or more in 30 days, newest first), top-buys-week and top-buys-month (largest open-market purchases filed in the last 7 or 30 days), top-sells-week and top-sells-month (largest open-market sales). Windows count back from now by SEC filing time. Non-derivative transactions only; rows flagged as price outliers, duplicate filings (the same trade reported again in a later filing) and issuers without a ticker are excluded. Trade rows have the same fields as get_insider_trades. Amounts in USD. At most 200 rows.
| Name | Required | Description | Default |
|---|---|---|---|
| list | Yes | cluster-buys, ceo-cfo-buys, top-buys-week, top-buys-month, top-sells-week or top-sells-month. | |
| limit | No | Maximum rows to return (1-200, default 25). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| list | Yes | |
| title | Yes | |
| trades | Yes | |
| companies | Yes | |
| definition | Yes | |
| window_days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds substantial behavioral context: non-derivative transactions only, exclusion of outlier rows, duplicate filings and issuers without tickers, SEC filing-time windows, USD amounts, and a 200-row cap. This is well beyond what the structured annotations provide.
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: it opens with the overall purpose, then defines each list, then covers exclusions, shared fields, currency, and row limits. Every sentence carries specific information, and none appears to be filler.
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 screen-listing tool with a full output schema and strong annotations, the description provides everything needed: list semantics, filtering rules, data currency, row limit, and field compatibility with get_insider_trades. Return-value details are appropriately left to the output schema.
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, making the baseline 3. The description meaningfully adds to the `list` parameter by defining each enum value's exact criteria and ranking, though it adds little beyond the schema for `limit` aside from restating the 200-row maximum.
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 names a specific resource (insider trading screens) and enumerates all six ready-made lists with their ranking criteria. It also distinguishes itself from the sibling get_insider_trades by stating that trade rows share the same fields, so an agent can tell it apart without opening either schema.
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 clearly explains what each screen represents and when those lists are useful, e.g., cluster-buys means 3+ insiders bought in 30 days. However, it does not explicitly state when to prefer this tool over get_insider_trades or other siblings, nor does it name exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insider transactions from SEC Form 4 filings (coverage starts July 2021; updated daily). One row per filing and transaction type: same-day lots are combined, avg_price_usd is value-weighted, value_usd is the USD total, shares_owned_after is the holding after the last lot, ownership_change_pct is the change in the insider's holding in percent (null = new position or not computable). Filter by ticker, insider_cik, filing-date range, codes, the primary insider's role and minimum value. Without ticker or insider_cik the query is market-wide and limited to 30 days of filings (default: last 7 days). Codes: P = open-market or private purchase, S = sale, A = grant or award, D = disposition to the issuer, F = shares withheld for taxes, G = gift, M = option exercise under a company plan, X = in-the-money exercise, C = conversion, W = inheritance, J = other. Default codes P and S. Dates are YYYY-MM-DD; filed_at is ISO 8601 UTC and filed_date its US Eastern date; backfilled filings may only have the date (filed_at at midnight Eastern). price_outlier is true when the reported price or value is not reliable (a typo, a wrong unit or a foreign company's home-market shares priced in local currency instead of US dollars); avg_price_usd and value_usd are then as filed, and the site leaves these rows out of rankings and totals. carried_from is set on rows that a Form 4/A carried over from the original filing: an amendment that restates only some lines leaves the original's other transactions standing, so they are listed under the amendment's accession (amendment true), with the original's accession in carried_from and the original's filed_at and sec_url; it is null otherwise. rule_10b5_1 is null for filings before 2023. Each row links to livermore.club (url) and the SEC filing that reports the transaction (sec_url). At most 200 rows per call; use page for more.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest SEC filing date, YYYY-MM-DD, inclusive. | |
| from | No | Earliest SEC filing date, YYYY-MM-DD (US Eastern). | |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| sort | No | filed = newest filing first (default); trade_date = most recent trade date first; value = largest USD value first (rows flagged as price outliers or duplicate filings are left out). | filed |
| codes | No | Form 4 transaction codes to include, e.g. ["P"] for purchases only, or "all". Default ["P","S"] (open-market purchases and sales). | |
| limit | No | Maximum rows to return (1-200, default 25). | |
| roles | No | Keep rows whose primary reporting owner has any of these roles: ceo, cfo, director, officer, owner10 (10% owner). Empty = any role. | |
| ticker | No | Only this company's filings (all share classes of the issuer), e.g. AAPL or BRK.B. | |
| insider_cik | No | Only filings on which this insider (reporting owner) appears, across all companies. Get the CIK from search. | |
| min_value_usd | No | Minimum transaction value in USD (rows without a price are then excluded). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| limit | Yes | |
| scope | Yes | |
| stock | Yes | |
| filters | Yes | |
| insider | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent read, so the bar is lower, yet the description adds substantial behavioral context: daily updates, 200-row cap with pagination via page, price_outlier rows excluded from rankings/totals, carried_from semantics for Form 4/A amendments, and rule_10b5_1 null before 2023. These are non-obvious traits an agent could not infer from the schema.
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 core purpose and a dense but largely waste-free paragraph; nearly every sentence carries field semantics or a constraint. It would be more scannable with structure, and the back-half semantics (carried_from, price_outlier) could be tightened, but there is little filler.
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 explain return shapes, yet it still covers row granularity, aggregation rules, date formats, null conditions, and pagination limits. For a 10-parameter tool with zero required params, this is fully sufficient 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 a baseline of 3 applies, but the description goes further by enumerating the meaning of each transaction code (P, S, A, D, F, G, M, X, C, W, J) and restating the default codes P and S, which the schema only lists as values. It also clarifies that 'without ticker or insider_cik' triggers a 30-day market-wide limit, adding conditional meaning to those params.
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 and resource ('Insider transactions from SEC Form 4 filings') and immediately scopes it with coverage start and update cadence. It is easily separable from siblings like get_insider_lists and get_superinvestor_activity, 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 clear usage context: 'Filter by ticker, insider_cik, filing-date range, codes, the primary insider's role and minimum value,' and explains that omitting ticker/insider_cik yields a market-wide query capped at 30 days, defaulting to the last 7. However, it never names or routes to an alternative sibling tool, so it falls short of explicit when-to-use-vs-alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One 13F filer (an institution or a curated superinvestor) by SEC CIK: names (and the superinvestor's manager and style), the quarters it filed (newest 12, with quarters_total: number of positions, portfolio value in USD, filing time, amendments), and its holdings for one quarter (default: the latest it filed) with shares, market value in USD at quarter end, pct_of_portfolio (percent) and the change versus the previous calendar quarter (new/added/reduced/unchanged, share_change_pct in percent). When a stock split between the two quarters, previous_shares is converted to this quarter's shares before comparing (split_factor = new shares per old share) and a change within 0.5% counts as unchanged; a split that changed the CUSIP is shown as one row under the new CUSIP. Also returns the 10 largest positions sold out that quarter and the 10 largest option positions (put/call market value), each with its total count. Portfolio value counts long positions and excludes options. If the institution did not file the previous quarter, changes and sold-out positions are not reported. Securities without a ticker (bonds, some ETFs and foreign shares) have url null. At most 200 holdings per call; use page.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | SEC CIK of the 13F filer, e.g. 0001067983 (Berkshire Hathaway). Get it from search. | |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| sort | No | value = largest market value first (default); shares; change = largest share increase first; pct = largest share of the portfolio first. | value |
| limit | No | Maximum rows to return (1-200, default 25). | |
| quarter | No | Quarter to show, e.g. 2026-q2. Default: the latest quarter this institution filed. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| period | Yes | |
| options | Yes | |
| quarter | Yes | |
| summary | Yes | |
| holdings | Yes | |
| quarters | Yes | |
| sold_out | Yes | |
| institution | Yes | |
| quarters_total | Yes | |
| previous_quarter | Yes | |
| changes_available | Yes | |
| previous_quarter_filed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial non-obvious behavior: split handling with split_factor and CUSIP changes, the 0.5% unchanged threshold, a 200-holding cap requiring pagination, exclusion of options from portfolio value, null url for tickerless securities, and suppression of changes when the prior quarter was not filed.
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 core purpose and defaults are front-loaded, and every clause carries real information rather than repetition. It is dense to the point of reading as one long block, which slightly hurts scannability, but there is no filler to cut.
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 tool this complex, the description covers the edge cases an agent must know before calling: pagination limits, split adjustments, missing-prior-quarter behavior, and option/sold-out reporting. Return fields are also covered by the output schema, so nothing material is missing.
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 adds meaning about how parameters interact: the quarter parameter's default (latest filed) is tied to the change/sold-out logic, and the page hint is linked to the 200-holding cap. This slightly exceeds what the schema alone conveys.
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 and resource: retrieving one 13F filer (institution or curated superinvestor) by SEC CIK, plus its filing quarters and holdings. The scope is narrow and unambiguous enough that an agent can distinguish it from siblings like get_stock_13f_holders (the inverse direction) without opening the schema.
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 never says when to use this tool versus get_stock_13f_holders, get_superinvestor_activity, or search; the only routing hint ('Get it from search') lives in the schema, not the description. Usage is inferable from the resource name alone, but no explicit conditions or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current holders of 5% or more of a stock according to their latest Schedule 13D or 13G filing, largest first, like the Major holders tab on livermore.club. Each holder has pct_of_class (percent of the share class, 7.5 = 7.5%) and shares from its latest filing, the change against the previous filing of the same position (previous_pct_of_class, pct_of_class_change in percentage points; new_position is true for a first filing), the form (13D, 13G, 13D/A, 13G/A), filing and event dates, when the position was first filed and how many filings it has, and links to the holder's livermore.club page (institutions and insiders) and the SEC filing. In a group filing each member reports the shares it counts as its own, so the figure is the largest single stake, not a sum. Share classes (GOOG, GOOGL) are split by the CUSIP in the filing. Limits: holders stop filing after a company is acquired or delisted, and holders whose latest filing is an older SC 13D or SC 13G (before 2024-12-18) have no percent and are not counted. Structured 13D/13G filings (voluntary since 2023-12-18, required since 2024-12-18) carry the percent, shares and event date; older SC 13D and SC 13G filings (since 2021) list only the filer, the company and the date (legacy true). Call get_data_coverage for the loaded date range.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return (1-200, default 25). | |
| ticker | Yes | Stock ticker, e.g. AAPL or BRK.B (share classes use a dot; BRK-B also works). |
| Name | Required | Description |
|---|---|---|
| cik | Yes | |
| url | Yes | |
| name | Yes | |
| note | Yes | |
| ticker | Yes | |
| holders | Yes | |
| holders_total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial non-obvious behavior: group filings report the largest single stake rather than a sum, share classes are split by CUSIP, legacy SC 13D/13G filings lack percent and are excluded, and holders stop filing after acquisition/delisting. This is exactly the kind of caveat an agent cannot infer from structured fields.
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?
Purpose and the field inventory are front-loaded, and every clause carries real information (field semantics, filing-form caveats, limits). It is dense and close to a wall of text, which slightly hurts scannability, but little is expendable.
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?
Though an output schema exists (so return values need not be explained), the description goes further by documenting field semantics and legacy/group-filing edge cases, leaving an agent fully equipped to interpret results and avoid misreading the figures.
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 both parameters (ticker, limit) are already documented in the schema and the description adds no further parameter detail. Baseline 3 applies when the schema does the heavy lifting.
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 resource (current holders of 5%+ of a stock via Schedule 13D/13G filings), ordering (largest first), and anchors it to a known reference (the Major holders tab on livermore.club). An agent can distinguish it from get_stock_13f_holders or get_ownership_filings, which cover different filing regimes.
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?
Usage context is implied through the described data scope and the pointed 'Call get_data_coverage for the loaded date range' note, but it never explicitly says when to prefer this over sibling tools like get_ownership_filings or get_stock_13f_holders. No when-not or alternative-selection guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule 13D and 13G filings by holders of more than 5% of a company, newest first, like livermore.club/en/ownership. 13D is filed by holders who may seek to influence the company (activists), 13G by passive holders; /A marks an amendment. Filter by form, ticker (one stock's whole history), filer_cik (an institution's or person's filings, including those it is named in), query (filer or company name, or a ticker) and filing dates. Without ticker or filer_cik the query is market-wide and limited to 365 days of filings (default: the last 30 days); note says when the range was narrowed. Each row has the company (issuer_cik, issuer_name, ticker), the filer (filer_cik, filer_name, the superinvestor name when it is one, reporting_persons in a group filing), pct_of_class and shares, the change against the previous filing of the same position (previous_pct_of_class, pct_of_class_change in percentage points, new_position), below_5_pct (an exit or a drop below the threshold), the event date, and links to livermore.club (filer_url, stock_url) and the SEC filing. Structured 13D/13G filings (voluntary since 2023-12-18, required since 2024-12-18) carry the percent, shares and event date; older SC 13D and SC 13G filings (since 2021) list only the filer, the company and the date (legacy true). Call get_data_coverage for the loaded date range. At most 200 rows per call; use page for more.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest filing date, YYYY-MM-DD, inclusive. | |
| form | No | 13D (holders who may seek to influence the company) or 13G (passive holders). Default: both. | |
| from | No | Earliest filing date, YYYY-MM-DD (US Eastern). | |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| limit | No | Maximum rows to return (1-200, default 25). | |
| query | No | Filer or company name contains this text, or a ticker for that company's filings (like the search box on livermore.club/en/ownership). | |
| ticker | No | Only filings for this stock (the company's filings for this share class), whole history. | |
| filer_cik | No | Only filings this filer submitted or is named in as a reporting person, whole history. Get the CIK from search (institutions and insiders). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| filer | Yes | |
| limit | Yes | |
| scope | Yes | |
| stock | Yes | |
| filters | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, and the description goes further: the 200-row cap and paging requirement, the note signal when the date range is narrowed, and the legacy/structured data split (percent/shares only available post-2023-12-18, legacy rows carry filer/company/date only). That is exactly the operational context an agent needs.
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 purpose, then filters, then defaults, then row shape and data caveats — a logical progression. It is long and repeats the form definitions already in the schema, but nearly every clause carries information useful for calling the tool.
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 an 8-param, zero-required, read-only search tool with pagination and heterogeneous data vintages, the description covers filtering modes, defaults, pagination limits, and data-quality caveats. With an output schema present, the row-field enumeration is a bonus rather than a gap.
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 adds real meaning beyond the schema: filer_cik includes filings where the entity is merely *named* as a reporting person, ticker returns the stock's whole history, and query can match a ticker as well as a name. The restated 13D/13G definitions duplicate the schema wording.
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 (Schedule 13D/13G filings by >5% holders), scope (newest first, market-wide vs. single-entity), and anchors to a concrete analog (livermore.club/en/ownership). It is clearly separable from siblings like get_stock_13f_holders or get_superinvestor_activity.
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?
Explains when the query is market-wide and how it is then capped to 365 days (default 30), and routes the agent to get_data_coverage for the loaded range. However, it never explicitly says when to prefer this tool over get_major_holders or get_stock_13f_holders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One politician (a member of the U.S. Congress: House or Senate), by bioguide ID or name: party, chamber, state, district, in office or former, terms served with start and end dates; a profile with the official photo_url, position (e.g. U.S. Representative for California's 11th district), district code (CA-11), birthday and age, official website, social accounts and Wikipedia as URLs, leadership roles (Speaker, whips, caucus chairs; current first) and, for politicians in office, current committee and subcommittee seats with titles (chair, ranking_member and so on); trade statistics since 2020 for the chosen assets (listed securities by default: trades, buys, sells, estimated volume in USD, median filing delay in days, late trades and the reports that contain them), unlisted_trades (trades in bonds, private holdings and other assets, whatever asset is), the number of reports and how many are paper or scanned, the latest filing date, and the 5 tickers the politician traded most in the chosen assets, with livermore.club links. Use get_politician_trades with the bioguide ID for the trades. Profiles, committees and photos come from the unitedstates project (public domain), refreshed daily. Data: House and Senate periodic transaction reports (PTRs) filed since 2020-01-01, from the U.S. House Clerk and the Senate Office of Public Records (eFD), updated daily. Only listed securities are included by default: stocks (including ADRs), ETFs and options, the assets with an exchange ticker. Politicians also report Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; pass asset=other for those or asset=all for everything. Amounts are the statutory ranges members of Congress report, not exact values: amount_min_usd to amount_max_usd, where a null amount_max_usd is an 'Over $X' range; estimated volumes add up range midpoints (an 'Over $X' range counts as X), so treat them as rough sizes. Trades replaced by an amendment and duplicates reported again in a later filing are left out. Paper and scanned reports are listed on politician pages but their trades are not read.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which assets to include: listed (default) = listed securities, that is stocks including ADRs, ETFs and options; stock = listed stocks and ETFs without options; option = options; other = Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; all = everything. The statistics and top tickers cover these assets. | listed |
| politician | Yes | A bioguide ID (e.g. P000197) or a name (e.g. Pelosi, Nancy Pelosi, Bernie Sanders). A name that matches several politicians returns an error listing them. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| asset | Yes | The assets that stats and top_tickers cover. |
| stats | Yes | |
| profile | Yes | |
| politician | Yes | |
| top_tickers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety; the description adds data provenance, daily refresh, statutory amount ranges, treatment of amendments/duplicates, and paper/scanned reports not being read. These are substantive behavioral constraints 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 a single dense block with semicolon-delimited clauses, front-loading identity and fields but running very long. Most content is relevant for this complex tool, though some output detail is redundant with the output schema.
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 explain returns, yet it goes beyond by covering data sources, refresh cadence, asset defaults, amount interpretation, and report limitations. Combined with annotations and 100% schema coverage, an agent has everything needed to call 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%, with both parameters fully documented including the asset enum. The description restates the default and asset meanings but adds no parameter-level syntax or meaning beyond what the schema already provides.
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 names the resource and scope precisely—one U.S. Congress member, by bioguide ID or name—and enumerates profile fields and trade statistics. It explicitly distinguishes this from get_politician_trades, so an agent can select it without inspecting siblings.
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 states the alternative tool and the selector: use get_politician_trades with the bioguide ID for trades. It also defines asset parameter choices and default, giving context for when to fetch other asset classes. The alternative routing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trades in stocks, ETFs, options and, on request, other assets reported by politicians (members of the U.S. Congress: House and Senate), one row per trade, newest report first by default. Filter by politician (bioguide ID or name), ticker, asset (listed by default, or stock, option, other, all), chamber, party, type (buy, sell, exchange), report filing dates (filed_from, filed_to) and trade dates (traded_from, traded_to). Each row has the politician (politician_bioguide, politician_name, party, chamber, state), the asset and reported ticker, asset_class, type (purchase, sale_full, sale_partial, sale or exchange), owner (self, spouse, joint or child), traded_date and filed_date, delay_days (days from the trade to its first report; null when the reported trade date is after the filing date, a typo flagged by trade_date_error), late (reported more than 45 days after the trade), the amount range, the official source_url, and livermore.club links for the politician and the stock (stock_url is null when the asset is not a listed company). totals summarize all trades matching the filters, not just this page. Data: House and Senate periodic transaction reports (PTRs) filed since 2020-01-01, from the U.S. House Clerk and the Senate Office of Public Records (eFD), updated daily. Only listed securities are included by default: stocks (including ADRs), ETFs and options, the assets with an exchange ticker. Politicians also report Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; pass asset=other for those or asset=all for everything. Amounts are the statutory ranges members of Congress report, not exact values: amount_min_usd to amount_max_usd, where a null amount_max_usd is an 'Over $X' range; estimated volumes add up range midpoints (an 'Over $X' range counts as X), so treat them as rough sizes. Trades replaced by an amendment and duplicates reported again in a later filing are left out. Paper and scanned reports are listed on politician pages but their trades are not read. At most 200 rows per call; use page for more.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| sort | No | filed = newest report first (default); traded = most recent trade first; amount = largest amount range first. | filed |
| type | No | buy (purchases), sell (full, partial or unspecified sales) or exchange. | |
| asset | No | Which assets to include: listed (default) = listed securities, that is stocks including ADRs, ETFs and options; stock = listed stocks and ETFs without options; option = options; other = Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; all = everything. | listed |
| limit | No | Maximum rows to return (1-200, default 25). | |
| party | No | democrat, republican or independent (the politician's latest party). | |
| ticker | No | Only trades in this company (all its share classes, options and former tickers), e.g. MSFT. A ticker that is not a listed company (many ETFs and funds) matches the ticker as reported. | |
| chamber | No | house or senate. | |
| filed_to | No | Latest filing date of the report, YYYY-MM-DD, inclusive. | |
| traded_to | No | Latest trade date, YYYY-MM-DD, inclusive. | |
| filed_from | No | Earliest filing date of the report, YYYY-MM-DD. | |
| politician | No | Only this politician (a member of the U.S. Congress): a bioguide ID (e.g. P000197) or a name (e.g. Pelosi, Nancy Pelosi, Bernie Sanders). A name that matches several politicians returns an error listing them. | |
| traded_from | No | Earliest trade date, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| limit | Yes | |
| stock | Yes | |
| ticker | Yes | The ticker filter when it is not a listed company and is matched as reported. |
| totals | Yes | |
| filters | Yes | |
| has_more | Yes | |
| politician | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavioral context: daily updates, 2020-01-01 coverage floor, exclusion of amended and duplicate trades, unreadable paper filings, null semantics for delay_days and amount_max_usd, and the 200-row-per-call cap with paging. This is far beyond what the annotations convey.
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 purpose is front-loaded and much of the content earns its place (asset filtering rules, amendment exclusions), but it is a single dense paragraph that also enumerates output fields. Because an output schema exists, that field-by-field return listing is largely redundant and inflates the 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?
Given the tool's complexity (13 params, multi-source disclosure data), the description covers data provenance, coverage dates, update cadence, deduplication/amendment handling, amount-range caveats, pagination, and default asset scope. An agent has everything needed to call it correctly; return-value detail is further backed by the output schema.
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 every parameter is already documented; the description mostly restates the same filters (asset classes, type values, date ranges). It adds minor value by clarifying that totals span all matching trades and that ticker matching behaves differently for non-listed tickers, but the baseline of 3 applies when the schema does the heavy lifting.
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 and resource ('Trades... reported by politicians') with precise scope: U.S. Congress House and Senate, one row per trade. It distinguishes this from corporate-insider data by explicitly naming the data source (PTRs from the House Clerk and Senate eFD), letting an agent tell it apart from get_insider_trades without opening the schema.
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 clear context: default returns only listed securities, and it routes the agent to asset=other or asset=all for bonds, crypto, private holdings, etc. It also notes paper/scanned reports have no readable trades. It doesn't explicitly name a sibling alternative (e.g., get_insider_trades vs this), so routing is inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Short-selling data for one stock, newest first, in four sections: short_interest (FINRA short interest per settlement date since 2021: short_shares, prev_short_shares, change_shares, change_pct, avg_daily_volume, days_to_cover, dtc_capped), short_volume (FINRA daily off-exchange short volume, last two years: short_volume, short_exempt_volume, total_volume, short_volume_pct), fails_to_deliver (SEC fails-to-deliver, last two years: quantity, price, value_usd) and ats_weekly (FINRA weekly ATS and OTC volume since December 2021, per tier: ats_shares, ats_trades, otc_shares, otc_trades, ats_pct). Without dates: about the last year of short interest (24 settlement dates), the last 30 trading days of short volume and of fails-to-deliver, and the last 12 weeks of ATS data; with from and/or to, each section covers that range, up to 200 rows. Short interest (FINRA) is the number of shares sold short and not yet covered on a settlement date, reported twice a month about 8 business days after the settlement date. Daily short volume (FINRA Reg SHO) is something else: the shares sold short on one day among off-exchange trades only (not short interest, and not total market volume); short_volume_pct is not a sentiment indicator, because market makers' hedging short sales are normally around half of off-exchange volume. Fails-to-deliver (SEC) are shares not delivered on the settlement date, with the SEC's price (the previous close). ATS weekly (FINRA) is volume on alternative trading systems (dark pools) and other off-exchange (OTC) trading, published 2 to 4 weeks late; ats_pct is ATS divided by ATS plus OTC, not a share of total volume. There is no short interest as a percent of float or shares outstanding (no reliable float data). Share classes are separate tickers (BRK.A, BRK.B).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest date, YYYY-MM-DD, inclusive. | |
| from | No | Earliest date, YYYY-MM-DD. With from or to, every section covers that range (up to 200 rows each). | |
| ticker | Yes | Stock ticker, e.g. AAPL or BRK.B (share classes use a dot; BRK-B also works). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| note | Yes | |
| range | Yes | |
| ticker | Yes | |
| ats_weekly | Yes | |
| short_volume | Yes | |
| short_interest | Yes | |
| fails_to_deliver | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile, and the description goes well beyond them: it explains default windows per section, the 200-row cap, publication lags (FINRA ~8 business days, ATS 2-4 weeks late), and disambiguates short interest vs. short volume vs. FTD vs. ATS. It also sets expectations on missing metrics (no float-based percentage).
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 section inventory, which is good, but the body is a dense wall of comma-separated field lists and parenthetical caveats that is hard to scan. Every claim is useful, yet the structure sacrifices readability for completeness.
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 four heterogeneous datasets, no output schema detail needed beyond what exists, idempotent read-only annotations, and one required ticker, the definition covers the nuances an agent needs: what each section means, timing/lag, row caps, and data limitations. Nothing material is missing.
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 baseline is 3; the description adds meaningful semantics by spelling out what from/to do per section (each section covers the range, up to 200 rows) and what defaults apply when they are omitted — information not fully present in the 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?
Names a specific resource and enumerates all four data sections with their fields, distinguishing it from list_short_interest (which is presumably cross-stock). An agent can immediately tell this is the per-stock short-selling dataset.
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?
Implicitly scopes usage to a single ticker and clarifies date-range behavior, but never names the sibling list_short_interest or states when to use one over the other. Guidance is strong on domain semantics but weak on tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overview of one US-listed stock: company facts (SEC name, CIK, exchange, SIC industry, other share classes), open-market insider activity in the last 90 days (Form 4 codes P and S, non-derivative: number of filings and total USD), institutional ownership from 13F for the latest complete quarter (number of holders, total shares and market value in USD, and the previous quarter for comparison), and the curated superinvestors holding it (shares, market value, pct_of_portfolio = percent of that superinvestor's 13F portfolio). A quarter is complete once its 45-day filing deadline has passed and the data is loaded; in_progress_quarter is a newer quarter still being filed. Share classes (GOOG/GOOGL, BRK.A/BRK.B) are separate tickers because 13F reports each class separately. A ticker that is no longer on the SEC's list (active false; delisted true when the company has no listed common stock left, with the Form 25 delisting date in delisted_on when known) keeps its page, and its 13F figures are for its last quarter with a full set of 13F holders (f13.note). financials summarizes the latest fiscal year and quarter (revenue, net income, free cash flow and their year-over-year growth, in the reporting currency, which is not always USD) and short_interest the latest FINRA short interest (short shares, change, days to cover); each is null when there is no data. market_cap is the company's market cap in USD. Market cap is the latest daily closing price of the company's primary ticker times the shares outstanding on its latest SEC 10-K or 10-Q cover page (shares_as_of), adjusted for stock splits since then (split_factor, 1 = none). It is recalculated every US trading day after the close; close_date is the trading day of the close used. No stock price is returned. When market_cap is null, market_cap_unavailable gives the reason: no_price or stale_price (no daily close in the last 7 days, for example OTC or halted stocks), no_shares or stale_shares (no cover-page share count within about 400 days, common for companies whose cover lists several share classes separately, such as GOOGL/GOOG, BRK or META), foreign_filer (a Form 20-F filer: the US listing is usually ADSs and the ADS ratio is not in SEC data), shares_mismatch (the cover-page share count does not match the listed shares: 13F institutions report holding more than 1.5 times the cover-page shares, which points to several share classes or ADSs, or the company has two or more traded common lines whose latest closes differ by more than 1.25 times, such as multi-fund ETP trusts like ProShares Trust II that share one cover-page share count) or out_of_range (an implausible value, including a market cap below $1 million); both are null when Livermore has no market cap row for the company. screen_stocks lists companies by market cap. Use get_insider_trades, get_stock_13f_holders, get_financials and get_short_interest for the full lists.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker, e.g. AAPL or BRK.B (share classes use a dot; BRK-B also works). |
| Name | Required | Description |
|---|---|---|
| cik | Yes | |
| f13 | Yes | |
| sic | Yes | |
| url | Yes | |
| name | Yes | |
| active | Yes | false when the ticker is no longer on the SEC's list of tickers. |
| ticker | Yes | |
| delisted | Yes | true when the ticker is inactive and the company has no active common-stock ticker left (delisted or acquired). An inactive ticker whose company still trades under another ticker (a ticker change) is not delisted. |
| exchange | Yes | |
| industry | Yes | |
| financials | Yes | Latest fiscal year and latest quarter from the XBRL financial statements, in the reporting currency; null when there are none. get_financials has the full statements. |
| market_cap | Yes | Market cap in USD: the latest close of the company's primary ticker times the cover-page shares outstanding (no price is returned); null when unavailable (see market_cap_unavailable). |
| delisted_on | Yes | Delisting date (YYYY-MM-DD) of a delisted stock: the SEC filing date of the Form 25 that removed its common stock from the exchange. null when the stock is not delisted or no Form 25 was found (for example a company that kept trading over the counter). |
| holders_url | Yes | |
| insiders_url | Yes | |
| short_interest | Yes | Latest FINRA short interest (within the last year); null when there is none. get_short_interest has the history, short volume, fails-to-deliver and ATS volume. |
| superinvestors | Yes | |
| sec_filings_url | Yes | |
| insider_activity | Yes | |
| other_share_classes | Yes | |
| market_cap_unavailable | Yes | Why market_cap is null: no_price, stale_price, no_shares, stale_shares, foreign_filer, shares_mismatch, out_of_range. null when market_cap is set, or when Livermore has no market cap row for the company. |
Institutions that reported holding a stock in their 13F-HR filings for one calendar quarter (default: the latest complete quarter, or for a ticker that is no longer listed its last quarter with a full set of 13F holders; 13F is filed up to 45 days after quarter end and covers long positions in US-listed securities only). Each row: institution, shares, market value in USD at quarter end as reported, pct_of_portfolio (percent of that institution's 13F portfolio), and the change versus the previous calendar quarter (action new/added/reduced/unchanged/sold_out, share_change, share_change_pct in percent). When the stock split between the two quarters, previous_shares is converted to this quarter's shares before comparing (split_factor = new shares per old share; the filed count is previous_shares / split_factor) and a change within 0.5% counts as unchanged; the previous totals are as filed. Institutions that held the stock last quarter and filed this quarter without it are listed after the holders as sold_out; institutions that held it last quarter but have not filed this quarter yet are listed at the very end as not_filed (not a sale, shares and value null). Totals (holders, shares, value_usd) cover all holders, not just this page. Multiple CUSIPs of the same ticker are combined. changes_available is false (and the change fields are null) when the previous quarter cannot be compared; note explains incomplete or still-filing quarters. At most 200 rows per call; use page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| sort | No | value = largest market value first (default); shares = most shares; change = largest share increase first. Sold-out holders are always listed last. | value |
| limit | No | Maximum rows to return (1-200, default 25). | |
| ticker | Yes | Stock ticker, e.g. AAPL or BRK.B (share classes use a dot; BRK-B also works). | |
| quarter | No | Quarter to show, e.g. 2026-q2. Default: the latest complete quarter; for a ticker that is no longer listed, its last quarter with a full set of 13F holders. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| sort | Yes | |
| limit | Yes | |
| period | Yes | |
| shares | Yes | |
| ticker | Yes | |
| holders | Yes | |
| quarter | Yes | |
| has_more | Yes | |
| previous | Yes | |
| value_usd | Yes | |
| split_factor | Yes | Stock split between previous_quarter and quarter: new shares per old share (10 = 10-for-1 split, 0.1 = 1-for-10 reverse split); null when there was none. |
| previous_quarter | Yes | |
| changes_available | Yes | |
| in_progress_quarter | Yes | |
| latest_complete_quarter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial behavior beyond them: split-adjusted prior-share comparison with a 0.5% unchanged threshold, sold_out vs not_filed trailing rows, nulled change fields when changes_available is false, and totals that cover all holders rather than the page.
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?
Purpose is front-loaded, but the single dense paragraph dedicates much of its length to enumerating row fields and change semantics that the output schema already covers. The genuinely non-obvious domain logic (splits, sold_out/not_filed) earns its place; the field-by-field recap does not.
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 a complex financial domain, full annotation coverage, and an output schema, the description supplies exactly the logic an agent cannot infer: quarter completeness, filing lag, split normalization, and how non-holder rows are ordered. Nothing needed to interpret a call correctly is missing.
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 parameters (page, limit, sort, ticker, quarter) are already documented in the schema itself. The description reinforces the quarter default and the 200-row page cap but adds little semantic detail beyond what the schema already carries.
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 names a specific resource (institutions reporting holdings in 13F-HR filings) and a specific scope (one calendar quarter, long US-listed positions), with defaults spelled out. It is clearly distinguishable from siblings like get_insider_trades, get_institution, and get_superinvestor_activity.
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 states the default quarter, the fallback for delisted tickers, and the 45-day filing lag, which tells the agent when results are meaningful. It never explicitly routes to a sibling (e.g., 'for a specific institution use get_institution'), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the curated superinvestors bought and sold in one quarter according to 13F, compared with the previous calendar quarter (default: the latest complete quarter). Without superinvestor_cik: most_bought (stocks the most superinvestors opened or added to), most_sold (reduced or sold out) and per-superinvestor counts of new/added/reduced/sold-out positions. With superinvestor_cik: that superinvestor's individual moves grouped by action, largest positions first (shares_change_pct in percent for added and reduced). Only superinvestors that filed both quarters are compared; added and reduced are decided by share count, not value, and when a stock split between the two quarters the previous share count is converted first (split_factor). Securities are merged by ticker (CUSIP when there is none). 13F is filed up to 45 days after quarter end.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows per list (1-50, default 25). | |
| quarter | No | Quarter to compare with the previous calendar quarter, e.g. 2026-q2. Default: the latest complete quarter that can be compared. | |
| superinvestor_cik | No | Show this superinvestor's individual moves instead of the cross-superinvestor summary. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| period | Yes | |
| quarter | Yes | |
| most_sold | Yes | |
| most_bought | Yes | |
| superinvestor | Yes | |
| by_superinvestor | Yes | |
| previous_quarter | Yes | |
| superinvestors_compared | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations, which only cover the read-only/idempotent safety profile. It discloses subtle methodological rules: only superinvestors filing both quarters are compared, added/reduced is decided by share count not value, split adjustments via split_factor, ticker/CUSIP merging, and the 45-day 13F filing lag. This is exactly the kind of non-obvious behavior an agent needs.
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?
Dense but front-loaded, leading with the core purpose before detailing edge cases. The long run-on sentences pack a lot of caveats, but each sentence carries substantive information rather than filler.
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 an output schema exists, the description need not explain return values, and it covers the remaining gaps: modes, defaults, and the accounting/matching methodology. An agent has everything needed 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 baseline is 3, but the description adds real meaning: it explains that quarter compares against the previous calendar quarter and what the superinvestor_cik switch actually changes (grouping by action, largest first, shares_change_pct in percent). This exceeds what the schema alone conveys.
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 ('what curated superinvestors bought and sold in one quarter according to 13F') and delineates two distinct output modes based on superinvestor_cik. This is precise enough to distinguish it from siblings like get_stock_13f_holders or list_superinvestors without opening the schema.
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 explains the conditional branching: omit superinvestor_cik for the cross-investor summary, provide it for individual moves. It also clarifies the default quarter behavior. It does not name a specific alternative tool for looking up a CIK, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A company's SEC filings, or the whole market's: 10-K (annual report, including 10-KT), 10-Q (quarterly report), 8-K (current report), 20-F and 40-F (foreign companies' annual reports), each with its amendments (/A), newest first, since 2009. Each row: accession, form, the 8-K item codes with their descriptions (for example 2.02 Results of operations, 4.02 Non-reliance on previously issued financial statements, 5.02 Departure or appointment of directors or officers), filed_date, accepted_at (ISO 8601 UTC), period_of_report (the period end for 10-K and 10-Q, the event date for 8-K), the company with its ticker, url (the company's filings page on livermore.club), sec_url (the main document on SEC.gov) and index_url (the SEC filing index with all exhibits). Livermore does not store the text of filings. To learn what an 8-K reports, or a 10-K or 10-Q's business description, risk factors or management's discussion, fetch sec_url; the press release of an 8-K with Item 2.02 is usually exhibit EX-99.1, listed on index_url. With ticker or cik the company's whole history is searchable (filings under a former CIK included). Without either, the query covers the whole market (companies with a ticker) and at most 30 days of filing dates (default: the last 7 days); note says when the range was narrowed. items keeps 8-K filings with any of the given item codes. At most 200 rows per call; use page.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest filing date, YYYY-MM-DD, inclusive. | |
| cik | No | The company's SEC CIK instead of a ticker, e.g. 0000320193. Give ticker or cik, not both. | |
| from | No | Earliest filing date, YYYY-MM-DD (US Eastern). | |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| forms | No | Form types, each including its amendments (/A); 10-K also includes 10-KT. Default all, e.g. ["10-K","10-Q"]. | |
| items | No | 8-K item codes; a filing matches when it has any of them, e.g. ["4.01","4.02","5.02"]. Only 8-K and 8-K/A filings have items. | |
| limit | No | Maximum rows to return (1-200, default 25). | |
| ticker | No | Only this company's filings, whole history (including filings under a former CIK). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| limit | Yes | |
| scope | Yes | |
| company | Yes | |
| filters | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world, so the bar is met; the description still adds substantial behavior: newest-first ordering, data since 2009, the 30-day market cap with a note when the range is narrowed, a 200-row-per-call limit with pagination, and that filing text is not stored. These are operational constraints an agent needs and none duplicate 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?
The material is front-loaded with the resource, but it is delivered as one dense run-on paragraph mixing scope, form taxonomy, output fields, retrieval guidance, and pagination. The mid-sentence catalog of 8-K item codes with descriptions is heavy for a description, and a few structural breaks would make it far easier to parse.
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?
Despite an output schema existing, the description explains the row shape (accession, form, item codes, filed_date, accepted_at, period_of_report, ticker, url/sec_url/index_url) and how to retrieve underlying text, leaving no ambiguity for an 8-parameter, zero-required tool. Combined with the annotations, nothing needed to invoke it correctly is missing.
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 3 is the baseline; the description goes further by explaining that items matches 8-K filings containing any of the given codes (and only 8-K/8-K-A have items), that forms includes amendments, and that ticker/cik should not both be given. It adds meaningful semantics over the schema, though much of the row-field detail belongs to the output shape rather than inputs.
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 names a specific resource (SEC filings: 10-K, 10-Q, 8-K, 20-F, 40-F with amendments) and both scopes (a single company or the whole market). It is immediately distinguishable from siblings like get_ownership_filings, get_financials, or get_major_holders, which cover different datasets. An agent does not need to open the schema to know what this returns.
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 gives clear conditional guidance: with ticker/cik the full company history is searchable (including former CIKs), without either the query covers the market but is capped at 30 days (default 7). It also directs the agent to sec_url / index_url for the actual filing text since Livermore stores none. It does not, however, name any sibling tool as an alternative when the agent wants ownership or financials instead, so routing between siblings is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every stock's FINRA short interest for one settlement date (default: the latest), ranked like livermore.club/en/shorts: by change in short shares since the previous settlement date (default; dir=asc gives the largest decreases), change_pct, days_to_cover or short_shares. Only stocks with an average daily volume of at least min_avg_volume shares (default 100,000) are listed, which keeps thinly traded stocks with huge percentage changes out. Rows with missing values, and with days to cover at FINRA's cap of 999.99 (dtc_capped true, days_to_cover null), are listed last in either direction. Each row has our ticker (null when FINRA's symbol is not matched to a listed company), FINRA's symbol, the company name, the market, the short interest figures and the stock's short interest page (url). recent_settlement_dates lists the latest 12 settlement dates. Short interest is reported twice a month, about 8 business days after the settlement date. There is no short interest as a percent of float. At most 200 rows per call; use page.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | desc = largest first (default); with sort=change, asc lists the largest decreases (covering). | desc |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| sort | No | change = change in short shares since the previous settlement date (default), change_pct, days_to_cover or short_shares. | change |
| limit | No | Maximum rows to return (1-200, default 25). | |
| min_avg_volume | No | Minimum average daily volume in shares (default 100,000), which keeps thinly traded stocks with huge percentage changes out. | |
| settlement_date | No | FINRA settlement date, YYYY-MM-DD (mid-month and month-end). Default: the latest one. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| note | Yes | |
| page | Yes | |
| rows | Yes | |
| limit | Yes | |
| filters | Yes | |
| has_more | Yes | |
| settlement_date | Yes | |
| recent_settlement_dates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only/idempotent profile, and the description adds substantial non-obvious behavior: rows with missing values and days_to_cover capped at 999.99 (dtc_capped true, days_to_cover null) are always listed last regardless of direction, thin stocks are filtered by default, there is no short-interest-as-%-of-float, and results are capped at 200 rows requiring paging.
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 core purpose, default ordering and the pagination cap are front-loaded, and most sentences carry unique information (cadence, null ordering, absence of %-of-float). It is a single dense paragraph that could be broken into shorter units, but there is little filler.
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 need not be re-explained, and the description still covers row contents, the recent_settlement_dates companion field, edge-case ordering, volume filtering and page limits. For a 6-parameter, paginated ranking tool this leaves nothing an agent needs missing.
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 adds interpretation beyond the schema: the cross-parameter interaction of dir=asc with sort=change ('largest decreases (covering)'), the reason min_avg_volume exists, and the twice-monthly, ~8-business-day reporting cadence that governs settlement_date.
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 precise verb and resource ('Every stock's FINRA short interest for one settlement date ... ranked like livermore.club/en/shorts'), including the ranking dimension and scope, which clearly separates it from the single-company get_short_interest sibling. An agent can tell what the tool returns and how it is ordered without opening the schema.
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 explains when the defaults are appropriate ('default: the latest' settlement date, default sort=change) and gives a concrete use signal ('dir=asc gives the largest decreases (covering)'), plus the rationale for min_avg_volume. It does not, however, explicitly name when to choose this over get_short_interest, so there is no hard exclusion or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The curated list of superinvestors (well-known long-term investors such as Warren Buffett's Berkshire Hathaway, Bill Ackman's Pershing Square, Li Lu's Himalaya Capital) with their latest 13F quarter: portfolio value in USD (long positions, excluding options), number of positions, filing date, and the 3 largest holdings with pct_of_portfolio (percent). Sorted by portfolio value. Names are in English with Chinese names in name_zh and manager_zh. source_cik is set when the latest quarter was filed under a predecessor CIK (pass it to get_institution to see that quarter). Use get_institution(cik) for full holdings and get_superinvestor_activity for what they bought and sold in a quarter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| count | Yes | |
| superinvestors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is covered. The description adds meaningful behavior beyond annotations: sorting by portfolio value, exclusion of options, Chinese name fields, and the predecessor CIK behavior. It does not contradict annotations, and the added context enriches the agent's understanding without relying on the schema.
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 each sentence earns its place: main purpose, data fields, sorting, naming, predecessor CIK, and alternatives. It is front-loaded with the primary function and avoids redundancy. Slightly long but not wasteful.
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 no parameters and an output schema present, the description covers all essential call-time information: what data is returned, sorting, edge case of source_cik, and pointers to sibling tools. It does not mention pagination or rate limits, but those are less critical given the tool's simplicity and the output schema's coverage.
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 tool has zero parameters, so the baseline is 4. There is nothing for the description to add beyond what the schema provides (which is empty). The description appropriately explains the data structure instead, which is not parameter-related. No issues.
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: 'list the curated list of superinvestors' with detailed data fields (portfolio value, positions, filing date, top holdings). It clearly distinguishes from siblings by mentioning get_institution and get_superinvestor_activity for different needs, so an agent can tell it apart.
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 directs when to use alternatives: 'Use get_institution(cik) for full holdings and get_superinvestor_activity for what they bought and sold in a quarter.' Also explains the source_cik caveat, leaving no ambiguity about when to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US-listed companies by market cap, largest first (dir=asc for smallest first), optionally within min_market_cap_usd and max_market_cap_usd (US dollars, both inclusive; give either, both or neither). For companies around $100 million, try for example min_market_cap_usd 50000000 and max_market_cap_usd 200000000. Market cap is the latest daily closing price of the company's primary ticker times the shares outstanding on its latest SEC 10-K or 10-Q cover page (shares_as_of), adjusted for stock splits since then (split_factor, 1 = none). It is recalculated every US trading day after the close; close_date is the trading day of the close used. No stock price is returned. Companies without a market cap are not listed: no_price or stale_price (no daily close in the last 7 days, for example OTC or halted stocks), no_shares or stale_shares (no cover-page share count within about 400 days, common for companies whose cover lists several share classes separately, such as GOOGL/GOOG, BRK or META), foreign_filer (a Form 20-F filer: the US listing is usually ADSs and the ADS ratio is not in SEC data), shares_mismatch (the cover-page share count does not match the listed shares: 13F institutions report holding more than 1.5 times the cover-page shares, which points to several share classes or ADSs, or the company has two or more traded common lines whose latest closes differ by more than 1.25 times, such as multi-fund ETP trusts like ProShares Trust II that share one cover-page share count) or out_of_range (an implausible value, including a market cap below $1 million). So Form 20-F issuers whose US shares are ADSs, companies whose cover page lists several share classes and multi-fund ETP trusts are missing. One row per company: ticker (the priced ticker), name, exchange, SIC industry, market_cap_usd, close_date, shares, shares_as_of, split_factor and url (the stock page). total counts every matching company and as_of is the newest close date. To research a company, follow up with get_stock, get_financials and get_insider_trades. At most 200 rows per call; use page.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | desc = largest market cap first (default); asc = smallest first. | desc |
| page | No | Page number starting at 1; each page has `limit` rows. Check has_more. | |
| limit | No | Maximum rows to return (1-200, default 25). | |
| max_market_cap_usd | No | Largest market cap in US dollars, inclusive; not below min_market_cap_usd. Default: no maximum. | |
| min_market_cap_usd | No | Smallest market cap in US dollars, inclusive (100000000 = $100 million). Default: no minimum. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| page | Yes | |
| as_of | Yes | The newest close date in the market cap data; null before it is loaded. |
| limit | Yes | |
| total | Yes | Number of companies matching the range (all pages). |
| filters | Yes | |
| has_more | Yes | |
| companies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes far beyond them: the exact market-cap formula (close x cover-page shares, split-adjusted), daily recalculation after close, the 200-row cap, and a full enumeration of why companies are silently absent (no_price, stale_price, no_shares, foreign_filer, shares_mismatch, out_of_range). The disclosure that GOOGL/BRK/META-class issuers are missing is exactly the kind of surprise an agent must know in advance.
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 correctly — sort order and filters come first, methodology and exclusions after. It is long, and the row-field inventory (ticker, name, exchange, ... url) partially duplicates the output schema, but the exclusion taxonomy genuinely earns its space because it flags non-obvious missing data.
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?
An output schema exists, yet the description still sketches the row shape, reports total/as_of semantics, and covers pagination limits and follow-up paths. Combined with the methodology and exclusion notes, an agent has everything needed to call and interpret this tool 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 3 is the baseline; the description exceeds it by giving illustrative dollar values for a realistic screen and stating that either, both, or neither bound may be supplied. It adds usable intuition about bound semantics beyond the schema's terse 'inclusive / default: no maximum' phrasing.
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 opening clause gives a specific verb+resource+ordering: 'US-listed companies by market cap, largest first (dir=asc for smallest first)'. It is immediately distinguishable from siblings like get_stock (single company) or list_short_interest, and the optional cap-range scoping is stated up front.
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 supplies a concrete usage scenario ('For companies around $100 million, try min 50000000 and max 200000000') and routes the agent onward for deeper work ('follow up with get_stock, get_financials and get_insider_trades'). What it lacks is an explicit when-not-to-use or a named same-purpose alternative, but the screening context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find US stocks, 13F institutions (including the curated superinvestors, matched by fund or manager name, e.g. 'Buffett' or 'Pershing', and large asset managers matched by their common name, e.g. 'Fidelity' finds FMR LLC and 'Capital Group' its three 13F filers), corporate insiders (Form 4 reporting persons) and politicians (members of the U.S. Congress: House and Senate members who served in 2019 or later, by name, nickname, last name or bioguide ID; current members first) by ticker or name. Returns up to limit matches per group, best match first, with the identifier the other tools take: ticker for get_stock, get_insider_trades, get_stock_13f_holders, get_major_holders and the other stock filters; institution cik for get_institution and get_ownership_filings(filer_cik); insider cik for get_insider_trades(insider_cik) and get_form144_notices(seller_cik); politician bioguide for get_politician and get_politician_trades(politician). Names are SEC names in English (insiders appear as 'Cook Timothy D'); superinvestors and those asset managers also match their Chinese names. Tickers match exactly or by prefix; a CIK (e.g. 1067983) or a 9-character CUSIP (e.g. 037833100) matches exactly; names need at least 2 characters. Stocks carry the company in name; detail is the manager for superinvestors ('13F filer' for other institutions) and the latest title and company for insiders. Politicians have party (D, R, I), chamber (house or senate), state, district (House seats; 0 is at-large) and in_office. Every item has its livermore.club url.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches per group (1-20, default 5). | |
| query | Yes | Ticker, company, fund, manager, person or politician name, CIK or CUSIP. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| stocks | Yes | |
| insiders | Yes | |
| politicians | Yes | |
| institutions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial behavior beyond that: per-group result cap, best-match-first ordering, politicians sorted current-members-first, matching semantics (exact/prefix ticker, exact CIK/CUSIP, 2-char minimum for names), and the meaning of the `detail` field per group.
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?
Purpose is front-loaded in the opening clause and every subsequent sentence carries non-redundant information. It is dense and somewhat run-on with nested parentheticals, which slightly taxes readability, but there is little wasted text.
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 an output schema exists, the description appropriately focuses on input interpretation and cross-tool routing while still noting the per-item `detail` and `url` fields. For a resolver feeding eight-plus siblings, this is complete enough for an agent to call it correctly and consume its output.
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 adds real meaning: it interprets `query` by spelling out how tickers, CIKs, CUSIPs and names are matched, and clarifies that names are SEC English names with Chinese-name matching for superinvestors/asset managers. `limit` is explained as a per-group cap, adding nuance beyond the schema's 'maximum matches per group'.
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 (find) and enumerates the exact resources searched (US stocks, 13F institutions/superinvestors, corporate insiders, politicians) with the disambiguating detail that it searches by ticker or name. It goes further by naming which sibling each returned identifier feeds (ticker→get_stock, institution cik→get_institution, etc.), so an agent can instantly tell it apart from the retrieval siblings.
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 makes its role clear as a resolver that yields the identifiers the other tools consume, giving strong context for when to reach for it first. It names the downstream siblings explicitly, but it does not state any exclusion or 'when not to use' condition (e.g. when to skip search and call a sibling directly).
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_data_coverage4 fields changedOutput schema / properties / last_successful_update / properties / market_capsAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / last_successful_update / requiredPrevious value: -[
- "sec_filings",
- "tickers",
- "cusip_mapping",
- "congress",
- "company_filings",
- "financials",
- "finra",
- "exchange_rates"
-]New value: +[
+ "sec_filings",
+ "tickers",
+ "cusip_mapping",
+ "congress",
+ "company_filings",
+ "financials",
+ "finra",
+ "exchange_rates",
+ "market_caps"
+]Output schema / properties / market_capsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "companies_with_market_cap": {
+ "type": "number"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_close_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "companies_with_market_cap",
+ "latest_close_date",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "website",
- "sources",
- "form4",
- "f13",
- "superinvestors",
- "ownership",
- "congress",
- "filings",
- "financials",
- "short_interest",
- "short_volume",
- "ats_weekly",
- "fails_to_deliver",
- "last_successful_update",
- "update_schedule",
- "limits",
- "docs_url",
- "llms_txt_url"
-]New value: +[
+ "website",
+ "sources",
+ "form4",
+ "f13",
+ "superinvestors",
+ "ownership",
+ "congress",
+ "filings",
+ "financials",
+ "short_interest",
+ "short_volume",
+ "ats_weekly",
+ "fails_to_deliver",
+ "market_caps",
+ "last_successful_update",
+ "update_schedule",
+ "limits",
+ "docs_url",
+ "llms_txt_url"
+]get_stock3 fields changedOutput schema / properties / market_capAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "close_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shares": {
+ "description": "Cover-page shares outstanding, adjusted for later splits.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shares_as_of": {
+ "description": "Date of the share count on the 10-K or 10-Q cover page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock splits applied since shares_as_of (1 = none).",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "description": "The ticker whose close was used (the company's primary ticker; other share classes share it).",
+ "type": "string"
+ },
+ "usd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "usd",
+ "ticker",
+ "close_date",
+ "shares",
+ "shares_as_of",
+ "split_factor"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Market cap in USD: the latest close of the company's primary ticker times the cover-page shares outstanding (no price is returned); null when unavailable (see market_cap_unavailable)."
+}Output schema / properties / market_cap_unavailableAdded value: +{
+ "description": "Why market_cap is null: no_price, stale_price, no_shares, stale_shares, foreign_filer, shares_mismatch, out_of_range. null when market_cap is set, or when Livermore has no market cap row for the company.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "cik",
- "exchange",
- "active",
- "delisted",
- "delisted_on",
- "sic",
- "industry",
- "other_share_classes",
- "url",
- "insiders_url",
- "holders_url",
- "sec_filings_url",
- "insider_activity",
- "f13",
- "superinvestors",
- "financials",
- "short_interest"
-]New value: +[
+ "ticker",
+ "name",
+ "cik",
+ "exchange",
+ "active",
+ "delisted",
+ "delisted_on",
+ "sic",
+ "industry",
+ "other_share_classes",
+ "url",
+ "insiders_url",
+ "holders_url",
+ "sec_filings_url",
+ "insider_activity",
+ "f13",
+ "superinvestors",
+ "financials",
+ "short_interest",
+ "market_cap",
+ "market_cap_unavailable"
+]screen_stocksget_data_coverage12 fields changedOutput schema / properties / ats_weeklyAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_week_start": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_week_start": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_week_start",
+ "latest_week_start",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / fails_to_deliverAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_settlement_date": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_settlement_date": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_settlement_date",
+ "latest_settlement_date",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / filingsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_filed_date": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_filed_date": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_filed_date",
+ "latest_filed_date",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / financialsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "companies": {
+ "type": "number"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_filed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "companies",
+ "latest_filed_date",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / last_successful_update / properties / company_filingsAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / last_successful_update / properties / exchange_ratesAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / last_successful_update / properties / financialsAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / last_successful_update / properties / finraAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / last_successful_update / requiredPrevious value: -[
- "sec_filings",
- "tickers",
- "cusip_mapping",
- "congress"
-]New value: +[
+ "sec_filings",
+ "tickers",
+ "cusip_mapping",
+ "congress",
+ "company_filings",
+ "financials",
+ "finra",
+ "exchange_rates"
+]Output schema / properties / short_interestAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_settlement_date": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_settlement_date": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_settlement_date",
+ "latest_settlement_date",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / short_volumeAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_trade_date": {
+ "type": "string"
+ },
+ "last_updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_trade_date": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_trade_date",
+ "latest_trade_date",
+ "last_updated",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "website",
- "sources",
- "form4",
- "f13",
- "superinvestors",
- "ownership",
- "congress",
- "last_successful_update",
- "update_schedule",
- "limits",
- "docs_url",
- "llms_txt_url"
-]New value: +[
+ "website",
+ "sources",
+ "form4",
+ "f13",
+ "superinvestors",
+ "ownership",
+ "congress",
+ "filings",
+ "financials",
+ "short_interest",
+ "short_volume",
+ "ats_weekly",
+ "fails_to_deliver",
+ "last_successful_update",
+ "update_schedule",
+ "limits",
+ "docs_url",
+ "llms_txt_url"
+]get_financialsget_short_interestget_stock3 fields changedOutput schema / properties / financialsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "description": "Reporting currency of the latest period; amounts are in it, not USD.",
+ "type": "string"
+ },
+ "latest_annual": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "filed_date": {
+ "type": "string"
+ },
+ "fiscal_period": {
+ "enum": [
+ "FY",
+ "Q1",
+ "Q2",
+ "Q3",
+ "Q4"
+ ],
+ "type": "string"
+ },
+ "fiscal_year": {
+ "type": "number"
+ },
+ "form": {
+ "type": "string"
+ },
+ "free_cash_flow": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "period_end": {
+ "type": "string"
+ },
+ "reported_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "usd_rate": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "average": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "period_end": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "average",
+ "period_end"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "US dollars per 1 unit of the reporting currency (FRED H.10): average over the period (for income statement and cash flow amounts) and on the period-end date (for balance sheet amounts). null for companies reporting in USD."
+ },
+ "yoy_pct": {
+ "additionalProperties": false,
+ "properties": {
+ "free_cash_flow": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "revenue",
+ "net_income",
+ "free_cash_flow"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fiscal_year",
+ "fiscal_period",
+ "period_end",
+ "currency",
+ "revenue",
+ "net_income",
+ "free_cash_flow",
+ "yoy_pct",
+ "form",
+ "filed_date",
+ "reported_date",
+ "usd_rate"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "latest_quarter": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "filed_date": {
+ "type": "string"
+ },
+ "fiscal_period": {
+ "enum": [
+ "FY",
+ "Q1",
+ "Q2",
+ "Q3",
+ "Q4"
+ ],
+ "type": "string"
+ },
+ "fiscal_year": {
+ "type": "number"
+ },
+ "form": {
+ "type": "string"
+ },
+ "free_cash_flow": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "period_end": {
+ "type": "string"
+ },
+ "reported_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "usd_rate": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "average": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "period_end": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "average",
+ "period_end"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "US dollars per 1 unit of the reporting currency (FRED H.10): average over the period (for income statement and cash flow amounts) and on the period-end date (for balance sheet amounts). null for companies reporting in USD."
+ },
+ "yoy_pct": {
+ "additionalProperties": false,
+ "properties": {
+ "free_cash_flow": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "revenue",
+ "net_income",
+ "free_cash_flow"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "fiscal_year",
+ "fiscal_period",
+ "period_end",
+ "currency",
+ "revenue",
+ "net_income",
+ "free_cash_flow",
+ "yoy_pct",
+ "form",
+ "filed_date",
+ "reported_date",
+ "usd_rate"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "currency",
+ "latest_annual",
+ "latest_quarter",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Latest fiscal year and latest quarter from the XBRL financial statements, in the reporting currency; null when there are none. get_financials has the full statements."
+}Output schema / properties / short_interestAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "avg_daily_volume": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "change_shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "days_to_cover": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dtc_capped": {
+ "type": "boolean"
+ },
+ "settlement_date": {
+ "type": "string"
+ },
+ "short_shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "settlement_date",
+ "short_shares",
+ "change_shares",
+ "change_pct",
+ "avg_daily_volume",
+ "days_to_cover",
+ "dtc_capped",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Latest FINRA short interest (within the last year); null when there is none. get_short_interest has the history, short volume, fails-to-deliver and ATS volume."
+}Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "cik",
- "exchange",
- "active",
- "delisted",
- "delisted_on",
- "sic",
- "industry",
- "other_share_classes",
- "url",
- "insiders_url",
- "holders_url",
- "sec_filings_url",
- "insider_activity",
- "f13",
- "superinvestors"
-]New value: +[
+ "ticker",
+ "name",
+ "cik",
+ "exchange",
+ "active",
+ "delisted",
+ "delisted_on",
+ "sic",
+ "industry",
+ "other_share_classes",
+ "url",
+ "insiders_url",
+ "holders_url",
+ "sec_filings_url",
+ "insider_activity",
+ "f13",
+ "superinvestors",
+ "financials",
+ "short_interest"
+]list_filingslist_short_interestget_politician2 fields changedOutput schema / properties / profileAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "age": {
+ "description": "Age today (US Eastern), for politicians in office only: the source has no date of death, so it is null for former members.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "birthday": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "committees": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chamber": {
+ "description": "house, senate or joint.",
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "side": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "subcommittees": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "side": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "anyOf": [
+ {
+ "enum": [
+ "chair",
+ "vice_chair",
+ "ranking_member",
+ "ex_officio",
+ "co_chair",
+ "other"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "chair, vice_chair, ranking_member, ex_officio, co_chair or other (the source's wording is in title_raw); null for a regular member."
+ },
+ "title_raw": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "side",
+ "title",
+ "title_raw"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "enum": [
+ "chair",
+ "vice_chair",
+ "ranking_member",
+ "ex_officio",
+ "co_chair",
+ "other"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "chair, vice_chair, ranking_member, ex_officio, co_chair or other (the source's wording is in title_raw); null for a regular member."
+ },
+ "title_raw": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "side",
+ "title",
+ "title_raw",
+ "chamber",
+ "url",
+ "subcommittees"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "district": {
+ "description": "House seat code of the latest term, e.g. CA-11; AK-AL for an at-large seat, DC-AL for a delegate; null for senators.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "leadership": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chamber": {
+ "type": "string"
+ },
+ "current": {
+ "type": "boolean"
+ },
+ "end": {
+ "description": "The end date, or null when the source gives none (the role is held).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "start": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "chamber",
+ "start",
+ "end",
+ "current"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "photo_url": {
+ "description": "Official portrait, 360x450 WebP, public domain; null when there is no photo.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "position": {
+ "description": "The seat in English, e.g. U.S. Representative for California's 11th district.",
+ "type": "string"
+ },
+ "social": {
+ "additionalProperties": false,
+ "properties": {
+ "facebook": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "instagram": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "mastodon": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "x": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "youtube": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "x",
+ "facebook",
+ "youtube",
+ "instagram",
+ "mastodon"
+ ],
+ "type": "object"
+ },
+ "website": {
+ "description": "Official website; politicians in office only.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "wikipedia_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "photo_url",
+ "position",
+ "district",
+ "birthday",
+ "age",
+ "website",
+ "social",
+ "wikipedia_url",
+ "leadership",
+ "committees"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "politician",
- "asset",
- "stats",
- "top_tickers",
- "note",
- "url"
-]New value: +[
+ "politician",
+ "profile",
+ "asset",
+ "stats",
+ "top_tickers",
+ "note",
+ "url"
+]get_congress_memberget_congress_tradesget_politicianget_politician_tradessearch4 fields changedInput schema / properties / query / descriptionPrevious value: -"Ticker, company, fund, manager, person or member of Congress name, CIK or CUSIP."New value: +"Ticker, company, fund, manager, person or politician name, CIK or CUSIP."Output schema / properties / membersRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "bioguide": {
- "type": "string"
- },
- "chamber": {
- "enum": [
- "house",
- "senate"
- ],
- "type": "string"
- },
- "district": {
- "type": [
- "number",
- "null"
- ]
- },
- "in_office": {
- "type": "boolean"
- },
- "name": {
- "type": "string"
- },
- "party": {
- "type": [
- "string",
- "null"
- ]
- },
- "state": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "bioguide",
- "name",
- "party",
- "chamber",
- "state",
- "district",
- "in_office",
- "url"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / politiciansAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bioguide": {
+ "type": "string"
+ },
+ "chamber": {
+ "enum": [
+ "house",
+ "senate"
+ ],
+ "type": "string"
+ },
+ "district": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "in_office": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "party": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "bioguide",
+ "name",
+ "party",
+ "chamber",
+ "state",
+ "district",
+ "in_office",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "query",
- "stocks",
- "institutions",
- "insiders",
- "members"
-]New value: +[
+ "query",
+ "stocks",
+ "institutions",
+ "insiders",
+ "politicians"
+]get_congress_member5 fields changedInput schema / properties / assetAdded value: +{
+ "default": "listed",
+ "description": "Which assets to include: listed (default) = listed securities, that is stocks including ADRs, ETFs and options; stock = listed stocks and ETFs without options; option = options; other = Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; all = everything. The statistics and top tickers cover these assets.",
+ "enum": [
+ "listed",
+ "stock",
+ "option",
+ "other",
+ "all"
+ ],
+ "type": "string"
+}Output schema / properties / assetAdded value: +{
+ "description": "The assets that stats and top_tickers cover.",
+ "enum": [
+ "listed",
+ "stock",
+ "option",
+ "other",
+ "all"
+ ],
+ "type": "string"
+}Output schema / properties / stats / properties / unlisted_tradesAdded value: +{
+ "description": "Trades in bonds, private holdings and other assets that are not listed securities, whatever asset is.",
+ "type": "number"
+}Output schema / properties / stats / requiredPrevious value: -[
- "trades",
- "buys",
- "sells",
- "estimated_volume_usd",
- "median_delay_days",
- "late_trades",
- "late_filings",
- "filings",
- "paper_filings",
- "latest_filed_date"
-]New value: +[
+ "trades",
+ "buys",
+ "sells",
+ "estimated_volume_usd",
+ "median_delay_days",
+ "late_trades",
+ "late_filings",
+ "unlisted_trades",
+ "filings",
+ "paper_filings",
+ "latest_filed_date"
+]Output schema / requiredPrevious value: -[
- "member",
- "stats",
- "top_tickers",
- "note",
- "url"
-]New value: +[
+ "member",
+ "asset",
+ "stats",
+ "top_tickers",
+ "note",
+ "url"
+]get_congress_trades3 fields changedInput schema / properties / assetAdded value: +{
+ "default": "listed",
+ "description": "Which assets to include: listed (default) = listed securities, that is stocks including ADRs, ETFs and options; stock = listed stocks and ETFs without options; option = options; other = Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; all = everything.",
+ "enum": [
+ "listed",
+ "stock",
+ "option",
+ "other",
+ "all"
+ ],
+ "type": "string"
+}Output schema / properties / filters / properties / assetAdded value: +{
+ "enum": [
+ "listed",
+ "stock",
+ "option",
+ "other",
+ "all"
+ ],
+ "type": "string"
+}Output schema / properties / filters / requiredPrevious value: -[
- "chamber",
- "party",
- "type",
- "filed_from",
- "filed_to",
- "traded_from",
- "traded_to",
- "sort"
-]New value: +[
+ "asset",
+ "chamber",
+ "party",
+ "type",
+ "filed_from",
+ "filed_to",
+ "traded_from",
+ "traded_to",
+ "sort"
+]get_congress_memberget_congress_tradesget_data_coverage6 fields changedOutput schema / properties / congressAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "earliest_filed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_filed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_filed_date",
+ "latest_filed_date",
+ "note"
+ ],
+ "type": "object"
+}Output schema / properties / last_successful_update / properties / congressAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / last_successful_update / requiredPrevious value: -[
- "sec_filings",
- "tickers",
- "cusip_mapping"
-]New value: +[
+ "sec_filings",
+ "tickers",
+ "cusip_mapping",
+ "congress"
+]Output schema / properties / not_yet_availableRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / ownershipAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "form144": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_filed_date": {
+ "type": "string"
+ },
+ "latest_filed_at": {
+ "type": "string"
+ },
+ "latest_filed_date": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_filed_date",
+ "latest_filed_at",
+ "latest_filed_date"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "schedule_13d": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_filed_date": {
+ "type": "string"
+ },
+ "latest_filed_at": {
+ "type": "string"
+ },
+ "latest_filed_date": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_filed_date",
+ "latest_filed_at",
+ "latest_filed_date"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "schedule_13g": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest_filed_date": {
+ "type": "string"
+ },
+ "latest_filed_at": {
+ "type": "string"
+ },
+ "latest_filed_date": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest_filed_date",
+ "latest_filed_at",
+ "latest_filed_date"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "schedule_13d",
+ "schedule_13g",
+ "form144",
+ "note"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "website",
- "sources",
- "form4",
- "f13",
- "superinvestors",
- "last_successful_update",
- "update_schedule",
- "not_yet_available",
- "limits",
- "docs_url",
- "llms_txt_url"
-]New value: +[
+ "website",
+ "sources",
+ "form4",
+ "f13",
+ "superinvestors",
+ "ownership",
+ "congress",
+ "last_successful_update",
+ "update_schedule",
+ "limits",
+ "docs_url",
+ "llms_txt_url"
+]get_form144_noticesget_major_holdersget_ownership_filingssearch3 fields changedInput schema / properties / query / descriptionPrevious value: -"Ticker, company, fund, manager or person name."New value: +"Ticker, company, fund, manager, person or member of Congress name, CIK or CUSIP."Output schema / properties / membersAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bioguide": {
+ "type": "string"
+ },
+ "chamber": {
+ "enum": [
+ "house",
+ "senate"
+ ],
+ "type": "string"
+ },
+ "district": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "in_office": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "party": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "bioguide",
+ "name",
+ "party",
+ "chamber",
+ "state",
+ "district",
+ "in_office",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "query",
- "stocks",
- "institutions",
- "insiders"
-]New value: +[
+ "query",
+ "stocks",
+ "institutions",
+ "insiders",
+ "members"
+]get_insider_lists1 field changedOutput schema / properties / trades / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "accession": {
- "type": "string"
- },
- "acquired_or_disposed": {
- "anyOf": [
- {
- "enum": [
- "acquired",
- "disposed"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amendment": {
- "type": "boolean"
- },
- "avg_price_usd": {
- "type": [
- "number",
- "null"
- ]
- },
- "code": {
- "type": [
- "string",
- "null"
- ]
- },
- "derivative": {
- "type": "boolean"
- },
- "filed_at": {
- "type": "string"
- },
- "filed_date": {
- "type": "string"
- },
- "insider_cik": {
- "type": [
- "string",
- "null"
- ]
- },
- "insider_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "insider_roles": {
- "items": {
- "enum": [
- "director",
- "officer",
- "ten_percent_owner",
- "other"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "insider_title": {
- "type": [
- "string",
- "null"
- ]
- },
- "issuer_cik": {
- "type": "string"
- },
- "issuer_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "lots": {
- "type": "number"
- },
- "ownership": {
- "anyOf": [
- {
- "enum": [
- "direct",
- "indirect"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "ownership_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "price_outlier": {
- "type": "boolean"
- },
- "reporting_owners": {
- "type": "number"
- },
- "rule_10b5_1": {
- "type": [
- "boolean",
- "null"
- ]
- },
- "sec_url": {
- "type": "string"
- },
- "security_title": {
- "type": [
- "string",
- "null"
- ]
- },
- "shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "shares_owned_after": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "trade_date_first": {
- "type": [
- "string",
- "null"
- ]
- },
- "trade_date_last": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- },
- "value_usd": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "accession",
- "filed_at",
- "filed_date",
- "trade_date_first",
- "trade_date_last",
- "ticker",
- "issuer_cik",
- "issuer_name",
- "insider_cik",
- "insider_name",
- "insider_roles",
- "insider_title",
- "reporting_owners",
- "code",
- "acquired_or_disposed",
- "derivative",
- "security_title",
- "ownership",
- "shares",
- "avg_price_usd",
- "value_usd",
- "shares_owned_after",
- "ownership_change_pct",
- "lots",
- "rule_10b5_1",
- "amendment",
- "price_outlier",
- "url",
- "sec_url"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "accession": {
+ "type": "string"
+ },
+ "acquired_or_disposed": {
+ "anyOf": [
+ {
+ "enum": [
+ "acquired",
+ "disposed"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amendment": {
+ "type": "boolean"
+ },
+ "avg_price_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "carried_from": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "derivative": {
+ "type": "boolean"
+ },
+ "filed_at": {
+ "type": "string"
+ },
+ "filed_date": {
+ "type": "string"
+ },
+ "insider_cik": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "insider_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "insider_roles": {
+ "items": {
+ "enum": [
+ "director",
+ "officer",
+ "ten_percent_owner",
+ "other"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "insider_title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "issuer_cik": {
+ "type": "string"
+ },
+ "issuer_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "lots": {
+ "type": "number"
+ },
+ "ownership": {
+ "anyOf": [
+ {
+ "enum": [
+ "direct",
+ "indirect"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ownership_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price_outlier": {
+ "type": "boolean"
+ },
+ "reporting_owners": {
+ "type": "number"
+ },
+ "rule_10b5_1": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "sec_url": {
+ "type": "string"
+ },
+ "security_title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shares_owned_after": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trade_date_first": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trade_date_last": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "accession",
+ "filed_at",
+ "filed_date",
+ "trade_date_first",
+ "trade_date_last",
+ "ticker",
+ "issuer_cik",
+ "issuer_name",
+ "insider_cik",
+ "insider_name",
+ "insider_roles",
+ "insider_title",
+ "reporting_owners",
+ "code",
+ "acquired_or_disposed",
+ "derivative",
+ "security_title",
+ "ownership",
+ "shares",
+ "avg_price_usd",
+ "value_usd",
+ "shares_owned_after",
+ "ownership_change_pct",
+ "lots",
+ "rule_10b5_1",
+ "amendment",
+ "carried_from",
+ "price_outlier",
+ "url",
+ "sec_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]get_insider_trades2 fields changedOutput schema / properties / rows / items / properties / carried_fromAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / rows / items / requiredPrevious value: -[
- "accession",
- "filed_at",
- "filed_date",
- "trade_date_first",
- "trade_date_last",
- "ticker",
- "issuer_cik",
- "issuer_name",
- "insider_cik",
- "insider_name",
- "insider_roles",
- "insider_title",
- "reporting_owners",
- "code",
- "acquired_or_disposed",
- "derivative",
- "security_title",
- "ownership",
- "shares",
- "avg_price_usd",
- "value_usd",
- "shares_owned_after",
- "ownership_change_pct",
- "lots",
- "rule_10b5_1",
- "amendment",
- "price_outlier",
- "url",
- "sec_url"
-]New value: +[
+ "accession",
+ "filed_at",
+ "filed_date",
+ "trade_date_first",
+ "trade_date_last",
+ "ticker",
+ "issuer_cik",
+ "issuer_name",
+ "insider_cik",
+ "insider_name",
+ "insider_roles",
+ "insider_title",
+ "reporting_owners",
+ "code",
+ "acquired_or_disposed",
+ "derivative",
+ "security_title",
+ "ownership",
+ "shares",
+ "avg_price_usd",
+ "value_usd",
+ "shares_owned_after",
+ "ownership_change_pct",
+ "lots",
+ "rule_10b5_1",
+ "amendment",
+ "carried_from",
+ "price_outlier",
+ "url",
+ "sec_url"
+]get_stock2 fields changedOutput schema / properties / delisted_onAdded value: +{
+ "description": "Delisting date (YYYY-MM-DD) of a delisted stock: the SEC filing date of the Form 25 that removed its common stock from the exchange. null when the stock is not delisted or no Form 25 was found (for example a company that kept trading over the counter).",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "cik",
- "exchange",
- "active",
- "delisted",
- "sic",
- "industry",
- "other_share_classes",
- "url",
- "insiders_url",
- "holders_url",
- "sec_filings_url",
- "insider_activity",
- "f13",
- "superinvestors"
-]New value: +[
+ "ticker",
+ "name",
+ "cik",
+ "exchange",
+ "active",
+ "delisted",
+ "delisted_on",
+ "sic",
+ "industry",
+ "other_share_classes",
+ "url",
+ "insiders_url",
+ "holders_url",
+ "sec_filings_url",
+ "insider_activity",
+ "f13",
+ "superinvestors"
+]get_institution2 fields changedOutput schema / properties / holdings / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "has_more": {
- "type": "boolean"
- },
- "limit": {
- "type": "number"
- },
- "page": {
- "type": "number"
- },
- "rows": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "action": {
- "anyOf": [
- {
- "enum": [
- "new",
- "added",
- "reduced",
- "unchanged",
- "sold_out",
- "not_filed"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "cusip": {
- "type": "string"
- },
- "holding_history_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "name_of_issuer": {
- "type": [
- "string",
- "null"
- ]
- },
- "pct_of_portfolio": {
- "type": [
- "number",
- "null"
- ]
- },
- "previous_shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "previous_value_usd": {
- "type": [
- "number",
- "null"
- ]
- },
- "share_change": {
- "type": [
- "number",
- "null"
- ]
- },
- "share_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "title_of_class": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- },
- "value_usd": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "ticker",
- "cusip",
- "name_of_issuer",
- "title_of_class",
- "shares",
- "value_usd",
- "pct_of_portfolio",
- "previous_shares",
- "previous_value_usd",
- "share_change",
- "share_change_pct",
- "action",
- "url",
- "holding_history_url"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "sort": {
- "type": "string"
- }
- },
- "required": [
- "sort",
- "page",
- "limit",
- "has_more",
- "rows"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "has_more": {
+ "type": "boolean"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "page": {
+ "type": "number"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "anyOf": [
+ {
+ "enum": [
+ "new",
+ "added",
+ "reduced",
+ "unchanged",
+ "sold_out",
+ "not_filed"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cusip": {
+ "type": "string"
+ },
+ "holding_history_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name_of_issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pct_of_portfolio": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "previous_shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "previous_value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock split between the two quarters: new shares per old share (10 = 10-for-1, 0.1 = 1-for-10 reverse split); previous_shares is converted by it. null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_of_class": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "cusip",
+ "name_of_issuer",
+ "title_of_class",
+ "shares",
+ "value_usd",
+ "pct_of_portfolio",
+ "previous_shares",
+ "previous_value_usd",
+ "share_change",
+ "share_change_pct",
+ "split_factor",
+ "action",
+ "url",
+ "holding_history_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "sort",
+ "page",
+ "limit",
+ "has_more",
+ "rows"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / sold_out / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "rows": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "action": {
- "anyOf": [
- {
- "enum": [
- "new",
- "added",
- "reduced",
- "unchanged",
- "sold_out",
- "not_filed"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "cusip": {
- "type": "string"
- },
- "holding_history_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "name_of_issuer": {
- "type": [
- "string",
- "null"
- ]
- },
- "pct_of_portfolio": {
- "type": [
- "number",
- "null"
- ]
- },
- "previous_shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "previous_value_usd": {
- "type": [
- "number",
- "null"
- ]
- },
- "share_change": {
- "type": [
- "number",
- "null"
- ]
- },
- "share_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "title_of_class": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- },
- "value_usd": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "ticker",
- "cusip",
- "name_of_issuer",
- "title_of_class",
- "shares",
- "value_usd",
- "pct_of_portfolio",
- "previous_shares",
- "previous_value_usd",
- "share_change",
- "share_change_pct",
- "action",
- "url",
- "holding_history_url"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "total": {
- "type": "number"
- }
- },
- "required": [
- "total",
- "rows"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "rows": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "anyOf": [
+ {
+ "enum": [
+ "new",
+ "added",
+ "reduced",
+ "unchanged",
+ "sold_out",
+ "not_filed"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cusip": {
+ "type": "string"
+ },
+ "holding_history_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name_of_issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pct_of_portfolio": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "previous_shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "previous_value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock split between the two quarters: new shares per old share (10 = 10-for-1, 0.1 = 1-for-10 reverse split); previous_shares is converted by it. null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_of_class": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "cusip",
+ "name_of_issuer",
+ "title_of_class",
+ "shares",
+ "value_usd",
+ "pct_of_portfolio",
+ "previous_shares",
+ "previous_value_usd",
+ "share_change",
+ "share_change_pct",
+ "split_factor",
+ "action",
+ "url",
+ "holding_history_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "rows"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]get_stock_13f_holders2 fields changedOutput schema / properties / split_factorAdded value: +{
+ "description": "Stock split between previous_quarter and quarter: new shares per old share (10 = 10-for-1 split, 0.1 = 1-for-10 reverse split); null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "quarter",
- "period",
- "previous_quarter",
- "latest_complete_quarter",
- "in_progress_quarter",
- "holders",
- "shares",
- "value_usd",
- "previous",
- "changes_available",
- "note",
- "sort",
- "page",
- "limit",
- "has_more",
- "rows",
- "url"
-]New value: +[
+ "ticker",
+ "name",
+ "quarter",
+ "period",
+ "previous_quarter",
+ "latest_complete_quarter",
+ "in_progress_quarter",
+ "holders",
+ "shares",
+ "value_usd",
+ "previous",
+ "changes_available",
+ "split_factor",
+ "note",
+ "sort",
+ "page",
+ "limit",
+ "has_more",
+ "rows",
+ "url"
+]get_superinvestor_activity1 field changedOutput schema / properties / superinvestor / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "added": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "cusip": {
- "type": "string"
- },
- "name_of_issuer": {
- "type": [
- "string",
- "null"
- ]
- },
- "shares_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "title_of_class": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "ticker",
- "cusip",
- "name_of_issuer",
- "title_of_class",
- "url",
- "shares_change_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "cik": {
- "type": "string"
- },
- "counts": {
- "additionalProperties": false,
- "properties": {
- "added": {
- "type": "number"
- },
- "new": {
- "type": "number"
- },
- "reduced": {
- "type": "number"
- },
- "sold_out": {
- "type": "number"
- }
- },
- "required": [
- "new",
- "added",
- "reduced",
- "sold_out"
- ],
- "type": "object"
- },
- "filed_current": {
- "type": "boolean"
- },
- "filed_previous": {
- "type": "boolean"
- },
- "manager": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "new": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "cusip": {
- "type": "string"
- },
- "name_of_issuer": {
- "type": [
- "string",
- "null"
- ]
- },
- "shares_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "title_of_class": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "ticker",
- "cusip",
- "name_of_issuer",
- "title_of_class",
- "url",
- "shares_change_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "note": {
- "type": [
- "string",
- "null"
- ]
- },
- "reduced": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "cusip": {
- "type": "string"
- },
- "name_of_issuer": {
- "type": [
- "string",
- "null"
- ]
- },
- "shares_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "title_of_class": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "ticker",
- "cusip",
- "name_of_issuer",
- "title_of_class",
- "url",
- "shares_change_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "sold_out": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "cusip": {
- "type": "string"
- },
- "name_of_issuer": {
- "type": [
- "string",
- "null"
- ]
- },
- "shares_change_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "ticker": {
- "type": [
- "string",
- "null"
- ]
- },
- "title_of_class": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "ticker",
- "cusip",
- "name_of_issuer",
- "title_of_class",
- "url",
- "shares_change_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "url": {
- "type": "string"
- },
- "value_usd": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "cik",
- "name",
- "manager",
- "filed_current",
- "filed_previous",
- "note",
- "value_usd",
- "counts",
- "new",
- "added",
- "reduced",
- "sold_out",
- "url"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "added": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cusip": {
+ "type": "string"
+ },
+ "name_of_issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shares_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock split between the two quarters that shares_change_pct was converted for: new shares per old share (10 = 10-for-1, 0.1 = 1-for-10 reverse split); null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_of_class": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "cusip",
+ "name_of_issuer",
+ "title_of_class",
+ "url",
+ "shares_change_pct",
+ "split_factor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cik": {
+ "type": "string"
+ },
+ "counts": {
+ "additionalProperties": false,
+ "properties": {
+ "added": {
+ "type": "number"
+ },
+ "new": {
+ "type": "number"
+ },
+ "reduced": {
+ "type": "number"
+ },
+ "sold_out": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "new",
+ "added",
+ "reduced",
+ "sold_out"
+ ],
+ "type": "object"
+ },
+ "filed_current": {
+ "type": "boolean"
+ },
+ "filed_previous": {
+ "type": "boolean"
+ },
+ "manager": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "new": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cusip": {
+ "type": "string"
+ },
+ "name_of_issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shares_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock split between the two quarters that shares_change_pct was converted for: new shares per old share (10 = 10-for-1, 0.1 = 1-for-10 reverse split); null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_of_class": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "cusip",
+ "name_of_issuer",
+ "title_of_class",
+ "url",
+ "shares_change_pct",
+ "split_factor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reduced": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cusip": {
+ "type": "string"
+ },
+ "name_of_issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shares_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock split between the two quarters that shares_change_pct was converted for: new shares per old share (10 = 10-for-1, 0.1 = 1-for-10 reverse split); null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_of_class": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "cusip",
+ "name_of_issuer",
+ "title_of_class",
+ "url",
+ "shares_change_pct",
+ "split_factor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sold_out": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cusip": {
+ "type": "string"
+ },
+ "name_of_issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shares_change_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "split_factor": {
+ "description": "Stock split between the two quarters that shares_change_pct was converted for: new shares per old share (10 = 10-for-1, 0.1 = 1-for-10 reverse split); null when there was none.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_of_class": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "cusip",
+ "name_of_issuer",
+ "title_of_class",
+ "url",
+ "shares_change_pct",
+ "split_factor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ },
+ "value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "cik",
+ "name",
+ "manager",
+ "filed_current",
+ "filed_previous",
+ "note",
+ "value_usd",
+ "counts",
+ "new",
+ "added",
+ "reduced",
+ "sold_out",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]get_stock4 fields changedOutput schema / properties / active / descriptionAdded value: +"false when the ticker is no longer on the SEC's list of tickers."Output schema / properties / delistedAdded value: +{
+ "description": "true when the ticker is inactive and the company has no active common-stock ticker left (delisted or acquired). An inactive ticker whose company still trades under another ticker (a ticker change) is not delisted.",
+ "type": "boolean"
+}Output schema / properties / f13 / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "holders": {
- "type": "number"
- },
- "in_progress_quarter": {
- "type": [
- "string",
- "null"
- ]
- },
- "latest_complete_quarter": {
- "type": "string"
- },
- "period": {
- "type": "string"
- },
- "previous": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "holders": {
- "type": "number"
- },
- "period": {
- "type": "string"
- },
- "quarter": {
- "type": "string"
- },
- "shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "value_usd": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "quarter",
- "period",
- "holders",
- "shares",
- "value_usd"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "quarter": {
- "type": "string"
- },
- "shares": {
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- },
- "value_usd": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "quarter",
- "period",
- "latest_complete_quarter",
- "in_progress_quarter",
- "holders",
- "shares",
- "value_usd",
- "previous",
- "url"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "holders": {
+ "type": "number"
+ },
+ "in_progress_quarter": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_complete_quarter": {
+ "type": "string"
+ },
+ "note": {
+ "description": "Why the quarter is older than latest_complete_quarter (inactive tickers).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "period": {
+ "type": "string"
+ },
+ "previous": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "holders": {
+ "type": "number"
+ },
+ "period": {
+ "type": "string"
+ },
+ "quarter": {
+ "type": "string"
+ },
+ "shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "quarter",
+ "period",
+ "holders",
+ "shares",
+ "value_usd"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "quarter": {
+ "type": "string"
+ },
+ "shares": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "quarter",
+ "period",
+ "latest_complete_quarter",
+ "in_progress_quarter",
+ "holders",
+ "shares",
+ "value_usd",
+ "previous",
+ "note",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "cik",
- "exchange",
- "active",
- "sic",
- "industry",
- "other_share_classes",
- "url",
- "insiders_url",
- "holders_url",
- "sec_filings_url",
- "insider_activity",
- "f13",
- "superinvestors"
-]New value: +[
+ "ticker",
+ "name",
+ "cik",
+ "exchange",
+ "active",
+ "delisted",
+ "sic",
+ "industry",
+ "other_share_classes",
+ "url",
+ "insiders_url",
+ "holders_url",
+ "sec_filings_url",
+ "insider_activity",
+ "f13",
+ "superinvestors"
+]get_stock_13f_holders1 field changedInput schema / properties / quarter / descriptionPrevious value: -"Quarter to show, e.g. 2026-q2. Default: the latest complete quarter."New value: +"Quarter to show, e.g. 2026-q2. Default: the latest complete quarter; for a ticker that is no longer listed, its last quarter with a full set of 13F holders."search2 fields changedOutput schema / properties / stocks / items / properties / activeAdded value: +{
+ "description": "false when the ticker is no longer on the SEC's list of tickers (the company was delisted or changed its ticker); its page and history are still available.",
+ "type": "boolean"
+}Output schema / properties / stocks / items / requiredPrevious value: -[
- "ticker",
- "name",
- "url"
-]New value: +[
+ "ticker",
+ "name",
+ "active",
+ "url"
+]get_data_coverageget_insider_listsget_insider_tradesget_institutionget_stockget_stock_13f_holdersget_superinvestor_activitylist_superinvestorssearchFree US market data as tools: SEC filings, insiders, short interest, 13F, COT, Fed liquidity.
Insider, Congress, 13F and federal contract filings for US stocks, each linked to its source.
SEC filings, insider trades, and earnings data
Insidewell: SEC Form 4 insider buys/sells by ticker or whole market, with cluster-buy alerts.
Add one secure layer between your agents and this server.