secedgar-mcp-server
Server Details
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/secedgar-mcp-server
- GitHub Stars
- 10
- Server Listing
- @cyanheads/secedgar-mcp-server
TDQS
Scored across 16 tools
Each tool targets a distinct resource and action, with descriptions explicitly cross-referencing related tools (e.g., get_financials vs get_snapshot vs compare_companies, and the three ownership directions: manager portfolio, issuer-to-managers, and issuer-to-beneficial-owners). No two tools can be confused for the same operation, even in dense areas like XBRL access and filings search.
All tools share the secedgar_prefix and snake_case, generally following a verb_noun pattern (get_filing, search_filings, fetch_frames). Minor deviations occur in noun-first names like company_search, dataframe_describe, and dataframe_query, which break the otherwise consistent verb-first convention.
16 tools is slightly above the typical 3-15 range but justified by the broad SEC EDGAR domain, which spans entity resolution, filings search/retrieval, XBRL financials, ownership tracking, and dataframe analysis. No tools appear redundant or unnecessary, though the set is on the heavier side.
The surface covers a wide range of read-only EDGAR workflows: entity search, full-text filings search, financial concept discovery, snapshots, comparisons, frames, insider and institutional ownership, fund holdings, beneficial owners, material events, and dataframe analysis. Minor gaps remain, such as no dedicated tool for retrieving filing exhibits/attachments (e.g., EX-99 press releases) or structured proxy statement content.
Available Tools
16 toolssecedgar_company_searchSecedgar Company SearchARead-onlyIdempotentInspect
Find companies and retrieve entity info with optional recent filings. Entry point for most EDGAR workflows — resolves tickers, names, or CIKs to entity details, with accession numbers in the result feeding secedgar_get_filing for document content. When a date or form filter carries the scan past the recent submissions window, the full filtered filing history is also staged as df_ — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company ticker symbol (e.g., "AAPL", "VOO"), name (e.g., "Apple"), or CIK number (e.g., "320193"). Ticker is the fastest lookup and works for equities, ETFs, and mutual funds; a multi-class share ticker resolves in either form ("BRK-B" or "BRK.B"). Name search matches current and former names, and the corporate suffix does not have to match the registry's form ("Beacon Financial Corporation" finds "Beacon Financial Corp") — but Corp, Inc, Co, and Ltd stay distinct from each other, since separate registrants differ only by which one they use. | |
| form_types | No | Filter filings to specific form types (e.g., ["10-K", "10-Q", "8-K"]). Without this, returns all form types. | |
| filed_after | No | Only include filings filed on or after this date (YYYY-MM-DD). A date filter routes the scan into the older submissions archive pages, so it reaches filings that predate the ~1000-filing recent window (e.g. a company's 2005 10-K). | |
| filed_before | No | Only include filings filed on or before this date (YYYY-MM-DD). Use alone or with filed_after; together they bound the archive-page scan. | |
| filing_limit | No | Maximum number of filings to return in the inline list. | |
| include_filings | No | Include recent filings in the response. Set to false for entity-info-only lookups. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The `filing_limit` that was applied. |
| cik | No | Central Index Key, zero-padded to 10 digits. |
| sic | No | SIC industry code. |
| name | No | SEC-conformed company name. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of filings returned inline. |
| notice | No | Guidance when include_filings=true but no filings matched the form_types filter, or when filing_limit withheld some. |
| dataset | No | Canvas dataframe holding the full filtered filing history (recent + archive pages), registered only when the scan reached beyond the recent window and the history exceeds filing_limit. Query the complete history — filings by form by year — with secedgar_dataframe_query; the inline `filings` list stays capped at filing_limit. |
| filings | No | Recent filings, filtered by form_types if specified. |
| tickers | No | Associated ticker symbols. |
| class_id | No | SEC fund class ID (e.g. "C000092055"). Present when the query resolved via a fund ticker (ETF or mutual fund). |
| exchanges | No | Exchanges where listed. |
| series_id | No | SEC fund series ID (e.g. "S000002839"). Present when the query resolved via a fund ticker (ETF or mutual fund). |
| truncated | No | True when more filings matched than `filing_limit` allowed into the inline list. |
| total_filings | No | Total filings matching the filter across everything scanned (recent window + any archive pages), which may exceed filing_limit and the inline list. |
| fiscal_year_end | No | Fiscal year end (MM-DD format, e.g., "09-26"). Absent for filers SEC records no fiscal year end for (e.g. private or pre-IPO entities). |
| sic_description | No | Human-readable SIC description. |
| state_of_incorporation | No | State of incorporation (US two-letter code, e.g. "DE"). Omitted for some entities, including many foreign filers and individuals. |
| history_scanned_through | No | Oldest filing date reached by the scan (YYYY-MM-DD). Filings older than this were not examined: the recent window caps at ~1000 filings, and older filings live in archive pages fetched only when a date filter or an under-filled form filter requires them. Absent when no filings were scanned. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent hints. The description adds a crucial behavioral detail: staging the full filtered filing history as df_<id> when date/form filters exceed the recent window. This is beyond the annotations and directly affects agent expectations, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff. The first sentence front-loads purpose; the second packs workflow routing and side-effect disclosure. Every clause earns its place, making it dense yet readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's role as entry point, how results feed downstream tools (secedgar_get_filing), and the dataframe staging behavior. With an output schema present and 100% parameter schema coverage, nothing essential is missing for an agent to call and chain 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% with descriptive text for each parameter. The description itself adds minimal new meaning to parameters beyond reiterating the query resolution modes (ticker/name/CIK) and the staging effect tied to date/form filters, which is already implied by schema. It does not significantly enhance parameter understanding, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('Find companies and retrieve entity info') and explains the resolution of tickers, names, or CIKs. It explicitly differentiates from siblings by positioning itself as the entry point and naming downstream tools like secedgar_get_filing, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly declares 'Entry point for most EDGAR workflows' and provides conditional guidance: when filters push past the recent window, a dataframe is staged for secedgar_dataframe_describe/query. This tells the agent exactly when to use this tool and what to do next, with clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_compare_companiesSecedgar Compare CompaniesARead-onlyIdempotentInspect
Compare 2-10 named companies across 1-8 XBRL concepts, aligned on calendar periods. This is the middle shape between secedgar_get_financials (one company, one concept, full history) and secedgar_fetch_frames (one concept, one period, every reporting company) — reach for it when the question names the companies. One companyfacts read per company, resolved through the same frame dedup and tag priority as secedgar_get_financials so the numbers agree. Balance-sheet and entity-info concepts are filed as point-in-time values and align on the calendar year (annual) or quarter (quarterly) their snapshot falls in, so they sit in the same matrix as income-statement lines. The inline matrix covers the most recent periods up to periods, trimmed further when companies x concepts x periods is too large to return in one response; the full aligned series is materialized as df_ for growth rates and spreads — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query. A company that fails to resolve is reported in failed_companies and the comparison proceeds with the rest, and a company that does not report a concept is reported in gaps with the tags that were tried — never interpolated or zero-filled. Off-calendar filers and unit mismatches are surfaced in caveats rather than silently mixed.
| Name | Required | Description | Default |
|---|---|---|---|
| periods | No | Upper bound on how many recent periods the inline matrix covers, newest first — not a guarantee. The matrix is companies x concepts x periods cells, and the inline window drops further older periods when that product is too large to return in one response. The full aligned series is always registered to the dataframe, so dropped periods stay queryable via secedgar_dataframe_query. | |
| concepts | Yes | Concepts to compare — friendly names like "revenue" or "net_income" (discover them with secedgar_search_concepts) or raw XBRL tags. | |
| taxonomy | No | XBRL taxonomy to resolve concepts under. Use ifrs-full only when every company in the list reports under IFRS; mixing IFRS and US GAAP filers in one call resolves them all under the same taxonomy. | us-gaap |
| companies | Yes | Companies to compare, as ticker symbols (preferred) or CIK numbers. A company that does not resolve is reported in failed_companies and the rest of the comparison still runs. | |
| period_type | No | Align on full calendar years (annual) or calendar quarters (quarterly). Quarterly comparisons of off-calendar filers are missing at least one calendar quarter per year — see caveats. | annual |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The periods cap applied. |
| gaps | No | Company-concept pairs with no data. Deliberately explicit — a missing value is never interpolated or zero-filled. |
| cells | No | Inline matrix values, covering the periods listed in periods[]. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of periods shown inline. |
| notice | No | Guidance when the inline matrix dropped periods, or when the full aligned series is staged as a dataframe. |
| caveats | No | Comparability warnings: a filer missing one or two calendar quarters from the frame-tagged series, a concept whose values stop at least two full years behind the rest of that company's reporting (either an XBRL tag SEC has retired, or a current tag the filer stopped using), period ends that differ inside one aligned period, and concepts whose unit differs across companies. Company-specific warnings are prefixed with the company name. Empty when nothing needs flagging. |
| dataset | No | Canvas dataframe holding the full aligned series across every period, not just the inline window. Columns match cells[]. Absent when canvas is unavailable. |
| periods | No | Calendar period keys covered by the inline matrix, newest first. Shorter than the requested periods when the cell count forced the window to shrink — the enrichment trailer reports the drop. |
| concepts | No | Concepts covered, in the order supplied. |
| taxonomy | No | Taxonomy the concepts were resolved under, echoed from input. |
| companies | No | Companies included in the comparison. |
| truncated | No | True when the aligned series has more periods than the inline matrix shows. |
| period_type | No | Period alignment used, echoed from input. |
| failed_companies | No | Companies excluded from the matrix. The comparison proceeds with the rest rather than failing the whole call. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context that annotations cannot: it explains the companyfacts read strategy, deduplication and tag-priority alignment, point-in-time vs flow concept handling, period trimming behavior when the matrix is too large, failed-company handling, gap reporting without interpolation or zero-filling, and surfacing of off-calendar and unit mismatches in caveats. No annotation inconsistency exists.
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 front-loaded with the purpose and sibling contrast before getting into behavioral details. It is above average in length, but every clause earns its place, covering output trimming, error handling, alignment semantics, no-imputation guarantees, and later route to data frames. There is no tautology or filler; the apparent density serves complexity.
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 (5 params, up to 10 companies, up to 8 concepts), the description is complete enough. It explains behavior for every major scenario: multiple companies, missing concepts, failed resolves, period alignment, file sizing, and the dataframe output. The presence of an output schema means the return format need not be restated; and the description fully covers what can only be expressed in prose.
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 elevates it significantly by clarifying latent semantics of periods ('not a guarantee' and trimming behavior), taxonomy (mixing IFRS and US GAAP resolves under one taxonomy), companies (unresolved entries go to failed_companies), and period_type (off-calendar quarterly comparisons gloss a missing quarter). This go-by-effect guidance for each parameter, crucially informing how parameters trade off, is exactly the value a description should add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Compare 2-10 named companies across 1-8 XBRL concepts, aligned on calendar periods.' It explicitly distinguishes the tool from its siblings by framing it as the middle shape between secedgar_get_financials and secedgar_fetch_frames, naming both. An agent can determine exactly what this tool does and how it differs from related tools without inspecting their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'reach for it when the question names the companies,' giving an explicit selection rule that separates it from sibling tools. It also states when NOT to use it indirectly by contrasting with get_financials (one company, one concept, full history) and fetch_frames (one concept, every company). It additionally routes follow-up analysis to secedgar_dataframe_describe and secedgar_dataframe_query, completing the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_dataframe_describeSecedgar Dataframe DescribeARead-onlyIdempotentInspect
List the dataframes (df_XXXXX_XXXXX) registered by the data-returning secedgar_* tools — any tool whose response carries a dataset handle stages its full result set here. Each entry surfaces source tool, query parameters, creation/expiry timestamps, row count, column schema, and whether the dataframe is truncated relative to the upstream source. Read the column schema here before writing SQL for secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional table name (df_XXXXX_XXXXX) to describe a single dataframe. Omit to list all dataframes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| dataframes | No | Active dataframes for this tenant, newest first. Empty when none are registered. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description reveals that data-returning tools stage full result sets, that entries include source tool, query parameters, timestamps, row count, column schema, and truncation status, and that dataframes have expiry. This is substantial behavioral context with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The purpose is front-loaded, the entry contents are listed compactly, and the final sentence gives actionable guidance for the related query 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 a read-only metadata-list tool with one optional parameter, an output schema, and rich annotations, the description covers what the tool returns, how dataframes come to exist, and how to use the information. Nothing essential 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?
The schema already documents the optional name parameter at 100% coverage, so the description adds no new semantic value for the single parameter. Baseline 3 is appropriate because schema handles 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 ('List') and a precise resource: dataframes registered by data-returning secedgar_* tools. It also identifies the naming pattern and distinguishes the describe function from the downstream SQL query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: inspect the dataframe catalog and column schemas before writing SQL against secedgar_dataframe_query. It stops short of naming explicit when-not-to-use alternatives, but the workflow guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_dataframe_querySecedgar Dataframe QueryARead-onlyIdempotentInspect
Run a single-statement SELECT against the canvas dataframes registered by the data-returning secedgar_* tools — any tool whose response carries a dataset handle. Inspect a dataframe with secedgar_dataframe_describe first; its column schema is what the SQL has to match. Read-only: writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file table functions are rejected. System catalogs (information_schema, pg_catalog, sqlite_master, duckdb_*) are denied — list dataframes via secedgar_dataframe_describe. Optional register_as chains the result as a new dataframe with a fresh TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Single-statement SELECT against df_<id> tables on the shared canvas. Standard DuckDB SQL — joins, aggregates, window functions, CTEs all supported. Reference dataframes by the names returned in fetch/search responses or listed by secedgar_dataframe_describe. BIGINT columns (e.g., XBRL `value`, COUNT/SUM results) serialize as JSON strings to preserve precision past 2^53 — CAST(col AS DOUBLE) in projections for inline arithmetic. | |
| preview | No | Rows to include in the immediate response. Defaults to the row limit. Set lower (e.g., 50) when chaining via register_as and only a sample is needed inline. | |
| row_limit | No | Hard cap on rows materialized in the response. Default 1000, max 10000. A query matching more rows than this stops at the cap and `row_count_capped` comes back true; the full result lives on-canvas under register_as when provided, so do not raise this to keep large results. One case is not detectable: a SQL LIMIT exactly equal to this cap reads identically to a result that genuinely holds that many rows, and is reported as exact. | |
| register_as | No | When set, persist the result as a new dataframe under this name (must match df_XXXXX_XXXXX shape, or pass a fresh df_<id> generated by the agent). Fresh TTL window — not inherited from the parents in the SELECT. Use to chain analyses without re-running the source SQL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The row cap that actually bound — `preview` when it is lower than `row_limit`, otherwise `row_limit`. |
| rows | No | Materialized rows, bounded by `preview` / `row_limit`. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of rows returned inline. |
| notice | No | Guidance when the query returned no rows, or when the row cap withheld some. |
| columns | No | Column names in projection order. |
| row_count | No | Rows the query produced, up to `row_limit` (exceeds `rows.length` when `preview` returned fewer). Read it with `row_count_capped`: when that is true this number is the `row_limit` cap itself, and the size of the full result is not in this response. |
| truncated | No | True when the result set held more rows than the row cap allowed through. |
| expires_at | No | ISO 8601 expiry timestamp for the newly registered dataframe, when applicable. |
| registered_as | No | Set when `register_as` was supplied and the new dataframe was materialized. |
| row_count_capped | No | True when the query matched more rows than `row_limit`, so `row_count` is that cap rather than a total. False means `row_count` is exact — including when it happens to equal `row_limit`. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses what SQL constructs are blocked, the 10000-row hard cap and default 1000, the row_count_capped flag, BIGINT-to-string serialization, the register_as TTL behavior, and an edge case where an explicit LIMIT equal to the cap is indistinguishable from an exact result. This is substantial, actionable behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-organized: the top line states the core action, then each parameter block adds necessary detail (defaults, caps, edge cases). Long-ish, but every sentence conveys useful behavioral or semantic information; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the full operational envelope: which SQL is allowed/denied, how to find dataframes, row cap semantics with the exact-equality edge case, BIGINT precision behavior, and chainability via register_as with TTL note. With an output schema present, nothing essential 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% and both the description and param descriptions are rich, so the baseline is 3. The description adds extra meaning: how to reference dataframe names from search/describe outputs, explicit casting guidance for BIGINT columns, and the practical suggestion to lower preview when chaining with register_as. This elevates it to 4.
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 is explicit: it names the tool's action ('Run a single-statement SELECT...') and specific object ('dataframes on the shared canvas'). It clearly distinguishes this tool from its sibling secedgar_dataframe_describe, noting it performs queries while the sibling handles schema discovery. The verb+resource+scope make the purpose unmistakable.
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 states when to use this tool (querying the dataframe canvas with standard SQL, joins/aggregates/window functions), and explicitly routes schema discovery to secedgar_dataframe_describe. It also gives concrete usage guidance around preview vs row_limit and chaining queries with register_as, plus warnings about not raising row_limit for large results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_fetch_framesSecedgar Fetch FramesARead-onlyIdempotentInspect
Fetch SEC XBRL frames for one concept × one period across all reporting companies. Inline response returns a page of the ranked companies — start at the top or pass offset/next_offset to walk further down the ranking; the full frames response (all reporters) is materialized as df_ when a canvas is available — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query. Accepts friendly names like "revenue" or "assets" (discover via secedgar_search_concepts) or raw XBRL tags. One call hits one XBRL tag — when a friendly name maps to multiple same-meaning tags, the response's unqueried_tags lists the others; call again per tag and UNION/COALESCE in SQL with an analysis-specific priority (e.g. SalesRevenueGoodsNet is goods-only). The response's related_tags separately flags alternate-DEFINITION tags a meaningful share of filers use as their primary line (e.g. cash incl. restricted cash, equity incl. noncontrolling interest) — a whole-universe screen on the base tag silently omits those filers; query them separately, but do not blindly union (the semantics differ). Response includes value_distribution and period_end_range to flag XBRL scale-factor anomalies and fiscal-year mixing.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort direction. "desc" for highest values first (typical for revenue, assets). "asc" for lowest values. | desc |
| unit | No | Unit of measure. Use "USD-per-shares" (or equivalently "USD/shares") for EPS, "shares" for share counts, "pure" for ratios. Ignored when concept resolves to a friendly name with a known unit. | USD |
| limit | No | Number of companies to return. | |
| offset | No | Rank to start the page at, 0-based, over the sorted frame. Pass the next_offset from the previous response to read the next page — the ranked list is fetched whole and sliced, so paging is stable and gap-free. An offset at or past total_companies returns an empty page. | |
| period | Yes | Calendar period. Use duration periods (no I suffix) for income/cash-flow items: "CY2023" (full year), "CY2024Q2" (single quarter). Use instant periods (I suffix) for balance-sheet items: "CY2023Q4I" (snapshot at Q4 close). | |
| concept | Yes | Financial concept — same friendly names as secedgar_get_financials (e.g., "revenue", "assets", "eps_basic") or raw XBRL tag. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| data | No | Ranked companies for this metric. |
| unit | No | Unit of measure used for the lookup (always normalized to dashed form, e.g. "USD-per-shares"). |
| error | No | Present when the call failed. Absent on success. |
| label | No | Human-readable concept label. |
| shown | No | Number of companies shown inline. |
| notice | No | Guidance when the requested offset lands past the end of the ranked list. |
| offset | No | Rank the returned page starts at, 0-based — the effective offset applied. |
| period | No | Calendar period the data was fetched for, echoed from input. |
| caveats | No | Data-completeness warnings specific to this query. Currently populated for duration periods 'CY####Q[1-4]', where SEC XBRL omits filers' fiscal Q4 (reported only as the 10-K residual) — affected filers are silently absent from the frame. Empty for annual ('CY####') and instant ('CY####Q#I') periods, where the underlying facts exist and the frame is complete. |
| concept | No | XBRL tag the data was actually fetched against (after resolving any friendly name). |
| dataset | No | Canvas dataframe handle holding the full frames response. Absent when canvas is unavailable or materialization failed. |
| truncated | No | True when the inline data[] was capped by limit. |
| next_offset | No | Offset to pass on the next call to continue down the ranking. Absent on the last page (no companies remain past this one). |
| related_tags | No | Alternate-DEFINITION XBRL tags (distinct from same-meaning `unqueried_tags`) that a meaningful share of filers use as their primary line for this metric — e.g. `cash` filers reporting `CashCashEquivalentsRestrictedCashAndRestrictedCashEquivalents` (incl. restricted cash), `equity` filers reporting `StockholdersEquityIncludingPortionAttributableToNoncontrollingInterest` (incl. noncontrolling interest). These filers are NOT in `data` or the dataframe, so a whole-universe screen on the base tag silently under-counts. To recover them, run a separate fetch_frames against the alternate tag — do NOT blindly UNION (definitions differ; you would mix or double-count). Empty when the concept has no known high-coverage alternate. |
| unqueried_tags | No | Other same-meaning XBRL tags in the friendly-name mapping that this call did NOT query (historical/variant spellings of the same metric). Empty for raw tags or single-tag concepts — for alternate-DEFINITION tags some filers use instead, see `related_tags`. For "revenue" this typically lists `Revenues`, `SalesRevenueNet`, `SalesRevenueGoodsNet` — filers reporting under legacy variants are absent from `data`; call again per tag and UNION/COALESCE in SQL to recover them. |
| total_companies | No | Total companies reporting this metric for this period. |
| period_end_range | No | Range of period_end dates across the frame. SEC normalizes to calendar periods but filers report against their own fiscal year-ends, so a "CY2023" duration frame can contain period_ends from 2023-01-31 (January-FY filers like Walmart) to 2024-12-31 (calendar-FY filers reported late). Wide ranges mean cross-comparison mixes fiscal periods. |
| value_distribution | No | Distribution stats across the full frame, computed during materialization. Use `max_to_p95_ratio` as the primary outlier signal — it catches scale-factor anomalies even when median is 0 or negative. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses pagination stability, inline vs. full dataframe materialization, the unqueried_tags caveat for ambiguous friendly names, the related_tags semantic difference, and the presence of value_distribution/period_end_range. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized and front-loaded with the core purpose. Every sentence contributes, though the volume of behavioral detail makes it longer than strictly minimal; the length is justified by the complexity of the tool's response modes and tag-mapping behavior.
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 input schema, output schema, and sibling tools available, the description covers all key operational dimensions: output modes (inline vs. full dataframe), pagination, tag disambiguation, related-tag caveats, period semantics, and where to route follow-up work.
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 a 3; the description earns a 4 by adding non-obvious semantics for `concept` (friendly-name discovery, multi-tag mapping, related tags with different meanings) and `period` (duration vs point-in-time suffix), which materially helps the agent choose correct 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 opening sentence is precise and specific: 'Fetch SEC XBRL frames for one concept × one period across all reporting companies.' This clearly identifies the verb, the resource, and the uniqueness constraint (one concept × one period), leaving no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent to sibling tools: use secedgar_search_concepts to discover friendly names, use secedgar_dataframe_describe and secedgar_dataframe_query for the full materialized response, and call once per XBRL tag with SQL UNION/COALESCE guidance. It also explains how to paginate with offset/next_offset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_find_holdersFind HoldersARead-onlyIdempotentInspect
Find which institutional managers reported holding an issuer, by searching 13F-HR information tables for one reporting quarter. This is the reverse direction of secedgar_get_institutional_holdings: that tool takes a manager and returns its portfolio, this one takes an issuer and returns its managers — pass a returned filer_cik plus the same quarter to read the actual position. Searching by cusip is the precise path, matching the identifier the information table itself carries; without it the issuer name is matched as a phrase against the filing text, which both over-matches (unrelated issuers sharing a word) and under-matches (managers writing the name differently), so prefer cusip whenever one is known. A CUSIP cannot be derived from a ticker here — read one off any 13F information table returned by secedgar_get_institutional_holdings. The returned list is unranked: the search index scores by text relevance, which carries no signal about position size, and no ordering by shares or market value is available without opening each filing. Managers holding under $100M in 13(f) securities are exempt from filing at all. When more managers match than fit inline, the full fetched set is staged as df_ — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| cusip | No | The issuer's 9-character CUSIP (e.g. "037833100" for Apple common stock; foreign issuers use a CINS starting with a letter, e.g. "H1467J104"). The precise match key — information tables identify every position by CUSIP, so this avoids the name-phrase misses. Each share class has its own CUSIP, so a multi-class issuer needs one call per class. Read a CUSIP off the holdings returned by secedgar_get_institutional_holdings. | |
| limit | No | Filer rows returned inline. The full fetched set (up to 500 rows) is materialized as a dataframe when a canvas is available. Default 20. | |
| issuer | Yes | The portfolio company whose holders you want — a ticker ("AAPL"), a 10-digit CIK ("0000320193"), or a company name. Without cusip, this resolves to the company's EDGAR-conformed name and that name is phrase-matched against 13F information tables, so it must identify one company. With cusip supplied, it is used only to label the result. | |
| quarter | No | Reporting quarter to search, "YYYY-QN" (e.g. "2026-Q1"). Omit for the newest quarter whose 45-day filing deadline has passed — the applied quarter and its filing window are echoed in the response. A quarter still inside its deadline returns nothing, because the filings do not exist yet. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of filers shown inline. |
| issuer | No | The issuer input, echoed. |
| notice | No | Guidance when the search returned no filers — names the likely cause. |
| dataset | No | Canvas dataframe holding every fetched filer row, each carrying the issuer key and quarter so it joins across issuers and quarters. Absent when the result fits inline, canvas is unavailable, or materialization failed. Query with secedgar_dataframe_query. |
| fetched | No | Filings retrieved from the index, capped by the fetch budget of 500. Equals total_filings when the whole window fit inside the budget. |
| holders | No | One page of filers, capped at limit. Order carries no position-size meaning — see the ordering note. |
| quarter | No | Reporting quarter searched, "YYYY-QN" — the requested one, or the applied default. |
| filed_to | No | End of the filing window searched (YYYY-MM-DD). |
| ordering | No | How the holder list is ordered, and what that ordering does not mean. |
| truncated | No | True when the inline holders list was capped. |
| filed_from | No | Start of the filing window searched (YYYY-MM-DD). |
| search_key | No | The exact term searched — the CUSIP, or the quoted phrase. |
| search_mode | No | Which key matched the information tables. "cusip" matches the identifier the table itself carries; "name" phrase-matches the filing text and is looser in both directions. |
| total_filings | No | Total 13F-HR filings matching the search key inside the filing window, as reported by the index. A slight over-count of this quarter's holders on two counts, both of which the returned rows correct for: a few percent are amendments restating an older quarter, and a few more are managers amending their own report for this quarter, which puts them in the window twice. |
| total_is_exact | No | False when total_filings is a lower bound (the index capped the count). |
| holders_in_quarter | No | Distinct managers among the fetched filings reporting this quarter as their period — the set paged by limit and materialized on the dataframe. Lower than fetched by the filings dropped as amendments restating other quarters, and by managers that amended this quarter (kept once, at their latest filing). |
| resolved_issuer_cik | No | CIK of the resolved issuer, zero-padded to 10 digits. Absent when cusip was supplied. |
| resolved_issuer_name | No | EDGAR-conformed company name the issuer resolved to, and the phrase that was searched. Absent when cusip was supplied (no company lookup runs). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only, idempotent, and open-world, and the description adds materially beyond them: the returned list is deliberately unranked, text-relevance scoring carries no position-size signal, managers under $100M are exempt, and the full fetched set is staged as df_<id> for further inspection. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational value: purpose, sibling relationship, CUSIP preference rationale, unranked results, filing exemption, and dataframe staging. It is front-loaded with the core purpose and then layers caveats in a logical order.
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 complexity of the tool and the presence of an output schema and helpful annotations, the description is complete. It explains the search scope, the matching-path tradeoffs, the result ordering limitation, the legal filing exemption, the quarter rolling behavior, and the workflow for consuming large result sets with sibling dataframe tools.
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?
Although schema coverage is 100%, the description substantially enriches every parameter: CUSIP is explained as the precise match key with examples and multi-class caveats, issuer clarifies ticker/CIK/name resolution behavior, quarter explains omission semantics and deadline effects, and limit explains inline versus materialized dataframe behavior. This goes far beyond the baseline that 100% schema coverage would warrant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find which institutional managers reported holding an issuer, by searching 13F-HR information tables.' It explicitly contrasts itself with secedgar_get_institutional_holdings ('reverse direction'), so an agent can unambiguously distinguish it from the closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct when-to-use and when-not-to-use guidance: it names the reciprocal sibling, instructs the agent to pass a returned filer_cik from that tool to read positions, and gives a clear preference rule — use CUSIP whenever known because name matching over-matches and under-matches. It also explains quarter-deadline behavior and when results are staged as a dataframe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_beneficial_ownersGet Beneficial OwnersARead-onlyIdempotentInspect
List the 5%-and-over beneficial owners of a public company, parsed from the structured SCHEDULE 13D and SCHEDULE 13G filings made about it. The input is the ISSUER — the company being held — which is the opposite direction from secedgar_get_institutional_holdings, where the input is the manager. 13D is the activist form and carries the filer's stated purpose of the transaction; 13G is the passive form and has no purpose field at all, which is the substantive difference between a stake that intends to influence control and one that does not. Every filing is returned with each reporting person listed separately, because voting power, dispositive power, and percent of class are reported per person even on a joint filing where several funds and their controlling principal report overlapping shares — summing those percentages double-counts the same position. Coverage starts at 2024-12-18, when SEC replaced the legacy SC 13D / SC 13G text filings with this XML format; earlier stakes are readable but not parseable, and the response reports how many of them the issuer has. The full parsed set is materialized as df_ when a canvas is available, one row per reporting person, so it joins against the insider and 13F dataframes on issuer CIK — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of filings to fetch and parse, newest first. Each filing is a separate document fetch, so this is the cost of the call as well as its depth. Default 10; a widely-held company can have dozens of blockholder filings a year. | |
| issuer | Yes | The company whose blockholders you want — a ticker ("AAPL"), a 10-digit CIK ("0000320193"), or a company name. This is the subject company of the schedule, not the investor filing it; passing an investment manager here returns the schedules filed about that manager, which is almost always empty. | |
| form_kind | No | Which schedule to return. "13D" is the activist form, filed by a holder that may seek to influence control and carrying a stated purpose of transaction. "13G" is the passive form, available to institutions and holders under 20% that certify no control intent. "all" (default) returns both, newest first. | all |
| include_amendments | No | Whether to include amendments (SCHEDULE 13D/A, SCHEDULE 13G/A). Amendments carry the current position and are how an ongoing stake is tracked, so they are included by default. Set false to see only filings that opened a new position. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of filings returned. |
| issuer | No | The issuer input, echoed. |
| notice | No | Guidance when no filings matched — names the coverage boundary and the fallback. |
| dataset | No | Canvas dataframe holding one row per reporting person across every parsed filing, each row carrying the issuer, form, accession, and dates alongside the person's powers. Joins against the insider and 13F dataframes on issuer_cik. Absent when canvas is unavailable or nothing parsed. |
| filings | No | Blockholder filings, newest first, capped at limit. |
| form_kind | No | The schedule filter applied — the requested value, or the default "all". |
| truncated | No | True when filings were capped by limit. |
| issuer_cik | No | CIK of the resolved issuer, zero-padded to 10 digits. |
| issuer_name | No | EDGAR-conformed name of the resolved issuer. |
| filings_parsed | No | Filings actually fetched and parsed — total_structured_filings capped by limit. |
| structured_coverage_from | No | First filing date on which SEC required this XML format (YYYY-MM-DD). Blockholder filings before it exist but are not parseable into this schema. |
| total_structured_filings | No | Structured SCHEDULE 13D/13G filings matching the form filter in the issuer's recent submissions window, before the limit. The population the returned filings are the newest slice of. |
| legacy_filings_before_coverage | No | Legacy SC 13D / SC 13G filings in the issuer's recent submissions window — pre-2024-12-18 stakes this tool cannot parse. Reach them with secedgar_search_filings and read them with secedgar_get_filing. A floor, not a lifetime count: the submissions window holds roughly the last thousand filings of every type. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, so the description carries less burden on safety, but it discloses useful behavioral caveats: coverage only starts at 2024-12-18, earlier filings are readable but not parseable, and per-person reporting makes summing percentages double-count the same position. This is exactly the kind of non-obvious behavior an agent needs to interpret results correctly.
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 leads with the primary action and packs important caveats in a logical order. It is somewhat long, but every sentence earns its place: the double-count, coverage cutoff, and dataframe materialization warnings would be missing if trimmed. This is dense, not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description covers everything else an agent needs: what kind of entities to pass, what 13D/13G mean, what operates with per-person rows, how the data is stored as df_<id>, and how to inspect/query that df. The tool raises no obvious unanswered operational question.
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 all four parameters in detail. The description adds directional and categorical meaning beyond the schema—especially 'issuer' vs 'manager' and the substantive 13D-vs-13G distinction—but it does not need to re-describe each parameter. A mild deduction is appropriate because the un noticeable addition is richer but not essential for all parameters.
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 sentence states the exact resource ('5% and-over beneficial owners') and source ('SCHEDULE 13D and SCHEDULE 13G filings'), while the explicit 'opposite direction from secedgar_get_institutional_holdings' comparison distinguishes it from a direct sibling. An agent can tell exactly what this tool returns and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use this tool: when you have the issuer, not the manager, and it names the competing sibling tool that expects the opposite input. It also differentiates 13D/13G use cases. It does not enumerate every possible alternative among the 15 sibling tools, but the key disambiguation is present and concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_filingSecedgar Get FilingARead-onlyIdempotentInspect
Fetch a specific filing's metadata and document content by accession number. Returns the primary document as readable text. Use offset/next_offset for multi-page access to large filings (10-K, S-1 can exceed 1M chars): pass the next_offset from a truncated response to read the next page. Use section to jump directly to a heading (e.g. 'risk factors', 'item 7') without needing an offset.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | Company CIK, digits only (resolve via secedgar_company_search if you have a ticker or name). Optional but recommended — speeds up archive lookup. If omitted, likely filing CIKs are inferred from SEC search metadata and archive paths. | |
| offset | No | Character offset into the extracted document text. Pass next_offset from a truncated response to continue reading the next page. Default 0 reads from the beginning. | |
| section | No | Jump to a named section by case-insensitive substring match against detected headings (e.g. 'risk factors', 'item 7', 'certain relationships'). Matching also ignores whitespace and quote-style differences, so a heading copied from the outline resolves whether it carries the filing's non-breaking spaces and curly quotes or plain ones. Takes precedence over offset when both are provided. On a miss, the error message includes the detected outline so you can pick the correct heading. | |
| document | No | Specific document filename within the filing (e.g., "ex-21.htm" for subsidiaries list). Default: the primary document. Available documents are listed in the response metadata under documents; entries marked binary hold no text and are rejected. | |
| include_xbrl | No | Include XBRL viewer artifacts and machine-readable taxonomy files (R*.htm fragments, *_cal/_def/_lab/_pre.xml linkbases, *_htm.xml inline instance, *.xsd schemas, MetaLinks.json, FilingSummary.xml, Show.js, report.css, *-xbrl.zip, Financial_Report.xlsx, EX-101.* technical exhibits) under documents.xbrl. Off by default — these dominate filing indexes (~100 entries on a typical 10-K) and are rarely relevant when reading filing content. | |
| content_limit | No | Maximum characters of document text to return per page. 10-K filings can exceed 500,000 characters; S-1/A can exceed 1,000,000. Default 50,000 captures ~12,000 words (typically business overview, risk factors, and MD&A). Increase to 200,000 for full financial statements, or decrease for quick summaries. Use offset or section for subsequent pages. | |
| accession_number | Yes | Filing accession number in either format: "0000320193-23-000106" (dashes) or "000032019323000106" (no dashes). Obtained from secedgar_company_search or secedgar_search_filings results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The `content_limit` that was applied. |
| cik | No | Filing entity CIK, zero-padded to 10 digits. |
| form | No | Form type (e.g., "10-K", "10-Q"). Absent for filings older than the last ~1,000 the company has filed (SEC does not surface metadata for those without a separate fetch). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Characters of document text returned on this page. |
| notice | No | Guidance on reading the next page when the content was capped. |
| content | No | Document text content for this page window. |
| outline | No | Document outline — up to 50 detected headings with their character offsets. Present on the first page of a truncated response (offset=0, no section). Use a heading offset as offset, or pass heading text as section, to jump to that section. |
| documents | No | Filing documents grouped by category. Every name is a valid document input EXCEPT entries carrying binary: true — scanned pages, PDFs, packaged archives and spreadsheets, which hold no text and are rejected with a binary_document error. Scans can outnumber readable documents in a filing, so read the flag before picking a name. XBRL viewer artifacts are suppressed by default; setting include_xbrl=true surfaces them under the xbrl bucket. |
| truncated | No | True when the document is longer than `content_limit` allowed through. |
| filing_url | No | Direct URL to the filing on SEC.gov. |
| filing_date | No | Date the filing was submitted (YYYY-MM-DD). Absent under the same conditions as form. |
| next_offset | No | Character offset to pass as offset on the next call to continue reading. Only present when the response was truncated. Calling agents should follow this until content_truncated is false. |
| company_name | No | Filing entity name. Absent if the CIK did not resolve to a known entity. |
| period_ending | No | Period the filing reports on (YYYY-MM-DD). Absent under the same conditions as form. |
| accession_number | No | Filing accession number, normalized to dash format. |
| primary_document | No | Filename of the filing's actual primary document (e.g., the 10-K HTML file). |
| content_truncated | No | True if content was truncated at content_limit. |
| requested_document | No | Filename of the specific document requested via the document param. Only present when document differs from primary_document. |
| content_total_length | No | Full document length before any truncation. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses important behaviors: the primary document is returned as readable text, responses can be truncated, next_offset continues pagination, and section jumps directly to headings. This gives the agent accurate expectations for large filings and multi-page access.
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 three sentences with no filler, front-loading the core purpose and then giving actionable pagination and section-navigation guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and all parameters documented, the description covers the key behaviors, pagination mechanics, section jumping, and large-document caveats. Nothing an agent needs to invoke this tool 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 adds relational meaning between parameters: offset and next_offset are linked for pagination, section is an alternative to offset, and large 10-K/S-1 filings can exceed 1M characters. This helps the agent choose parameter combinations rather than merely restating schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Fetch a specific filing's metadata and document content by accession number.' This clearly differentiates the tool from search-focused siblings like secedgar_search_filings and other get_* tools by emphasizing retrieval of a known filing.
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?
Provides clear in-tool guidance: use offset/next_offset for pagination of large filings, and use section to jump to headings. It does not explicitly name alternative sibling tools for when to use this tool, but the 'by accession number' qualifier and the sibling list make the selection context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_financialsSecedgar Get FinancialsARead-onlyIdempotentInspect
Get historical XBRL financial data for a company. Accepts friendly concept names (e.g., "revenue", "net_income", "assets") or raw XBRL tags. Discover available friendly names with secedgar_search_concepts. Handles historical tag changes and deduplicates data automatically. The full series is also staged as df_ when a canvas is available — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cap the inline data[] to the most-recent N periods (the series is newest-first). The full series is always registered to the dataframe, so older periods stay queryable via secedgar_dataframe_query. Omit to return every period inline. | |
| company | Yes | Ticker symbol (e.g., "AAPL") or CIK number. Ticker is preferred. | |
| concept | Yes | Financial concept — friendly name (e.g., "revenue", "net_income", "assets", "eps_diluted") or raw XBRL tag (e.g., "AccountsPayableCurrent"). Friendly names auto-resolve to the correct XBRL tags and handle historical tag changes. | |
| taxonomy | No | XBRL taxonomy. us-gaap for US companies, ifrs-full for foreign filers, dei for entity info (shares outstanding). | us-gaap |
| period_type | No | Filter to annual (FY) or quarterly (Q1-Q4) data. "all" returns both. When omitted, defaults to "annual"; instant (balance-sheet) concepts automatically fall back to returning the full series on the first call when the annual filter yields nothing (#48). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| cik | No | Resolved CIK, zero-padded to 10 digits. |
| data | No | Deduplicated time series, newest first. |
| unit | No | Unit of measure (e.g., "USD", "shares", "USD/shares"). |
| error | No | Present when the call failed. Absent on success. |
| label | No | Human-readable label for the concept. |
| shown | No | Number of periods shown inline. |
| notice | No | Guidance when the inline series was capped, or when the full series is staged as a dataframe. |
| caveats | No | Data-completeness warnings about the returned series. Two kinds. On quarterly results, one entry when one or two calendar quarters are absent from every recent qualifying year — SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact, so the calendar quarter fiscal Q4 spans has no frame-tagged value, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. Applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. On any result, one entry when the series stops well short of today — either because the concept resolved to an XBRL tag SEC has retired from the taxonomy (the current tags reported nothing), or because a current tag's series ends more than two years plus a filing window back, which is what a filer migrating to a different element or dropping the disclosure looks like. Absent when the series has nothing to flag. |
| company | No | Resolved entity name (SEC-conformed). |
| concept | No | XBRL tag name used. |
| dataset | No | Canvas dataframe handle holding the same time series. Use for cross-company JOINs via secedgar_dataframe_query. The source-filing fiscal keys are materialized as source_filing_fy/source_filing_fp — order, group, and window by period_end, not by those columns. Absent when canvas is unavailable. |
| truncated | No | True when the inline data[] was capped by limit. |
| tags_tried | No | XBRL tags that were attempted (shown when using friendly names that map to multiple tags). |
| description | No | XBRL taxonomy description for this concept. Often absent for company-extension tags or older concepts. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral context beyond those hints: automatic handling of historical tag changes, automatic deduplication, and staging of the full series as df_<id> when a canvas is available. No contradiction with annotations exists.
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 compact and front-loaded with the core purpose. Each sentence earns its place: input flexibility, concept discovery, automatic handling of tag changes/dedup, and the dataframe analysis workflow. There is no filler or redundant restating of the tool name.
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 5-parameter tool, the rich schema and output schema cover parameter and return details, while the description supplies the workflow context an agent needs. Slight ambiguity remains around 'canvas' availability and what happens when no canvas exists, but that does not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the friendly-name/raw-tag flexibility for the concept parameter and mentions dataframe staging, but it does not add parameter meaning beyond what the schema already documents in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Get historical XBRL financial data for a company.' It clearly differentiates from sibling tools by highlighting the friendly-name/raw-tag input mode and by pointing to secedgar_search_concepts, secedgar_dataframe_describe, and secedgar_dataframe_query as adjacent workflow steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: retrieving historical XBRL series for a company. It also routes to related tools for concept discovery and dataframe analysis. It does not explicitly state exclusions such as 'use get_snapshot for point-in-time data' or 'use get_filing for source documents,' so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_fund_holdingsGet Fund HoldingsARead-onlyIdempotentInspect
List what an ETF or mutual fund holds, parsed from the NPORT-P portfolio report it files with the SEC every quarter. The input is the fund — a ticker like VOO, a fund series ID, or the registrant trust — which is the opposite direction from the ownership tools: secedgar_get_institutional_holdings and secedgar_find_holders answer who owns a company, this answers what a fund owns. Each position carries the security name, CUSIP/ISIN/LEI where the filer reports them, share balance, market value in USD, and percent of the fund's net assets, alongside fund-level net assets and total assets. Positions are returned largest-first by percent of net assets, one page of limit rows starting at offset; the full report registers as df_ when a canvas is available — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query, which is how a fund running to thousands of positions is aggregated or joined against the 13F and insider dataframes. An NPORT-P covers exactly one fund series and a registrant trust files one report per series, so a trust with several funds needs the specific fund named — pass its ticker or series_id. Reports publish roughly two months after the period they cover, so every result is dated: the holdings are the portfolio as of report_period_date, not as of today.
| Name | Required | Description | Default |
|---|---|---|---|
| fund | Yes | The fund whose portfolio you want — a fund ticker ("VOO", "SCHD"), an SEC fund series ID ("S000002839"), or a 10-digit CIK. A ticker names one share class of one series and routes directly; a CIK names the registrant, which files a separate report per series and needs series_id when it runs more than one fund. Fund trusts are indexed by ticker and series, not by name, so a trust name only resolves for a fund that trades under its own name ("SPDR S&P 500 ETF Trust") — pass the CIK otherwise. | |
| limit | No | Number of positions to return inline, largest first by percent of net assets. Default 20. A broad index fund reports thousands of positions, so the inline list is a preview — read the whole portfolio from the dataframe, or page it with offset. | |
| offset | No | Position to start the page at, 0-based, over the full ordered holdings list. Pass the returned next_offset to read the next page — the report is parsed whole and sliced, so paging is stable and gap-free. | |
| series_id | No | SEC fund series identifier ("S000002839"), naming which fund of the registrant to report. Takes precedence over any series the fund input implies. Series IDs come back on fund results from secedgar_company_search and in the series list of a series_required error. | |
| report_date | No | Target a specific reporting period by its last day (YYYY-MM-DD), e.g. "2025-12-31". Omit for the most recent report. Period ends follow the fund's own fiscal quarters, which are not always calendar quarters — Direxion funds report to February, May, August, and November. available_report_periods in the response lists the ones this call identified; a period missing from that list is still worth requesting directly, since a report the submissions window no longer dates is dated by reading it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| form | No | EDGAR form name — "NPORT-P", or "NPORT-P/A" for an amended report. |
| fund | No | The fund input, echoed. |
| as_of | No | The portfolio date these holdings are reported as of, and the publication lag behind it. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of positions shown inline. |
| notice | No | Guidance when the report carried no positions or the page fell past the end. |
| offset | No | Position the returned page starts at, 0-based. |
| dataset | No | Canvas dataframe holding every position in the report (the inline holdings[] is a preview capped at limit). Each row carries the fund keys — series_id, registrant_cik, report_period_date, accession_number — alongside the position fields, so it joins against the 13F and insider dataframes on cusip. Absent when canvas is unavailable or the report had no positions. |
| holdings | No | One page of positions, `limit` rows starting at `offset`, largest first by percent of net assets. |
| class_ids | No | SEC class IDs of the share classes covered. One report covers every class of the series, so a fund with both an ETF and an admiral-share class reports them together. |
| series_id | No | SEC series ID of the fund this report covers. Absent when the registrant files as a single fund with no series structure, which is how some older exchange-traded trusts are organized. |
| truncated | No | True when the inline holdings list was capped by limit. |
| filing_date | No | Date the report was submitted to EDGAR (YYYY-MM-DD). |
| next_offset | No | Offset to pass on the next call to continue through the portfolio. Absent on the last page. |
| series_name | No | Fund name as the filer states it on the report. A closed-end fund organized as a single registrant names itself here with no series_id alongside; absent only when the filer leaves the field blank or writes "N/A". |
| net_assets_usd | No | Fund net assets in USD at the report date — the denominator of percent_of_net_assets. |
| registrant_cik | No | CIK of the registrant trust, zero-padded to 10 digits. |
| total_holdings | No | Positions in the report, before offset and limit — the size of the full portfolio. |
| is_final_filing | No | True when the fund reports this as its last filing on the series, which marks a liquidation or merger. Absent when the filing does not answer. |
| registrant_name | No | EDGAR-conformed name of the registrant trust. |
| accession_number | No | Accession number — pass to secedgar_get_filing for the full document. |
| total_assets_usd | No | Fund total assets in USD at the report date. |
| report_period_end | No | Last day of the fiscal year the reporting period falls in (YYYY-MM-DD) — the fund's fiscal year end, not the portfolio date. |
| report_period_date | No | Last day of the period this portfolio is reported as of (YYYY-MM-DD). Holdings are the fund's positions on this date, not today's. Absent only when the filer omits it. |
| publication_lag_days | No | Days between the portfolio date and the filing date. Absent when the report omits its period date. |
| total_liabilities_usd | No | Fund total liabilities in USD at the report date. |
| available_report_periods | No | Period end dates of this fund's reports, newest first — the horizon report_date can address, not the fund's full history. It reaches back roughly a decade of quarterly reports, and a period older than that is refused rather than served. A period inside the horizon can still be missing from the list: the dates come from the registrant's recent submissions window, which a trust filing thousands of reports a year outruns in months, and a report the window no longer reaches is dated by reading it only when report_date asks for it. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable context beyond that: the data is dated to report_period_date rather than today, the two-month publication lag, the paging stability guarantee, and the per-series nature of NPORT-P reports. This exceeds what the annotations alone communicate.
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 long but tightly packed with essential information. It is front-loaded with the core purpose and direction, then flows into input resolution, output fields, paging, dataframe integration, and timing. No sentence is wasted; it reads as a coherent manual rather than a list of disconnected facts.
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 (5 parameters, output schema, sibling ecosystem), the description covers everything an agent needs: input disambiguation, output field list, paging mechanics, dataframe integration path, error hints (series_required), and temporal semantics. The output schema exists, so return details are handled, but the description still summarizes key output fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a descriptive comment, so the baseline is 3. The description adds meaningful extra guidance: the routing logic for ticker vs CIK vs series_id, precedence of series_id over fund, and the nuance about fiscal quarters not always being calendar quarters. This enriches the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'what an ETF or mutual fund holds', and immediately distinguishes it from sibling ownership tools by contrasting the direction of the query. The NPORT-P source is specified, making the purpose unambiguous.
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 names the sibling alternatives (secedgar_get_institutional_holdings, secedgar_find_holders) and explains the exact condition that selects this tool over them. It also guides when to use dataframe tools (secedgar_dataframe_describe/query) for large portfolios, and explains the timing nuance about report lag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_insider_transactionsGet Insider TransactionsARead-onlyIdempotentInspect
Fetch Form 4 insider transactions (purchases, sales, grants, exercises) for a company by parsing SEC EDGAR ownership XML. Returns the reporting person, their relationship to the issuer, transaction date, type, shares traded (absolute magnitude), direction (acquire/dispose), price per share, and shares owned after the transaction. Covers nonDerivative transactions (open-market buys/sells, gifts) and derivative transactions (option exercises, RSU vests). When a canvas is available, the full set of transactions parsed from the scanned recent filings is materialized as df_ (the inline list is a preview capped at limit) — inspect it with secedgar_dataframe_describe, then query it with secedgar_dataframe_query to aggregate net buy/sell by insider: SUM(CASE WHEN direction='dispose' THEN -shares_traded ELSE shares_traded END). Use secedgar_search_filings with forms=["4"] for broader date-range queries or to search across all companies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of transactions to return across all Form 4 filings fetched. Filings are scanned newest-first. Default 20. | |
| ticker_or_cik | Yes | Company ticker symbol (e.g., "AAPL") or 10-digit CIK number (e.g., "0000320193"). The issuer, not the reporting person. | |
| transaction_type | No | Filter by direction. "purchase" = open-market buys (code P). "sale" = open-market sells (code S). "all" includes grants, awards, exercises, gifts, and other coded transaction types as well. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of transactions shown inline. |
| notice | No | Guidance when results are empty after filtering — explains the filter applied and suggests alternatives. |
| dataset | No | Canvas dataframe holding the full parsed transaction set from the scanned filings (the inline transactions[] is a preview capped at limit). Each row carries the issuer (issuer_cik, issuer_ticker) plus the transaction fields, so it aggregates net buy/sell by insider and joins across issuers. Query with secedgar_dataframe_query. Absent when canvas is unavailable or no transactions were parsed. |
| truncated | No | True when the inline transactions[] was capped by limit. |
| issuer_cik | No | Issuer CIK, zero-padded to 10 digits. |
| issuer_name | No | Issuer entity name (SEC-conformed). |
| transactions | No | Insider transactions, newest filing first. Preview capped at `limit` — the full scanned set lives on the canvas dataframe (see `dataset`). |
| issuer_ticker | No | Issuer ticker symbol when available. |
| filings_scanned | No | Number of Form 4 filings scanned to produce the result. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It clearly states the data source (Form 4 filings), the returned fields, the derivative/non-derivative coverage, and the preview-vs-materialized-data behavior. It does not mention rate limits or error behavior, but it is otherwise transparent about what the tool does and returns.
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 organized: fetch scope, return fields, transaction type coverage, dataframe materialization, and alternatives. It could be split into clearer sentences, but every clause earns its place; the SQL hint is actionable, not 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?
Covers what is fetched, what fields are returned, how derivative vs non-derivative transactions are included, the preview-vs-dataframe behavior, and which sibling tool to use for broader queries. Nothing essential is missing for a caller deciding whether and how to use this tool.
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 schema already documents all three parameters at 100% coverage)Skip. The description still adds meaning by tying `limit` to the preview-vs-full-dataframe behavior and clarifying that `transaction_type` matches the acquire/dispose distinction in the returned direction field. That is real value beyond 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?
The opening sentence names a specific action (
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly distinguishes when to use this tool from when to use secedgar_search_filings, and it routes the user to dataframe inspection and query tools after retrieval. This gives clear, actionable guidance beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_institutional_holdingsGet Institutional HoldingsARead-onlyIdempotentInspect
Fetch 13F-HR quarterly institutional holdings by parsing the SEC EDGAR information table XML. ticker_or_cik is the institutional filer — its 10-digit CIK (e.g. 0000102909), or an entity name resolved through EDGAR entity search — and the tool returns what that institution holds. A name that matches several EDGAR filers (some legal names are shared across entities) returns those candidates so you can retry with the exact CIK, rather than guessing. For the reverse direction — which institutions hold a given portfolio company — use secedgar_find_holders, whose filer_cik results feed straight back into this tool. The 13F information table lists each position: issuer name, CUSIP, shares held, market value (in whole USD), and put/call designation for options. Sub-lines for the same security are consolidated into distinct positions sorted by value by default (set consolidate=false for raw filing rows). The inline holdings list is one page of limit rows starting at offset — pass the returned next_offset to walk further down a large information table. The full parsed holdings set is also materialized as df_ when a canvas is available — inspect it with secedgar_dataframe_describe, then query it with secedgar_dataframe_query to aggregate the whole filing or self-join across quarters on cusip + reporting_period. Institutions with less than $100M in 13(f) securities are exempt and may not file. Use secedgar_search_filings with forms=["13F-HR"] for broader search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of holdings rows to return. 13F filings from large institutions can contain thousands of positions. Default 20. | |
| offset | No | Row to start the page at, 0-based, over the ordered position list. Pass the next_offset from the previous response to read the next page — the filing is parsed whole and sliced, so paging is stable and gap-free. An offset at or past the position count returns an empty page. | |
| quarter | No | Reporting quarter to target, in "YYYY-QN" format (e.g., "2025-Q4"). When omitted, returns the most recent 13F-HR available. Quarters map to the filing window: Q4 2025 = filings submitted roughly Jan–Mar 2026. | |
| consolidate | No | When true (default), info-table sub-lines for the same security (CUSIP + class + put/call) are summed into one position and results are sorted by market value descending, so `limit` returns the largest distinct holdings. Set false to return raw information-table rows in filing order (one per investment-discretion/manager sub-line), preserving investment_discretion. | |
| ticker_or_cik | Yes | The institutional filer whose 13F to fetch — a 10-digit CIK (e.g. "0000102909" for VANGUARD GROUP INC, the most reliable form) or an entity name. Names resolve through EDGAR entity search, which covers institutional managers absent from the ticker file; a name matching several filers (some legal names are shared across entities) returns those candidates so you can retry with the exact CIK. This is NOT the portfolio company — passing an issuer ticker like "AAPL" finds that operating company's own filings (it files no 13F), not who holds it; use secedgar_find_holders for that direction. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of holdings shown inline. |
| notice | No | Guidance when no filings were found or the result set is empty — suggests alternatives. |
| offset | No | Row the returned page starts at, 0-based — the effective offset applied. |
| dataset | No | Canvas dataframe holding every parsed position from this 13F filing (the inline holdings[] is a preview capped at limit). Each row carries the filer metadata (filer_cik, filer_name, reporting_period, filing_date, accession_number) plus the position fields, so it self-joins across quarters/filers on cusip + reporting_period. Reflects the consolidate setting (consolidated positions when true, raw info-table sub-lines with investment_discretion when false). Query with secedgar_dataframe_query. Absent when canvas is unavailable or the filing had no holdings. |
| holdings | No | One page of holdings, `limit` rows starting at `offset` — consolidated positions sorted by market value when consolidate=true, else raw information-table rows in filing order. |
| filer_cik | No | CIK of the 13F filer, zero-padded to 10 digits. |
| truncated | No | True when the inline holdings[] was capped by limit. |
| filer_name | No | Name of the institutional filer (the 13F submitter). |
| filing_date | No | Date the 13F was submitted (YYYY-MM-DD). |
| next_offset | No | Offset to pass on the next call to continue through the positions. Absent on the last page (no rows remain past this one). |
| total_positions | No | Number of distinct positions after consolidating info-table sub-lines, before the limit. Present only when consolidate=true. |
| accession_number | No | Accession number for this 13F-HR filing — pass to secedgar_get_filing for the full document. |
| reporting_period | No | The calendar-quarter end date this 13F covers (YYYY-MM-DD), from the filing cover page. Absent if not surfaced in the filing. |
| total_holdings_in_filing | No | Total number of raw information-table rows in this filing, before consolidation and the limit. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral context: it discloses that it parses XML, that results are paginated and sliced stably, that the tool materializes a dataframe when a canvas is available, and that it can return candidate matches for ambiguous names. It also notes consolidation behavior and the effect of paging semantics, going beyond annotations to explain side effects (materialization) and edge cases (missing filings).
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 comprehensive but efficiently organized: it leads with the core purpose, then parameters, then reverse direction. Every sentence adds value—no filler. It manages to pack a lot of useful guidance into a dense but readable paragraph without redundancies.
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 (5 params, output schema, canvas integration), the description covers all necessary aspects: how to paginate, how to filter by quarter, how consolidation works, and how to leverage the dataframe for further analysis. The output schema is present, so return values are not the description's burden. It even explains the $100M filing threshold, which is a critical context for empty responses.
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%, but the description adds crucial semantics beyond the schema: it clarifies that ticker_or_cik is the filer (not the issuer), warns against using issuer tickers, and explains the 'offset' pagination with next_offset, the 'quarter' format and window, and 'consolidate' sub-line behavior. It even clarifies limit default behavior in context of consolidation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches 13F-HR quarterly institutional holdings by parsing the SEC EDGAR XML, and distinguishes the input as the filer, not the portfolio company. It names the reverse-direction sibling (secedgar_find_holders) and explicitly warns against passing issuer tickers like 'AAPL', which helps agents pick the right tool for the direction.
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 provides explicit when-to-use guidance: for the reverse direction (who holds a company), it points to secedgar_find_holders. It also mentions when to use secedgar_search_filings for broader search. Additionally, it explains when the tool may not return results (institutions with <$100M exempt) and advises using exact CIK for ambiguous names, covering both alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_material_eventsGet Material EventsARead-onlyIdempotentInspect
Retrieve a company's 8-K filings with their item codes decoded, optionally filtered to specific items. 8-K item codes are how material events are actually scoped — 1.01 material agreements, 2.02 results of operations, 4.02 non-reliance on previously issued financials, 5.02 officer and director departures — and filtering by them is narrower than any form-level filter in secedgar_search_filings or secedgar_company_search, neither of which can see items. Each row carries the accession number and primary document for secedgar_get_filing; press releases usually ride as EX-99 exhibits rather than in the primary document. Two numbering regimes exist: filings from 2004-08-23 onward use the x.xx codes, earlier ones use single integers (12 was the old results-of-operations item, 9 the old Regulation FD item), and both are accepted as filters and decoded in the response. A date window reaches filings older than the recent submissions window by paging into the archive. The full filtered set is materialized as df_ for item-distribution analysis over time — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Item codes to filter to; a filing matches when it reports any of them. Omit to return every 8-K. Current-regime codes are dotted ("2.02"), pre-2004-08-23 codes are bare integers ("12"), and the two vocabularies do not overlap — filtering on "2.02" alone returns nothing from a pre-2004 window, so pair them ("2.02", "12") when the window spans the changeover. Full decode table: the secedgar://filing-types resource. | |
| limit | No | Filings returned inline, newest first. The full filtered set is materialized as a dataframe when it exceeds this and a canvas is available. Default 20. | |
| company | Yes | Company ticker symbol (e.g. "AAPL"), name (e.g. "Apple"), or CIK number (e.g. "320193"). Ticker is the exact lookup; name search matches current and former names. | |
| filed_after | No | Only include filings filed on or after this date (YYYY-MM-DD). A date filter routes the scan into the older submissions archive pages, so it reaches 8-K filings that predate the ~1000-filing recent window. | |
| filed_before | No | Only include filings filed on or before this date (YYYY-MM-DD). Use alone or with filed_after; together they bound the archive-page scan. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| cik | No | Central Index Key of the resolved company, zero-padded to 10 digits. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of filings shown inline. |
| notice | No | Guidance when nothing matched — distinguishes an empty date window from an items filter that excluded everything. |
| dataset | No | Canvas dataframe holding the full filtered 8-K set. Item codes ride as a comma-separated `item_codes` column, so item-frequency-over-time queries split it (`unnest(string_split(item_codes, ','))`). Absent when the result fits inline, canvas is unavailable, or materialization failed. |
| filings | No | Matching filings, newest first, capped at limit. |
| truncated | No | True when the inline filings list was capped. |
| company_name | No | SEC-conformed company name. |
| items_filter | No | The item codes filtered on, echoed. Absent when no filter was applied. |
| total_matched | No | Filings matching every applied filter across the whole scan, which may exceed limit and the inline list. |
| total_8k_scanned | No | 8-K filings inside the date window before the items filter — compare against total_matched to see how much the items filter removed. |
| item_distribution | No | Count of the 8-K filings scanned in the date window carrying each item code, before the items filter. Empty when no 8-K filings were scanned. |
| history_scanned_through | No | Oldest filing date reached by the scan (YYYY-MM-DD). Older filings were not examined: the recent window caps at ~1000 filings, and archive pages are fetched only when a date filter or an under-filled result requires them. Absent when no filings were scanned. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although readOnlyHint, openWorldHint, and idempotentHint already cover the safety profile, the description discloses significant behavioral detail beyond those annotations: the old vs. new item-code regimes, archive paging when date filters are used, the fact that each row carries accession and primary document, the EX-99 exhibit caveat, and the side effect of materializing df_<id>. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, item-code semantics, sibling differentiation, numbering-regime nuance, archive paging, dataframe workflow, and downstream analysis tools. It is front-loaded with the core action and resource before diving into nuances, making it efficient despite its 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?
For a complex tool with five parameters, rich schema descriptions, an output schema, and detailed annotations, the description is complete. It covers what the tool returns, how filtering behaves, when to choose it over alternatives, how to reach older filings, and how to continue analysis with dataframe tools. Nothing essential for correct invocation 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% and parameter descriptions already explain item-code vocabularies, date formats, and limit semantics. However, the description adds meaning not present in the schema, such as cross-parameter interaction with date windows, dataframe materialization behavior, and the relationship between accession numbers, primary documents, and EX-99 exhibits. This adds real value above the schema baseline without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Retrieve a company's 8-K filings with their item codes decoded, optionally filtered to specific items.' It sharply distinguishes itself from siblings by noting that neither secedgar_search_filings nor secedgar_company_search can see item codes, making its unique role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with secedgar_search_filings and secedgar_company_search, stating what they cannot do (see items) and why this tool's item-level filtering is narrower. It also names downstream tools (secedgar_dataframe_describe, secedgar_dataframe_query) for the dataframe workflow, giving concrete when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_snapshotSecedgar Get SnapshotARead-onlyIdempotentInspect
Build a company financial profile in one call: the latest value of every supported XBRL concept, grouped by statement. Reads the filer's complete companyfacts payload once rather than one request per concept, so it replaces a run of secedgar_get_financials calls when the question is "what do this company's financials look like right now". Values use the same frame dedup and tag priority as secedgar_get_financials, so the two agree for any concept they both cover. Duration concepts (income statement, cash flow, per-share) report their latest full year and latest single quarter; balance-sheet and entity-info concepts report their latest point-in-time value, since that is the only form they are filed in. A concept the filer does not report is listed under gaps with the XBRL tags that were tried — never zero-filled or interpolated. Use secedgar_get_financials for a full time series of one concept, and secedgar_compare_companies to put several companies side by side.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Ticker symbol (e.g. "AAPL") or CIK number. Ticker is preferred. | |
| taxonomy | No | XBRL taxonomy to resolve concepts under. Every concept is looked up in this one taxonomy, so ifrs-full covers only the concepts with confirmed IFRS tag variants and the rest — including the dei entity-info concepts — come back under gaps. Leave at us-gaap for domestic filers, where each concept uses its own preferred taxonomy. | us-gaap |
| period_type | No | Which duration periods to report per concept: the latest full year, the latest single quarter, or both (default). Balance-sheet and entity-info concepts are point-in-time and always report their latest instant value regardless of this setting. | both |
Output Schema
| Name | Required | Description |
|---|---|---|
| cik | No | Resolved CIK, zero-padded to 10 digits. |
| gaps | No | Concepts with no value for this filer. Deliberately explicit — a missing concept is never zero-filled or interpolated. |
| error | No | Present when the call failed. Absent on success. |
| lines | No | Resolved concepts, ordered by statement group then concept name. |
| caveats | No | Data-completeness warnings. One entry when one or two calendar quarters are absent from every recent qualifying year, because SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact — this applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. One further entry, prefixed with the concept name, per line whose values stop at least two full years behind the newest period this filer reports anywhere in the profile — either because the line resolved to an XBRL tag SEC has retired from the taxonomy, or because a current tag's series simply ends, which is what a migration to a different element or a dropped disclosure looks like. Empty when nothing needs flagging. |
| company | No | Resolved entity name (SEC-conformed). |
| taxonomy | No | Taxonomy the concepts were resolved under, echoed from input. |
| period_type | No | Duration periods reported, echoed from input. |
| concepts_total | No | Concepts in the supported catalog that were attempted. |
| concepts_resolved | No | Concepts that produced at least one value. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses meaningful behavior: it reads the companyfacts payload once, applies the same frame dedup and tag priority as secedgar_get_financials, reports duration vs point-in-time values differently, and lists missing concepts under gaps with tried tags rather than zero-filling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds distinct value: purpose, efficiency rationale, consistency guarantee, period behavior, gap handling, and routing to alternatives. The main purpose is front-loaded in the first sentence, and there is no 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 snapshot tool with a rich schema and output schema, the description covers purpose, alternatives, data semantics, missing-value behavior, and consistency guarantees. Nothing an agent needs to call 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?
The input schema already documents all three parameters with 100% coverage, including detailed notes on taxonomy and period_type. The description adds context about snapshot semantics but does not add parameter-specific meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build a company financial profile in one call: the latest value of every supported XBRL concept, grouped by statement.' It explicitly distinguishes itself from siblings by saying it replaces a run of secedgar_get_financials calls and by routing secedgar_compare_companies for side-by-side comparisons.
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 concrete when-to-use guidance: use this when the question is 'what do this company's financials look like right now', and explicitly names alternatives: secedgar_get_financials for a full time series of one concept, secedgar_compare_companies for side-by-side. This leaves no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_search_conceptsSecedgar Search ConceptsARead-onlyIdempotentInspect
Search supported XBRL financial concepts by keyword, statement group, or taxonomy. Use before secedgar_get_financials or secedgar_fetch_frames to discover the right friendly name, or pass a raw XBRL tag (e.g., "NetIncomeLoss") to reverse-lookup which friendly names map to it. Empty search with no filters returns the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Filter to a single financial statement group. income_statement covers P&L items; balance_sheet covers position items (use instant periods in secedgar_fetch_frames); cash_flow covers CF statement items; per_share covers EPS; entity_info covers DEI items like shares outstanding. | |
| search | No | Case-insensitive substring matched against friendly name, label, and XBRL tags. Examples: "cash" finds cash and operating_cash_flow; "earnings" finds eps_basic and eps_diluted; "NetIncomeLoss" reverse-maps to net_income. Omit to list all concepts. | |
| taxonomy | No | Filter to a single XBRL taxonomy. us-gaap for US filers, ifrs-full for foreign filers, dei for entity info. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Number of concepts matching the filters. |
| notice | No | Guidance when no concepts matched — echoes the search term and suggests alternatives. |
| concepts | No | Matching concepts, ordered by group then alphabetical by name. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is safe to call repeatedly. The description adds the 'empty search with no filters returns the full catalog' behavior, which is helpful context for expected output volume. It doesn't describe pagination or size limits, but for a catalog lookup tool the annotations cover the safety profile; 3 reflects the modest additional disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first states the verb and scope, the second names the sibling tools and the reverse-lookup use, the third notes empty-search behavior. Slight room for improvement: the sentence about 'Usability' could be trimmed, but it's information-dense and front-loaded. Loses a point for slight denseness but not for waste.
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 (return format is documented separately), the description covers the key use case: discovering friendly names before calling get_financials or fetch_frames. It explains the search mechanisms and empty behavior. Missing pagination/limit details are minor for a search catalog tool with an output schema; 4 reflects adequate completeness with a small 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 schema already documents all three parameters, including enums with per-item explanations (e.g., balance_sheet covering position items with instant periods). The description adds the reverse-lookup example ('NetIncomeLoss' maps to net_income) which clarifies search semantics beyond the schema's substring description. This adds value but doesn't need to carry the full parameter burden; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource purpose: search XBRL financial concepts by keyword, statement group, or taxonomy. Clearly distinguishes itself from siblings by naming two specific consumers (secedgar_get_financials, secedgar_fetch_frames). Goes beyond a generic greeting to explain what the search returns and the reverse-lookup capability.
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?
Provides explicit when-to-use guidance: 'Use before secedgar_get_financials or secedgar_fetch_frames to discover the right friendly name'. This positions it as a discovery prerequisite relative to its likely siblings. Confirms the empty-search behavior (returns full catalog) without exclusions. The when-not scenario isn't stated, but the positive guidance is specific and directional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_search_filingsSecedgar Search FilingsARead-onlyIdempotentInspect
Search EDGAR filings since 1993. Full-text search covers 2001-present (the EFTS index floor); pre-2001 date ranges (to 1993) are served from the archives by form and entity/date. Pre-2001 free text needs entity scope (ticker:/cik:) — with it, the tool reads the entity's matching filings and matches the terms locally, which costs a few seconds (SEC's request rate caps the scan at roughly 5s for the 50-document maximum). A range crossing 2001-01-01 is split at the boundary and the two eras merged, each row tagged with its source. Supports exact phrases, boolean operators, wildcards, and entity targeting (ticker:AAPL or cik:320193 in query). When the match set outruns the inline list it is also staged as df_ — inspect it with secedgar_dataframe_describe, then analyze it with secedgar_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering. "filing_date_desc" (default) returns most recent first. "filing_date_asc" returns oldest first. "relevance" returns SEC's native search-score order, which weights term match strength over recency. Date sorts re-order the top 100 hits returned by the search index — for broad queries with more than 100 matches and no entity targeting, date-newest filings may sit outside that window. Entity targeting (ticker:/cik:) or a narrower query keeps matches inside the window when absolute recency matters. On the no-query browse path (forms/entity only), EFTS has no relevance signal — every hit scores null — and returns filings in natural date-descending order, so all sort modes effectively yield newest-first. Pre-2001 archive results carry no relevance score either, so relevance collapses to date-descending there. | filing_date_desc |
| forms | No | Filter to specific form types (e.g., ["10-K", "10-Q", "8-K"]). Without this, searches all form types. Note: "10-K" also matches amendments filed as 10-K/A. SEC renamed the blockholder schedules on 2024-12-18 — filings before that date are "SC 13D"/"SC 13G", filings after are "SCHEDULE 13D"/"SCHEDULE 13G" — so a filter spanning that boundary must list both spellings. Ownership forms (3, 4, 5) are indexed by the reporting person (e.g., "LEVINSON ARTHUR D"), not the issuer — rows carry no transaction code, share count, or price. Use secedgar_get_insider_transactions to retrieve parsed ownership XML with person, relationship, transaction code, shares, and price. | |
| limit | No | Results per page. Max 100. | |
| query | No | Full-text search query. Optional — omit (or pass "") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. The EFTS index that serves free text starts at 2001-01-01; a date range reaching earlier needs ticker:/cik: entity scope, which lets the tool read that entity's filings and match the terms locally (bounded to 50 documents, a few seconds at SEC's request rate), or drop the text terms to browse by form and date. When present, supports exact phrases ("material weakness"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default. A multi-class share ticker resolves in either form — ticker:BRK-B and ticker:BRK.B scope to the same issuer. The pre-2001 local scan honors the same phrase / OR / exclusion / wildcard syntax. | |
| offset | No | Pagination offset. For sort=relevance on a 2001-onward search, EDGAR pages server-side up to its 10,000-result cap. Everywhere else the offset indexes the rows this call assembled and sorted: a single 100-row window for date sorts and entity targeting, the full matched set on a pre-2001 archive path, or both together on a range that crosses 2001-01-01. Offsets at or past those rows return nothing even when total is larger — switch to sort=relevance for deep pagination on a 2001-onward search, narrow the search (forms, dates, entity targeting), or query the dataframe. On a crossing range the two sides are assembled unevenly — the archive side contributes every row it matched, the full-text side one window of its total — so once the window runs out the rows jump to the pre-2001 era with the remaining full-text matches absent from the middle; search the 2001-onward era on its own to page through those. | |
| end_date | No | End of date range (YYYY-MM-DD). Both start_date and end_date must be provided for date filtering. | |
| start_date | No | Start of date range (YYYY-MM-DD). Both start_date and end_date must be provided for date filtering. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied. |
| scan | No | Present only on the pre-2001 entity-scoped free-text path, where no full-text index exists and terms are matched by reading documents. Reports the scan's shape so a partial read is never presented as a complete one. Each document read is the whole accession .txt — SEC's original flat-submission format concatenates every exhibit into one file, and pre-1997 filings expose no per-document URL at all — so a match may sit in an attached exhibit rather than the body of the requested form. Absent on every other path. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of results shown inline. |
| total | No | Total matching filings, which can exceed the rows returned inline or materialized. On the full-text (2001+) path this is capped at 10,000; entity targeting (ticker:/cik:) scopes server-side via the EFTS ciks param, so it is the entity's exact match count up to the cap. On a pre-2001 archive path it is the exact count within the scanned window (see total_is_exact). On a range crossing 2001-01-01 it is the sum of both eras' counts. |
| notice | No | Guidance when no results were returned — echoes the query and suggests how to broaden. |
| dataset | No | Canvas dataframe holding the fetched hits (full-text window, or the full pre-2001 archive match set), each tagged with its `source`. Absent when total ≤ inline limit, canvas is unavailable, or materialization failed. Query with secedgar_dataframe_query SQL. |
| results | No | Matching filings. |
| truncated | No | True when results were capped by limit. |
| effectiveQuery | No | The query as executed against EDGAR (ticker/cik: tokens resolved to entity names). |
| total_is_exact | No | False when total is a lower bound — the full-text path hit its 10,000 cap, a pre-2001 archive scan hit its page/quarter cap before exhausting the range, or a pre-2001 local text scan hit its document cap (scan.capped). |
| form_distribution | No | Count of results by form type. Helps narrow follow-up searches. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is already covered. The description adds substantial behavioral context beyond annotations: the 2001 index boundary, the pre-2001 local scan cost (a few seconds, 50-document cap), the range-crossing split and merge behavior with source tags, the staging of large match sets as df_<id>, and the pagination caveats (date sorts re-order top 100 hits, offsets past assembled rows return nothing). This is rich, honest disclosure of non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich, with the most important scoping constraint (1993 coverage, 2001 full-text boundary) front-loaded. Every sentence earns its place, but the description is long and somewhat repetitive: the query parameter's supported syntax (phrases, boolean, wildcards, entity targeting) is stated in the main description and then restated almost verbatim in the query parameter description. The offset parameter description is also quite lengthy. Still, the structure is logical and the density is justified by the tool's complexity.
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 (7 parameters, 100% schema coverage, output schema present, annotations present), the description is remarkably complete. It covers the two-era data architecture, the pre-2001 local scan mechanics, the range-crossing merge behavior, pagination limits and workarounds, form-type nuances, and the dataframe staging workflow. An agent has everything needed to select this tool and invoke it correctly, including knowing when to switch to sort=relevance or narrow the search for deep pagination.
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. The description adds meaningful semantics beyond the schema: it explains the sort=relevance behavior on the no-query browse path and pre-2001 results, the 10-K/A amendment matching nuance, the SC 13D/SCHEDULE 13D rename boundary, the ownership form indexing by reporting person, the multi-class ticker resolution (BRK-B vs BRK.B), and the requirement that both start_date and end_date be provided. It doesn't add much beyond the schema for limit/offset, but the query and forms parameter descriptions are substantially enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Search EDGAR filings since 1993') and immediately distinguishes the tool's scope from siblings by explaining the 2001 full-text index boundary and the pre-2001 archive fallback. It clearly differentiates from sibling tools like secedgar_get_filing (retrieval of a specific filing) and secedgar_company_search (entity lookup) by focusing on full-text and form/entity browsing of filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: it explains when full-text search works (2001-present), when pre-2001 requires entity scope (ticker:/cik:), and when to browse by form/entity without a query. It also names alternatives: secedgar_dataframe_describe and secedgar_dataframe_query for inspecting/analyzing staged dataframes, and secedgar_get_insider_transactions for parsed ownership XML. This is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
12 tool updates
- Changed
secedgar_company_search1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_compare_companies2 fields changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query." - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when the inline matrix dropped periods, or when the full aligned series is staged as a dataframe.", + "type": "string" +}
- Changed
secedgar_dataframe_query4 fields changed- changed
Input schema / properties / row_limit / descriptionPrevious value: -"Hard cap on rows materialized in the response. Default 1000, max 10000. The full result lives on-canvas under register_as when provided — do not raise this to keep large results."New value: +"Hard cap on rows materialized in the response. Default 1000, max 10000. A query matching more rows than this stops at the cap and `row_count_capped` comes back true; the full result lives on-canvas under register_as when provided, so do not raise this to keep large results. One case is not detectable: a SQL LIMIT exactly equal to this cap reads identically to a result that genuinely holds that many rows, and is reported as exact." - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "columns", - "row_count", - "rows" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "columns", + "row_count", + "row_count_capped", + "rows" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / row_count / descriptionPrevious value: -"Total rows the query produced (may exceed `rows.length` when capped)."New value: +"Rows the query produced, up to `row_limit` (exceeds `rows.length` when `preview` returned fewer). Read it with `row_count_capped`: when that is true this number is the `row_limit` cap itself, and the size of the full result is not in this response." - added
Output schema / properties / row_count_cappedAdded value: +{ + "description": "True when the query matched more rows than `row_limit`, so `row_count` is that cap rather than a total. False means `row_count` is exact — including when it happens to equal `row_limit`.", + "type": "boolean" +}
- Changed
secedgar_fetch_frames1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_find_holders1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_get_beneficial_owners1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_get_financials2 fields changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query." - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when the inline series was capped, or when the full series is staged as a dataframe.", + "type": "string" +}
- Changed
secedgar_get_fund_holdings1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_get_insider_transactions1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_get_institutional_holdings1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_get_material_events1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
- Changed
secedgar_search_filings1 field changed- changed
Output schema / properties / dataset / properties / name / descriptionPrevious value: -"Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query."New value: +"Dataframe handle (df_XXXXX_XXXXX) — inspect its columns with secedgar_dataframe_describe, then query it with secedgar_dataframe_query."
1 tool update
- Changed
secedgar_get_filing1 field changed- changed
Input schema / properties / section / descriptionPrevious value: -"Jump to a named section by case-insensitive substring match against detected headings (e.g. 'risk factors', 'item 7', 'certain relationships'). Takes precedence over offset when both are provided. On a miss, the error message includes the detected outline so you can pick the correct heading."New value: +"Jump to a named section by case-insensitive substring match against detected headings (e.g. 'risk factors', 'item 7', 'certain relationships'). Matching also ignores whitespace and quote-style differences, so a heading copied from the outline resolves whether it carries the filing's non-breaking spaces and curly quotes or plain ones. Takes precedence over offset when both are provided. On a miss, the error message includes the detected outline so you can pick the correct heading."
2 tool updates
- Changed
secedgar_company_search1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Company ticker symbol (e.g., \"AAPL\", \"VOO\"), name (e.g., \"Apple\"), or CIK number (e.g., \"320193\"). Ticker is the fastest lookup and works for equities, ETFs, and mutual funds. Name search matches current and former names."New value: +"Company ticker symbol (e.g., \"AAPL\", \"VOO\"), name (e.g., \"Apple\"), or CIK number (e.g., \"320193\"). Ticker is the fastest lookup and works for equities, ETFs, and mutual funds; a multi-class share ticker resolves in either form (\"BRK-B\" or \"BRK.B\"). Name search matches current and former names, and the corporate suffix does not have to match the registry's form (\"Beacon Financial Corporation\" finds \"Beacon Financial Corp\") — but Corp, Inc, Co, and Ltd stay distinct from each other, since separate registrants differ only by which one they use."
- Changed
secedgar_search_filings1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. The EFTS index that serves free text starts at 2001-01-01; a date range reaching earlier needs ticker:/cik: entity scope, which lets the tool read that entity's filings and match the terms locally (bounded to 50 documents, a few seconds at SEC's request rate), or drop the text terms to browse by form and date. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default. The pre-2001 local scan honors the same phrase / OR / exclusion / wildcard syntax."New value: +"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. The EFTS index that serves free text starts at 2001-01-01; a date range reaching earlier needs ticker:/cik: entity scope, which lets the tool read that entity's filings and match the terms locally (bounded to 50 documents, a few seconds at SEC's request rate), or drop the text terms to browse by form and date. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default. A multi-class share ticker resolves in either form — ticker:BRK-B and ticker:BRK.B scope to the same issuer. The pre-2001 local scan honors the same phrase / OR / exclusion / wildcard syntax."
1 tool update
- Changed
secedgar_get_financials4 fields changed- removed
Output schema / properties / data / items / properties / fiscal_period / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / data / items / properties / fiscal_period / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / data / items / properties / fiscal_year / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / data / items / properties / fiscal_year / typeAdded value: +[ + "number", + "null" +]
16 tool updates
- Changed
secedgar_company_search10 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "cik", + "name", + "tickers", + "exchanges", + "sic", + "sic_description" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / capAdded value: +{ + "description": "The `filing_limit` that was applied.", + "type": "number" +} - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_match`: No company matches the query `multiple_matches`: Query is ambiguous and matches several companies Other values are possible when a failure originates below the handler.", + "examples": [ + "no_match", + "multiple_matches" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when include_filings=true but no filings matched the form_types filter."New value: +"Guidance when include_filings=true but no filings matched the form_types filter, or when filing_limit withheld some." - added
Output schema / properties / shownAdded value: +{ + "description": "Number of filings returned inline.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when more filings matched than `filing_limit` allowed into the inline list.", + "type": "boolean" +} - removed
Output schema / requiredRemoved value: -[ - "cik", - "name", - "tickers", - "exchanges", - "sic", - "sic_description" -]
- Changed
secedgar_compare_companies6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "period_type", + "taxonomy", + "periods", + "companies", + "failed_companies", + "concepts", + "cells", + "gaps", + "caveats" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_companies_resolved`: None of the supplied company inputs resolved to a CIK `no_comparable_data`: Companies resolved but not one of them reports any of the requested concepts for the requested period type Other values are possible when a failure originates below the handler.", + "examples": [ + "no_companies_resolved", + "no_comparable_data" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "period_type", - "taxonomy", - "periods", - "companies", - "failed_companies", - "concepts", - "cells", - "gaps", - "caveats" -]
- Changed
secedgar_dataframe_describe6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "dataframes" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `canvas_unavailable`: The DataCanvas service is not configured for this deployment Other values are possible when a failure originates below the handler.", + "examples": [ + "canvas_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "dataframes" -]
- Changed
secedgar_dataframe_query10 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "columns", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / capAdded value: +{ + "description": "The row cap that actually bound — `preview` when it is lower than `row_limit`, otherwise `row_limit`.", + "type": "number" +} - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `canvas_unavailable`: The DataCanvas service is not configured for this deployment `system_catalog_access`: The SQL query references a denied DuckDB system catalog (information_schema, pg_catalog, sqlite_master, duckdb_*) `missing_table`: The SQL query references a df_<id> table that does not exist or has expired `invalid_sql`: The SQL statement contains a syntax or execution error not covered by a more specific reason `register_as_clash`: The register_as target name already exists on the canvas `non_select_statement`: The SQL is a non-SELECT statement (DROP, INSERT, UPDATE, DDL, etc.) — only read-only SELECTs run against dataframes Other values are possible when a failure originates below the handler.", + "examples": [ + "canvas_unavailable", + "system_catalog_access", + "missing_table", + "invalid_sql", + "register_as_clash", + "non_select_statement" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when the query returned no rows, or when results were capped."New value: +"Guidance when the query returned no rows, or when the row cap withheld some." - added
Output schema / properties / shownAdded value: +{ + "description": "Number of rows returned inline.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when the result set held more rows than the row cap allowed through.", + "type": "boolean" +} - removed
Output schema / requiredRemoved value: -[ - "columns", - "row_count", - "rows" -]
- Changed
secedgar_fetch_frames6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "concept", + "period", + "unit", + "label", + "total_companies", + "offset", + "data", + "unqueried_tags", + "related_tags", + "value_distribution", + "period_end_range", + "caveats" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `unknown_concept`: The concept input does not match a friendly name and SEC frames returned no data `no_data`: Concept resolves but no companies report this metric for the requested period and unit Other values are possible when a failure originates below the handler.", + "examples": [ + "unknown_concept", + "no_data" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "concept", - "period", - "unit", - "label", - "total_companies", - "offset", - "data", - "unqueried_tags", - "related_tags", - "value_distribution", - "period_end_range", - "caveats" -]
- Changed
secedgar_find_holders6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "issuer", + "search_mode", + "search_key", + "quarter", + "filed_from", + "filed_to", + "total_filings", + "total_is_exact", + "fetched", + "holders_in_quarter", + "holders", + "ordering" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `issuer_not_found`: No cusip was given and the issuer does not resolve to a known EDGAR company `ambiguous_issuer`: The issuer name matches several EDGAR companies and no cusip was given Other values are possible when a failure originates below the handler.", + "examples": [ + "issuer_not_found", + "ambiguous_issuer" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "issuer", - "search_mode", - "search_key", - "quarter", - "filed_from", - "filed_to", - "total_filings", - "total_is_exact", - "fetched", - "holders_in_quarter", - "holders", - "ordering" -]
- Changed
secedgar_get_beneficial_owners6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "issuer", + "issuer_cik", + "issuer_name", + "form_kind", + "total_structured_filings", + "filings_parsed", + "structured_coverage_from", + "legacy_filings_before_coverage", + "filings" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `issuer_not_found`: The issuer input does not resolve to a known EDGAR company `ambiguous_issuer`: The issuer name matches several EDGAR companies `no_filings_found`: The issuer has no structured SCHEDULE 13D/13G filings matching the requested form kind Other values are possible when a failure originates below the handler.", + "examples": [ + "issuer_not_found", + "ambiguous_issuer", + "no_filings_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "issuer", - "issuer_cik", - "issuer_name", - "form_kind", - "total_structured_filings", - "filings_parsed", - "structured_coverage_from", - "legacy_filings_before_coverage", - "filings" -]
- Changed
secedgar_get_filing11 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "accession_number", + "cik", + "primary_document", + "documents", + "content", + "content_truncated", + "content_total_length", + "filing_url" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / capAdded value: +{ + "description": "The `content_limit` that was applied.", + "type": "number" +} - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `document_not_found`: A specific document was requested but not present in the filing archive `no_documents`: Filing index lists items but no fetchable primary document was found `binary_document`: The requested document is a binary entry (scanned image, PDF, archive) with no text to return `filing_not_found`: No filing matches the accession number under any candidate CIK `offset_out_of_range`: The provided offset is at or beyond the end of the document `section_not_found`: The section string did not match any detected heading in the document Other values are possible when a failure originates below the handler.", + "examples": [ + "document_not_found", + "no_documents", + "binary_document", + "filing_not_found", + "offset_out_of_range", + "section_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance on reading the next page when the content was capped.", + "type": "string" +} - changed
Output schema / properties / outline / descriptionPrevious value: -"Document outline — detected headings with their character offsets. Present on the first page of a truncated response (offset=0, no section). Use a heading offset as offset, or pass heading text as section, to jump to that section."New value: +"Document outline — up to 50 detected headings with their character offsets. Present on the first page of a truncated response (offset=0, no section). Use a heading offset as offset, or pass heading text as section, to jump to that section." - added
Output schema / properties / shownAdded value: +{ + "description": "Characters of document text returned on this page.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when the document is longer than `content_limit` allowed through.", + "type": "boolean" +} - removed
Output schema / requiredRemoved value: -[ - "accession_number", - "cik", - "primary_document", - "documents", - "content", - "content_truncated", - "content_total_length", - "filing_url" -]
- Changed
secedgar_get_financials6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "company", + "cik", + "concept", + "label", + "unit", + "data" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `company_not_found`: The company input does not resolve to a CIK `ambiguous_company`: The company input resolves to multiple entities and the target is ambiguous `no_concept_data`: The company does not report any XBRL data for the resolved concept and taxonomy `no_frame_data`: Concept exists but has no frame-aligned (standard calendar period) entries `no_period_data`: Concept has data but the period_type filter excluded all of it Other values are possible when a failure originates below the handler.", + "examples": [ + "company_not_found", + "ambiguous_company", + "no_concept_data", + "no_frame_data", + "no_period_data" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "company", - "cik", - "concept", - "label", - "unit", - "data" -]
- Changed
secedgar_get_fund_holdings6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "fund", + "class_ids", + "registrant_cik", + "registrant_name", + "filing_date", + "form", + "accession_number", + "total_holdings", + "offset", + "available_report_periods", + "holdings", + "as_of" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `fund_not_found`: The fund input resolves to neither an EDGAR company nor a known fund series `ambiguous_fund`: The fund name matches several EDGAR companies `series_required`: The input resolves to a registrant trust that files reports for more than one fund series `no_filings_found`: No NPORT-P report exists for this fund, or none for the requested report_date Other values are possible when a failure originates below the handler.", + "examples": [ + "fund_not_found", + "ambiguous_fund", + "series_required", + "no_filings_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "fund", - "class_ids", - "registrant_cik", - "registrant_name", - "filing_date", - "form", - "accession_number", - "total_holdings", - "offset", - "available_report_periods", - "holdings", - "as_of" -]
- Changed
secedgar_get_insider_transactions6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "issuer_name", + "issuer_cik", + "transactions", + "filings_scanned" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `company_not_found`: The ticker or CIK does not resolve to a known company `no_filings_found`: No Form 4 filings exist for this company in the recent submissions window Other values are possible when a failure originates below the handler.", + "examples": [ + "company_not_found", + "no_filings_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "issuer_name", - "issuer_cik", - "transactions", - "filings_scanned" -]
- Changed
secedgar_get_institutional_holdings6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "filer_name", + "filer_cik", + "filing_date", + "accession_number", + "total_holdings_in_filing", + "offset", + "holdings" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `company_not_found`: The ticker or CIK does not resolve to a known company or institution `ambiguous_entity`: The name resolves to multiple EDGAR entities (e.g. several filers sharing a legal name) `no_filings_found`: No 13F-HR filings found for this entity in the recent submissions window `no_info_table`: The 13F-HR filing was found but the information table XML document could not be located Other values are possible when a failure originates below the handler.", + "examples": [ + "company_not_found", + "ambiguous_entity", + "no_filings_found", + "no_info_table" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "filer_name", - "filer_cik", - "filing_date", - "accession_number", - "total_holdings_in_filing", - "offset", - "holdings" -]
- Changed
secedgar_get_material_events6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "cik", + "company_name", + "total_matched", + "total_8k_scanned", + "item_distribution", + "filings" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_match`: No company matches the query `multiple_matches`: The query is ambiguous and matches several companies Other values are possible when a failure originates below the handler.", + "examples": [ + "no_match", + "multiple_matches" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "cik", - "company_name", - "total_matched", - "total_8k_scanned", - "item_distribution", - "filings" -]
- Changed
secedgar_get_snapshot6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "company", + "cik", + "taxonomy", + "period_type", + "concepts_resolved", + "concepts_total", + "lines", + "gaps", + "caveats" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `company_not_found`: The company input does not resolve to a CIK `ambiguous_company`: The company input resolves to multiple entities and the target is ambiguous `no_company_facts`: The filer has no XBRL facts at all — pre-XBRL, foreign private issuer, or a non-operating registrant Other values are possible when a failure originates below the handler.", + "examples": [ + "company_not_found", + "ambiguous_company", + "no_company_facts" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "company", - "cik", - "taxonomy", - "period_type", - "concepts_resolved", - "concepts_total", - "lines", - "gaps", - "caveats" -]
- Changed
secedgar_search_concepts6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "concepts" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "concepts" -]
- Changed
secedgar_search_filings6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "total_is_exact", + "results", + "effectiveQuery" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_date_range`: Only one of start_date or end_date was provided `unresolved_ticker`: A ticker: targeting token in the query does not resolve to a known company `invalid_cik`: A cik: targeting token in the query is not a 1-10 digit number `entity_not_found`: A cik: targeting token on a pre-2001 date range names a CIK with no EDGAR submissions history `missing_criteria`: Neither a full-text query nor a forms filter was provided (a date range cannot stand alone) `pre2001_full_text_unscoped`: A date range reaching before 2001-01-01 carries free-text terms with no entity scope — no pre-2001 full-text index exists, and nothing bounds a local scan Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_date_range", + "unresolved_ticker", + "invalid_cik", + "entity_not_found", + "missing_criteria", + "pre2001_full_text_unscoped" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "total_is_exact", - "results", - "effectiveQuery" -]
3 tool updates
- Added
secedgar_get_beneficial_owners - Added
secedgar_get_fund_holdings - Changed
secedgar_search_filings12 fields changed- changed
Input schema / properties / forms / descriptionPrevious value: -"Filter to specific form types (e.g., [\"10-K\", \"10-Q\", \"8-K\"]). Without this, searches all form types. Note: \"10-K\" also matches amendments filed as 10-K/A. Ownership forms (3, 4, 5) are indexed by the reporting person (e.g., \"LEVINSON ARTHUR D\"), not the issuer — rows carry no transaction code, share count, or price. Use secedgar_get_insider_transactions to retrieve parsed ownership XML with person, relationship, transaction code, shares, and price."New value: +"Filter to specific form types (e.g., [\"10-K\", \"10-Q\", \"8-K\"]). Without this, searches all form types. Note: \"10-K\" also matches amendments filed as 10-K/A. SEC renamed the blockholder schedules on 2024-12-18 — filings before that date are \"SC 13D\"/\"SC 13G\", filings after are \"SCHEDULE 13D\"/\"SCHEDULE 13G\" — so a filter spanning that boundary must list both spellings. Ownership forms (3, 4, 5) are indexed by the reporting person (e.g., \"LEVINSON ARTHUR D\"), not the issuer — rows carry no transaction code, share count, or price. Use secedgar_get_insider_transactions to retrieve parsed ownership XML with person, relationship, transaction code, shares, and price." - changed
Input schema / properties / offset / descriptionPrevious value: -"Pagination offset. For sort=relevance, EDGAR pages server-side up to its 10,000-result cap. For date sorts (the default) and entity targeting, the tool fetches a single 100-row window and slices it client-side — offsets at or past the window return nothing; switch to sort=relevance for deep pagination, or narrow the search (forms, dates, entity targeting)."New value: +"Pagination offset. For sort=relevance on a 2001-onward search, EDGAR pages server-side up to its 10,000-result cap. Everywhere else the offset indexes the rows this call assembled and sorted: a single 100-row window for date sorts and entity targeting, the full matched set on a pre-2001 archive path, or both together on a range that crosses 2001-01-01. Offsets at or past those rows return nothing even when total is larger — switch to sort=relevance for deep pagination on a 2001-onward search, narrow the search (forms, dates, entity targeting), or query the dataframe. On a crossing range the two sides are assembled unevenly — the archive side contributes every row it matched, the full-text side one window of its total — so once the window runs out the rows jump to the pre-2001 era with the remaining full-text matches absent from the middle; search the 2001-onward era on its own to page through those." - changed
Input schema / properties / query / descriptionPrevious value: -"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. Full-text terms match only filings from 2001 onward (the EFTS index floor); for a pre-2001 date range, drop the text terms (browse by form/date) or add ticker:/cik: entity scope. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default."New value: +"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. The EFTS index that serves free text starts at 2001-01-01; a date range reaching earlier needs ticker:/cik: entity scope, which lets the tool read that entity's filings and match the terms locally (bounded to 50 documents, a few seconds at SEC's request rate), or drop the text terms to browse by form and date. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default. The pre-2001 local scan honors the same phrase / OR / exclusion / wildcard syntax." - changed
Output schema / properties / results / items / properties / file_description / descriptionPrevious value: -"SEC-provided description of the matching document (e.g., \"EX-99.1\"). Absent when SEC published none, and for pre-2001 archive-sourced rows."New value: +"SEC-provided description of the matching document (e.g., \"EX-99.1\"). Absent when SEC published none, and for pre-2001 archive-sourced rows. A range crossing 2001-01-01 returns both kinds of row together, so this field is populated on source=efts rows only." - changed
Output schema / properties / results / items / properties / location / descriptionPrevious value: -"Business location (state or country code). Absent when SEC has no location for this filer, and for pre-2001 archive-sourced rows."New value: +"Business location (state or country code). Absent when SEC has no location for this filer, and for pre-2001 archive-sourced rows. A range crossing 2001-01-01 returns both kinds of row together, so this field is populated on source=efts rows only." - changed
Output schema / properties / results / items / properties / period_ending / descriptionPrevious value: -"Period the filing reports on (YYYY-MM-DD). Absent for filings without a reporting period (e.g., proxy statements, ownership reports) and for all pre-2001 archive-sourced rows (source submissions/full-index), which carry no period field."New value: +"Period the filing reports on (YYYY-MM-DD). Absent for filings without a reporting period (e.g., proxy statements, ownership reports) and for all pre-2001 archive-sourced rows (source submissions/full-index), which carry no period field. A range crossing 2001-01-01 returns both kinds of row together, so this field is populated on source=efts rows only." - changed
Output schema / properties / results / items / properties / sic / descriptionPrevious value: -"SIC industry code for the filer. Absent for filers without a classification, and for pre-2001 archive-sourced rows."New value: +"SIC industry code for the filer. Absent for filers without a classification, and for pre-2001 archive-sourced rows. A range crossing 2001-01-01 returns both kinds of row together, so this field is populated on source=efts rows only." - changed
Output schema / properties / results / items / properties / source / descriptionPrevious value: -"Which EDGAR backend served this row: \"efts\" (2001+ full-text index), \"submissions\" (a pre-2001 entity-scoped filing history), or \"full-index\" (a pre-2001 unscoped quarterly index browse). Provenance is carried into the canvas dataframe as a `source` column."New value: +"Which EDGAR backend served this row: \"efts\" (2001+ full-text index), \"submissions\" (a pre-2001 entity-scoped filing history), or \"full-index\" (a pre-2001 unscoped quarterly index browse). A date range crossing 2001-01-01 is split at the boundary and returns rows of two sources in one result set, so read this per row rather than per result. Provenance is carried into the canvas dataframe as a `source` column." - changed
Output schema / properties / results / items / properties / ticker / descriptionPrevious value: -"Primary ticker symbol parsed from the EFTS display name. Absent for private filers, foreign filers without a US listing, filings whose display name omits the ticker parenthetical, and all pre-2001 archive-sourced rows. For multi-class issuers (e.g., BRK-A / BRK-B), this is the first class listed."New value: +"Primary ticker symbol parsed from the EFTS display name. Absent for private filers, foreign filers without a US listing, filings whose display name omits the ticker parenthetical, and all pre-2001 archive-sourced rows. A range crossing 2001-01-01 returns both kinds of row together, so this field is populated on source=efts rows only. For multi-class issuers (e.g., BRK-A / BRK-B), this is the first class listed." - added
Output schema / properties / scanAdded value: +{ + "additionalProperties": false, + "description": "Present only on the pre-2001 entity-scoped free-text path, where no full-text index exists and terms are matched by reading documents. Reports the scan's shape so a partial read is never presented as a complete one. Each document read is the whole accession .txt — SEC's original flat-submission format concatenates every exhibit into one file, and pre-1997 filings expose no per-document URL at all — so a match may sit in an attached exhibit rather than the body of the requested form. Absent on every other path.", + "properties": { + "candidates": { + "description": "Filings the form + date pre-filter selected before any document was read.", + "type": "number" + }, + "capped": { + "description": "True when candidates exceeded the document cap, so the unscanned remainder may hold further matches — narrow the form or date filter to bring them into range.", + "type": "boolean" + }, + "matched": { + "description": "Scanned filings whose text satisfied the query terms.", + "type": "number" + }, + "scanned": { + "description": "Candidate documents actually fetched and matched against. Capped at 50 per call.", + "type": "number" + } + }, + "required": [ + "candidates", + "scanned", + "matched", + "capped" + ], + "type": "object" +} - changed
Output schema / properties / total / descriptionPrevious value: -"Total matching filings. On the full-text (2001+) path this is capped at 10,000; entity targeting (ticker:/cik:) scopes server-side via the EFTS ciks param, so it is the entity's exact match count up to the cap. On a pre-2001 archive path it is the exact count within the scanned window (see total_is_exact)."New value: +"Total matching filings, which can exceed the rows returned inline or materialized. On the full-text (2001+) path this is capped at 10,000; entity targeting (ticker:/cik:) scopes server-side via the EFTS ciks param, so it is the entity's exact match count up to the cap. On a pre-2001 archive path it is the exact count within the scanned window (see total_is_exact). On a range crossing 2001-01-01 it is the sum of both eras' counts." - changed
Output schema / properties / total_is_exact / descriptionPrevious value: -"False when total is a lower bound — the full-text path hit its 10,000 cap, or a pre-2001 archive scan hit its page/quarter cap before exhausting the range."New value: +"False when total is a lower bound — the full-text path hit its 10,000 cap, a pre-2001 archive scan hit its page/quarter cap before exhausting the range, or a pre-2001 local text scan hit its document cap (scan.capped)."
6 tool updates
- Changed
secedgar_compare_companies1 field changed- changed
Output schema / properties / caveats / descriptionPrevious value: -"Comparability warnings: a filer missing one or two calendar quarters from the frame-tagged series, a concept that resolved to an XBRL tag SEC has retired (so that company's values may stop years short of the others'), period ends that differ inside one aligned period, and concepts whose unit differs across companies. Company-specific warnings are prefixed with the company name. Empty when nothing needs flagging."New value: +"Comparability warnings: a filer missing one or two calendar quarters from the frame-tagged series, a concept whose values stop at least two full years behind the rest of that company's reporting (either an XBRL tag SEC has retired, or a current tag the filer stopped using), period ends that differ inside one aligned period, and concepts whose unit differs across companies. Company-specific warnings are prefixed with the company name. Empty when nothing needs flagging."
- Added
secedgar_find_holders - Changed
secedgar_get_financials1 field changed- changed
Output schema / properties / caveats / descriptionPrevious value: -"Data-completeness warnings about the returned series. Two kinds. On quarterly results, one entry when one or two calendar quarters are absent from every recent qualifying year — SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact, so the calendar quarter fiscal Q4 spans has no frame-tagged value, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. Applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. On any result, one entry when the concept resolved to an XBRL tag SEC has retired from the taxonomy, which means the current tags reported nothing and the series may stop years short. Absent when the series has nothing to flag."New value: +"Data-completeness warnings about the returned series. Two kinds. On quarterly results, one entry when one or two calendar quarters are absent from every recent qualifying year — SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact, so the calendar quarter fiscal Q4 spans has no frame-tagged value, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. Applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. On any result, one entry when the series stops well short of today — either because the concept resolved to an XBRL tag SEC has retired from the taxonomy (the current tags reported nothing), or because a current tag's series ends more than two years plus a filing window back, which is what a filer migrating to a different element or dropping the disclosure looks like. Absent when the series has nothing to flag."
- Changed
secedgar_get_institutional_holdings1 field changed- changed
Input schema / properties / ticker_or_cik / descriptionPrevious value: -"The institutional filer whose 13F to fetch — a 10-digit CIK (e.g. \"0000102909\" for VANGUARD GROUP INC, the most reliable form) or an entity name. Names resolve through EDGAR entity search, which covers institutional managers absent from the ticker file; a name matching several filers (some legal names are shared across entities) returns those candidates so you can retry with the exact CIK. This is NOT the portfolio company — passing an issuer ticker like \"AAPL\" finds that operating company's own filings (it files no 13F), not who holds it."New value: +"The institutional filer whose 13F to fetch — a 10-digit CIK (e.g. \"0000102909\" for VANGUARD GROUP INC, the most reliable form) or an entity name. Names resolve through EDGAR entity search, which covers institutional managers absent from the ticker file; a name matching several filers (some legal names are shared across entities) returns those candidates so you can retry with the exact CIK. This is NOT the portfolio company — passing an issuer ticker like \"AAPL\" finds that operating company's own filings (it files no 13F), not who holds it; use secedgar_find_holders for that direction."
- Added
secedgar_get_material_events - Changed
secedgar_get_snapshot1 field changed- changed
Output schema / properties / caveats / descriptionPrevious value: -"Data-completeness warnings. One entry when one or two calendar quarters are absent from every recent qualifying year, because SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact — this applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. One further entry per line that resolved to an XBRL tag SEC has retired from the taxonomy, whose values may stop years short of the filer's latest report. Empty when nothing needs flagging."New value: +"Data-completeness warnings. One entry when one or two calendar quarters are absent from every recent qualifying year, because SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact — this applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. One further entry, prefixed with the concept name, per line whose values stop at least two full years behind the newest period this filer reports anywhere in the profile — either because the line resolved to an XBRL tag SEC has retired from the taxonomy, or because a current tag's series simply ends, which is what a migration to a different element or a dropped disclosure looks like. Empty when nothing needs flagging."
5 tool updates
- Changed
secedgar_compare_companies2 fields changed- changed
Input schema / properties / period_type / descriptionPrevious value: -"Align on full calendar years (annual) or calendar quarters (quarterly). Quarterly comparisons of off-calendar filers are missing one calendar quarter per year — see caveats."New value: +"Align on full calendar years (annual) or calendar quarters (quarterly). Quarterly comparisons of off-calendar filers are missing at least one calendar quarter per year — see caveats." - changed
Output schema / properties / caveats / descriptionPrevious value: -"Comparability warnings: a filer missing a calendar quarter from the frame-tagged series, period ends that differ inside one aligned period, and concepts whose unit differs across companies. Empty when nothing needs flagging."New value: +"Comparability warnings: a filer missing one or two calendar quarters from the frame-tagged series, a concept that resolved to an XBRL tag SEC has retired (so that company's values may stop years short of the others'), period ends that differ inside one aligned period, and concepts whose unit differs across companies. Company-specific warnings are prefixed with the company name. Empty when nothing needs flagging."
- Changed
secedgar_get_filing10 fields changed- changed
Input schema / properties / document / descriptionPrevious value: -"Specific document filename within the filing (e.g., \"ex-21.htm\" for subsidiaries list). Default: the primary document. Available documents listed in the response metadata."New value: +"Specific document filename within the filing (e.g., \"ex-21.htm\" for subsidiaries list). Default: the primary document. Available documents are listed in the response metadata under documents; entries marked binary hold no text and are rejected." - changed
Output schema / properties / documents / descriptionPrevious value: -"Filing documents grouped by category. Names from any list are valid values for the document input. XBRL viewer artifacts are suppressed by default; setting include_xbrl=true surfaces them under the xbrl bucket."New value: +"Filing documents grouped by category. Every name is a valid document input EXCEPT entries carrying binary: true — scanned pages, PDFs, packaged archives and spreadsheets, which hold no text and are rejected with a binary_document error. Scans can outnumber readable documents in a filing, so read the flag before picking a name. XBRL viewer artifacts are suppressed by default; setting include_xbrl=true surfaces them under the xbrl bucket." - added
Output schema / properties / documents / properties / auxiliary / items / properties / binaryAdded value: +{ + "description": "Present and true when the entry holds binary bytes — a scanned page or logo, a PDF exhibit, a packaged archive or spreadsheet. These cannot be converted to text and are rejected by the document input. Absent for readable entries.", + "type": "boolean" +} - changed
Output schema / properties / documents / properties / auxiliary / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), \"GRAPHIC\"/\"PDF\"/\"BINARY\" for known binary file extensions, and \"unknown\" for everything else." - added
Output schema / properties / documents / properties / exhibits / items / properties / binaryAdded value: +{ + "description": "Present and true when the entry holds binary bytes — a scanned page or logo, a PDF exhibit, a packaged archive or spreadsheet. These cannot be converted to text and are rejected by the document input. Absent for readable entries.", + "type": "boolean" +} - changed
Output schema / properties / documents / properties / exhibits / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), \"GRAPHIC\"/\"PDF\"/\"BINARY\" for known binary file extensions, and \"unknown\" for everything else." - added
Output schema / properties / documents / properties / primary / items / properties / binaryAdded value: +{ + "description": "Present and true when the entry holds binary bytes — a scanned page or logo, a PDF exhibit, a packaged archive or spreadsheet. These cannot be converted to text and are rejected by the document input. Absent for readable entries.", + "type": "boolean" +} - changed
Output schema / properties / documents / properties / primary / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), \"GRAPHIC\"/\"PDF\"/\"BINARY\" for known binary file extensions, and \"unknown\" for everything else." - added
Output schema / properties / documents / properties / xbrl / items / properties / binaryAdded value: +{ + "description": "Present and true when the entry holds binary bytes — a scanned page or logo, a PDF exhibit, a packaged archive or spreadsheet. These cannot be converted to text and are rejected by the document input. Absent for readable entries.", + "type": "boolean" +} - changed
Output schema / properties / documents / properties / xbrl / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), \"GRAPHIC\"/\"PDF\"/\"BINARY\" for known binary file extensions, and \"unknown\" for everything else."
- Changed
secedgar_get_financials1 field changed- changed
Output schema / properties / caveats / descriptionPrevious value: -"Data-completeness warnings about the returned series. Populated on quarterly results when one calendar quarter is absent from every recent fully-reported year — SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact, so the calendar quarter that fiscal Q4 spans has no frame-tagged value. Applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. Absent when the series has nothing to flag."New value: +"Data-completeness warnings about the returned series. Two kinds. On quarterly results, one entry when one or two calendar quarters are absent from every recent qualifying year — SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact, so the calendar quarter fiscal Q4 spans has no frame-tagged value, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. Applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. On any result, one entry when the concept resolved to an XBRL tag SEC has retired from the taxonomy, which means the current tags reported nothing and the series may stop years short. Absent when the series has nothing to flag."
- Changed
secedgar_get_snapshot1 field changed- changed
Output schema / properties / caveats / descriptionPrevious value: -"Data-completeness warnings about the quarterly values. Populated when one calendar quarter is absent from every recent fully-reported year, because SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact — this applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. Empty when nothing needs flagging."New value: +"Data-completeness warnings. One entry when one or two calendar quarters are absent from every recent qualifying year, because SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact — this applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones, and a filer whose other fiscal quarters span non-calendar durations loses a second quarter the same way. One further entry per line that resolved to an XBRL tag SEC has retired from the taxonomy, whose values may stop years short of the filer's latest report. Empty when nothing needs flagging."
- Changed
secedgar_search_concepts2 fields changed- added
Output schema / properties / concepts / items / properties / ifrs_tagsAdded value: +{ + "description": "XBRL tags this friendly name resolves to under taxonomy \"ifrs-full\", tried in order — a different element set from tags, not a synonym list. Each one is confirmed present in a live 20-F filing. Absent when the concept has no IFRS equivalent, in which case taxonomy \"ifrs-full\" does not resolve it.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / concepts / items / properties / tags / descriptionPrevious value: -"XBRL tags this friendly name resolves to, tried in order. Multiple tags cover historical naming changes (e.g., pre- vs post-ASC 606 revenue)."New value: +"XBRL tags this friendly name resolves to under us-gaap, tried in order. Multiple tags cover historical naming changes (e.g., pre- vs post-ASC 606 revenue) and can include a tag SEC has since retired, kept as a last-resort fallback for filers whose history predates its replacement."
3 tool updates
- Added
secedgar_compare_companies - Changed
secedgar_get_financials1 field changed- added
Output schema / properties / caveatsAdded value: +{ + "description": "Data-completeness warnings about the returned series. Populated on quarterly results when one calendar quarter is absent from every recent fully-reported year — SEC reports a filer's fiscal Q4 as the 10-K residual rather than a discrete quarterly fact, so the calendar quarter that fiscal Q4 spans has no frame-tagged value. Applies to calendar-year filers (no discrete Q4) as much as to off-calendar ones. Absent when the series has nothing to flag.", + "items": { + "type": "string" + }, + "type": "array" +}
- Added
secedgar_get_snapshot
2 tool updates
- Changed
secedgar_fetch_frames5 fields changed- added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Rank to start the page at, 0-based, over the sorted frame. Pass the next_offset from the previous response to read the next page — the ranked list is fetched whole and sliced, so paging is stable and gap-free. An offset at or past total_companies returns an empty page.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / next_offsetAdded value: +{ + "description": "Offset to pass on the next call to continue down the ranking. Absent on the last page (no companies remain past this one).", + "type": "number" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when the requested offset lands past the end of the ranked list.", + "type": "string" +} - added
Output schema / properties / offsetAdded value: +{ + "description": "Rank the returned page starts at, 0-based — the effective offset applied.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "concept", - "period", - "unit", - "label", - "total_companies", - "data", - "unqueried_tags", - "related_tags", - "value_distribution", - "period_end_range", - "caveats" -]New value: +[ + "concept", + "period", + "unit", + "label", + "total_companies", + "offset", + "data", + "unqueried_tags", + "related_tags", + "value_distribution", + "period_end_range", + "caveats" +]
- Changed
secedgar_get_institutional_holdings5 fields changed- added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Row to start the page at, 0-based, over the ordered position list. Pass the next_offset from the previous response to read the next page — the filing is parsed whole and sliced, so paging is stable and gap-free. An offset at or past the position count returns an empty page.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - changed
Output schema / properties / holdings / descriptionPrevious value: -"Holdings truncated to limit — consolidated positions sorted by market value when consolidate=true, else raw information-table rows in filing order."New value: +"One page of holdings, `limit` rows starting at `offset` — consolidated positions sorted by market value when consolidate=true, else raw information-table rows in filing order." - added
Output schema / properties / next_offsetAdded value: +{ + "description": "Offset to pass on the next call to continue through the positions. Absent on the last page (no rows remain past this one).", + "type": "number" +} - added
Output schema / properties / offsetAdded value: +{ + "description": "Row the returned page starts at, 0-based — the effective offset applied.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "filer_name", - "filer_cik", - "filing_date", - "accession_number", - "total_holdings_in_filing", - "holdings" -]New value: +[ + "filer_name", + "filer_cik", + "filing_date", + "accession_number", + "total_holdings_in_filing", + "offset", + "holdings" +]
1 tool update
- Changed
secedgar_search_filings13 fields changed- changed
Input schema / properties / query / descriptionPrevious value: -"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default."New value: +"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. Full-text terms match only filings from 2001 onward (the EFTS index floor); for a pre-2001 date range, drop the text terms (browse by form/date) or add ticker:/cik: entity scope. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default." - changed
Input schema / properties / sort / descriptionPrevious value: -"Result ordering. \"filing_date_desc\" (default) returns most recent first. \"filing_date_asc\" returns oldest first. \"relevance\" returns SEC's native search-score order, which weights term match strength over recency. Date sorts re-order the top 100 hits returned by the search index — for broad queries with more than 100 matches and no entity targeting, date-newest filings may sit outside that window. Entity targeting (ticker:/cik:) or a narrower query keeps matches inside the window when absolute recency matters. On the no-query browse path (forms/entity only), EFTS has no relevance signal — every hit scores null — and returns filings in natural date-descending order, so all sort modes effectively yield newest-first."New value: +"Result ordering. \"filing_date_desc\" (default) returns most recent first. \"filing_date_asc\" returns oldest first. \"relevance\" returns SEC's native search-score order, which weights term match strength over recency. Date sorts re-order the top 100 hits returned by the search index — for broad queries with more than 100 matches and no entity targeting, date-newest filings may sit outside that window. Entity targeting (ticker:/cik:) or a narrower query keeps matches inside the window when absolute recency matters. On the no-query browse path (forms/entity only), EFTS has no relevance signal — every hit scores null — and returns filings in natural date-descending order, so all sort modes effectively yield newest-first. Pre-2001 archive results carry no relevance score either, so relevance collapses to date-descending there." - changed
Output schema / properties / dataset / descriptionPrevious value: -"Canvas dataframe holding the hits already fetched for the inline response. Absent when total ≤ inline limit, canvas is unavailable, or materialization failed. The dataframe contains the raw EFTS results (entity-scoped server-side via the ciks param when ticker:/cik: was used) — query with secedgar_dataframe_query SQL."New value: +"Canvas dataframe holding the fetched hits (full-text window, or the full pre-2001 archive match set), each tagged with its `source`. Absent when total ≤ inline limit, canvas is unavailable, or materialization failed. Query with secedgar_dataframe_query SQL." - changed
Output schema / properties / dataset / properties / truncated / descriptionPrevious value: -"True when EFTS reported more text matches than the window we already fetched — additional rows exist beyond the dataframe. Page further with `offset` for the inline view; the canvas dataframe is bounded by the single response window."New value: +"True when more matches exist beyond the materialized set — the full-text window was exceeded, or a pre-2001 archive scan hit its cap. Each row carries a `source` column so provenance survives into secedgar_dataframe_query." - changed
Output schema / properties / results / items / descriptionPrevious value: -"One matching filing hit from the full-text search index."New value: +"One matching filing hit." - changed
Output schema / properties / results / items / properties / file_description / descriptionPrevious value: -"SEC-provided description of the matching document (e.g., \"EX-99.1\"). Absent when SEC published none."New value: +"SEC-provided description of the matching document (e.g., \"EX-99.1\"). Absent when SEC published none, and for pre-2001 archive-sourced rows." - changed
Output schema / properties / results / items / properties / location / descriptionPrevious value: -"Business location (state or country code). Absent when SEC has no location for this filer."New value: +"Business location (state or country code). Absent when SEC has no location for this filer, and for pre-2001 archive-sourced rows." - changed
Output schema / properties / results / items / properties / period_ending / descriptionPrevious value: -"Period the filing reports on (YYYY-MM-DD). Absent for filings without a reporting period (e.g., proxy statements, ownership reports)."New value: +"Period the filing reports on (YYYY-MM-DD). Absent for filings without a reporting period (e.g., proxy statements, ownership reports) and for all pre-2001 archive-sourced rows (source submissions/full-index), which carry no period field." - changed
Output schema / properties / results / items / properties / sic / descriptionPrevious value: -"SIC industry code for the filer. Absent for filers without a classification."New value: +"SIC industry code for the filer. Absent for filers without a classification, and for pre-2001 archive-sourced rows." - added
Output schema / properties / results / items / properties / sourceAdded value: +{ + "description": "Which EDGAR backend served this row: \"efts\" (2001+ full-text index), \"submissions\" (a pre-2001 entity-scoped filing history), or \"full-index\" (a pre-2001 unscoped quarterly index browse). Provenance is carried into the canvas dataframe as a `source` column.", + "enum": [ + "efts", + "submissions", + "full-index" + ], + "type": "string" +} - changed
Output schema / properties / results / items / properties / ticker / descriptionPrevious value: -"Primary ticker symbol parsed from the EFTS display name. Absent for private filers, foreign filers without a US listing, and filings whose display name omits the ticker parenthetical. For multi-class issuers (e.g., BRK-A / BRK-B), this is the first class listed."New value: +"Primary ticker symbol parsed from the EFTS display name. Absent for private filers, foreign filers without a US listing, filings whose display name omits the ticker parenthetical, and all pre-2001 archive-sourced rows. For multi-class issuers (e.g., BRK-A / BRK-B), this is the first class listed." - changed
Output schema / properties / total / descriptionPrevious value: -"Total matching filings (capped at 10,000). Entity targeting (ticker:/cik:) scopes server-side via the EFTS ciks param, so this is the entity's exact match count up to the cap."New value: +"Total matching filings. On the full-text (2001+) path this is capped at 10,000; entity targeting (ticker:/cik:) scopes server-side via the EFTS ciks param, so it is the entity's exact match count up to the cap. On a pre-2001 archive path it is the exact count within the scanned window (see total_is_exact)." - changed
Output schema / properties / total_is_exact / descriptionPrevious value: -"False only when total hits the 10,000 cap."New value: +"False when total is a lower bound — the full-text path hit its 10,000 cap, or a pre-2001 archive scan hit its page/quarter cap before exhausting the range."
2 tool updates
- Changed
secedgar_company_search6 fields changed- added
Input schema / properties / filed_afterAdded value: +{ + "anyOf": [ + { + "const": "", + "type": "string" + }, + { + "description": "YYYY-MM-DD", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + } + ], + "description": "Only include filings filed on or after this date (YYYY-MM-DD). A date filter routes the scan into the older submissions archive pages, so it reaches filings that predate the ~1000-filing recent window (e.g. a company's 2005 10-K)." +} - added
Input schema / properties / filed_beforeAdded value: +{ + "anyOf": [ + { + "const": "", + "type": "string" + }, + { + "description": "YYYY-MM-DD", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + } + ], + "description": "Only include filings filed on or before this date (YYYY-MM-DD). Use alone or with filed_after; together they bound the archive-page scan." +} - changed
Input schema / properties / filing_limit / descriptionPrevious value: -"Maximum number of filings to return."New value: +"Maximum number of filings to return in the inline list." - added
Output schema / properties / datasetAdded value: +{ + "additionalProperties": false, + "description": "Canvas dataframe holding the full filtered filing history (recent + archive pages), registered only when the scan reached beyond the recent window and the history exceeds filing_limit. Query the complete history — filings by form by year — with secedgar_dataframe_query; the inline `filings` list stays capped at filing_limit.", + "properties": { + "expires_at": { + "description": "ISO 8601 expiry timestamp.", + "type": "string" + }, + "name": { + "description": "Dataframe handle (df_XXXXX_XXXXX) — pass to secedgar_dataframe_query.", + "type": "string" + }, + "row_count": { + "description": "Rows materialized in the dataframe.", + "type": "number" + }, + "truncated": { + "description": "True when the archive scan hit its page cap before exhausting the manifest — older matching filings exist beyond the dataframe.", + "type": "boolean" + } + }, + "required": [ + "name", + "row_count", + "expires_at", + "truncated" + ], + "type": "object" +} - added
Output schema / properties / history_scanned_throughAdded value: +{ + "description": "Oldest filing date reached by the scan (YYYY-MM-DD). Filings older than this were not examined: the recent window caps at ~1000 filings, and older filings live in archive pages fetched only when a date filter or an under-filled form filter requires them. Absent when no filings were scanned.", + "type": "string" +} - changed
Output schema / properties / total_filings / descriptionPrevious value: -"Total filings matching the filter (may exceed filing_limit)."New value: +"Total filings matching the filter across everything scanned (recent window + any archive pages), which may exceed filing_limit and the inline list."
- Changed
secedgar_search_filings6 fields changed- added
Input schema / properties / query / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Full-text search query. Supports: exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), entity targeting (ticker:AAPL or cik:320193 in the query). Terms are AND'd by default.", + "minLength": 1, + "type": "string" + } +] - changed
Input schema / properties / query / descriptionPrevious value: -"Full-text search query. Supports: exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), entity targeting (ticker:AAPL or cik:320193 in the query). Terms are AND'd by default."New value: +"Full-text search query. Optional — omit (or pass \"\") to browse by form type and/or entity instead, e.g. every S-1 in a date window, or a company's filings via ticker:/cik:. A date range alone is not a valid search; pair it with forms or entity targeting. When present, supports exact phrases (\"material weakness\"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), and entity targeting (ticker:AAPL or cik:320193 in the query); terms are AND'd by default." - removed
Input schema / properties / query / minLengthRemoved value: -1 - removed
Input schema / properties / query / typeRemoved value: -"string" - changed
Input schema / properties / sort / descriptionPrevious value: -"Result ordering. \"filing_date_desc\" (default) returns most recent first. \"filing_date_asc\" returns oldest first. \"relevance\" returns SEC's native search-score order, which weights term match strength over recency. Date sorts re-order the top 100 hits returned by the search index — for broad queries with more than 100 matches and no entity targeting, date-newest filings may sit outside that window. Entity targeting (ticker:/cik:) or a narrower query keeps matches inside the window when absolute recency matters."New value: +"Result ordering. \"filing_date_desc\" (default) returns most recent first. \"filing_date_asc\" returns oldest first. \"relevance\" returns SEC's native search-score order, which weights term match strength over recency. Date sorts re-order the top 100 hits returned by the search index — for broad queries with more than 100 matches and no entity targeting, date-newest filings may sit outside that window. Entity targeting (ticker:/cik:) or a narrower query keeps matches inside the window when absolute recency matters. On the no-query browse path (forms/entity only), EFTS has no relevance signal — every hit scores null — and returns filings in natural date-descending order, so all sort modes effectively yield newest-first." - removed
Input schema / requiredRemoved value: -[ - "query" -]
1 tool update
- Changed
secedgar_get_institutional_holdings1 field changed- changed
Input schema / properties / ticker_or_cik / descriptionPrevious value: -"The institutional filer whose 13F to fetch — its CIK (e.g., \"0000102909\" for Vanguard) or full legal name (e.g., \"Vanguard Group\"). CIK or the full legal name resolves most reliably; tickers usually belong to operating companies, which do not file 13Fs. This is NOT the portfolio company — passing an issuer ticker like \"AAPL\" finds that entity's own filings, not who holds it."New value: +"The institutional filer whose 13F to fetch — a 10-digit CIK (e.g. \"0000102909\" for VANGUARD GROUP INC, the most reliable form) or an entity name. Names resolve through EDGAR entity search, which covers institutional managers absent from the ticker file; a name matching several filers (some legal names are shared across entities) returns those candidates so you can retry with the exact CIK. This is NOT the portfolio company — passing an issuer ticker like \"AAPL\" finds that operating company's own filings (it files no 13F), not who holds it."
2 tool updates
- Changed
secedgar_get_filing1 field changed- changed
Input schema / properties / section / descriptionPrevious value: -"Jump to a named section by case-insensitive substring match against detected headings (e.g. 'risk factors', 'item 7', 'certain relationships'). Takes precedence over offset when both are provided. On a miss, the error data carries the detected outline so you can pick the correct heading."New value: +"Jump to a named section by case-insensitive substring match against detected headings (e.g. 'risk factors', 'item 7', 'certain relationships'). Takes precedence over offset when both are provided. On a miss, the error message includes the detected outline so you can pick the correct heading."
- Changed
secedgar_get_financials3 fields changed- changed
Output schema / properties / data / items / properties / fiscal_period / descriptionPrevious value: -"Fiscal period of the source filing (FY, Q1, Q2, Q3, Q4). Null when the source filing did not encode a fiscal period."New value: +"Fiscal period of the source filing (FY, Q1, Q2, Q3, Q4), not the data period. Null when the source filing did not encode a fiscal period." - changed
Output schema / properties / data / items / properties / fiscal_year / descriptionPrevious value: -"Fiscal year of the source filing. Null when the source filing did not encode a fiscal year."New value: +"Fiscal year of the source filing, not the data period — every comparative period restated in the same filing carries that filing's fiscal year, so use end (or period) as the time key. Null when the source filing did not encode a fiscal year." - changed
Output schema / properties / dataset / descriptionPrevious value: -"Canvas dataframe handle holding the same time series. Use for cross-company JOINs via secedgar_dataframe_query. Absent when canvas is unavailable."New value: +"Canvas dataframe handle holding the same time series. Use for cross-company JOINs via secedgar_dataframe_query. The source-filing fiscal keys are materialized as source_filing_fy/source_filing_fp — order, group, and window by period_end, not by those columns. Absent when canvas is unavailable."
2 tool updates
- Changed
secedgar_get_filing8 fields changed- added
Input schema / properties / accession_number / patternAdded value: +"^(?:\\d{10}-\\d{2}-\\d{6}|\\d{18})$" - changed
Input schema / properties / cik / descriptionPrevious value: -"Company CIK (resolve via secedgar_company_search if you have a ticker or name). Optional but recommended — speeds up archive lookup. If omitted, likely filing CIKs are inferred from SEC search metadata and archive paths."New value: +"Company CIK, digits only (resolve via secedgar_company_search if you have a ticker or name). Optional but recommended — speeds up archive lookup. If omitted, likely filing CIKs are inferred from SEC search metadata and archive paths." - added
Input schema / properties / cik / patternAdded value: +"^\\d{1,10}$" - changed
Output schema / properties / documents / properties / auxiliary / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename for known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.) and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else." - changed
Output schema / properties / documents / properties / exhibits / descriptionPrevious value: -"Filed exhibits (EX-21 subsidiaries, EX-31/32 certifications, EX-99 press releases, etc.). Excludes XBRL technical exhibits (EX-101.*). Identified by the EX- prefix on the document type. Some exhibits may appear under auxiliary when the submission header is unavailable and the filename has no recognizable pattern."New value: +"Filed exhibits (EX-21 subsidiaries, EX-31/32 certifications, EX-99 press releases, etc.). Excludes XBRL technical exhibits (EX-101.*). Identified by the EX- prefix on the document type, or by common exhibit filename patterns when the submission header is unavailable (type \"exhibit\"). Exhibits with unrecognizable filenames may still appear under auxiliary in the header-less case." - changed
Output schema / properties / documents / properties / exhibits / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename for known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.) and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else." - changed
Output schema / properties / documents / properties / primary / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename for known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.) and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else." - changed
Output schema / properties / documents / properties / xbrl / items / properties / type / descriptionPrevious value: -"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename for known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.) and \"unknown\" for everything else."New value: +"SEC document type from the submission header (e.g., \"10-K\", \"EX-21.1\", \"GRAPHIC\", \"XML\"). When the submission header is unavailable, falls back to a label inferred from the filename: known XBRL artifacts (\"XBRL-LINKBASE\", \"XBRL-INSTANCE\", etc.), \"exhibit\" for common exhibit filename patterns (ex-21.htm, exhibit21, dex991), and \"unknown\" for everything else."
- Changed
secedgar_get_institutional_holdings1 field changed- changed
Input schema / properties / ticker_or_cik / descriptionPrevious value: -"Ticker symbol or CIK of the institutional filer (e.g., \"0000102909\" for Vanguard) or a company name. For institution lookups, CIK or the full legal name resolves most reliably — tickers are typically for operating companies, not fund managers."New value: +"The institutional filer whose 13F to fetch — its CIK (e.g., \"0000102909\" for Vanguard) or full legal name (e.g., \"Vanguard Group\"). CIK or the full legal name resolves most reliably; tickers usually belong to operating companies, which do not file 13Fs. This is NOT the portfolio company — passing an issuer ticker like \"AAPL\" finds that entity's own filings, not who holds it."
3 tool updates
- Changed
secedgar_dataframe_query1 field changed- added
Input schema / properties / register_as / patternAdded value: +"^df_[A-Z0-9]{5}_[A-Z0-9]{5}$"
- Changed
secedgar_get_filing8 fields changed- changed
Input schema / properties / content_limit / descriptionPrevious value: -"Maximum characters of document text to return. 10-K filings can exceed 500,000 characters. Default 50,000 captures ~12,000 words (typically business overview, risk factors, and MD&A). Increase to 200,000 for full financial statements, or decrease for quick summaries."New value: +"Maximum characters of document text to return per page. 10-K filings can exceed 500,000 characters; S-1/A can exceed 1,000,000. Default 50,000 captures ~12,000 words (typically business overview, risk factors, and MD&A). Increase to 200,000 for full financial statements, or decrease for quick summaries. Use offset or section for subsequent pages." - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Character offset into the extracted document text. Pass next_offset from a truncated response to continue reading the next page. Default 0 reads from the beginning.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / sectionAdded value: +{ + "description": "Jump to a named section by case-insensitive substring match against detected headings (e.g. 'risk factors', 'item 7', 'certain relationships'). Takes precedence over offset when both are provided. On a miss, the error data carries the detected outline so you can pick the correct heading.", + "minLength": 1, + "type": "string" +} - changed
Output schema / properties / content / descriptionPrevious value: -"Document text content, truncated to content_limit."New value: +"Document text content for this page window." - changed
Output schema / properties / content_total_length / descriptionPrevious value: -"Full document length before truncation."New value: +"Full document length before any truncation." - changed
Output schema / properties / content_truncated / descriptionPrevious value: -"True if content was truncated."New value: +"True if content was truncated at content_limit." - added
Output schema / properties / next_offsetAdded value: +{ + "description": "Character offset to pass as offset on the next call to continue reading. Only present when the response was truncated. Calling agents should follow this until content_truncated is false.", + "type": "number" +} - added
Output schema / properties / outlineAdded value: +{ + "description": "Document outline — detected headings with their character offsets. Present on the first page of a truncated response (offset=0, no section). Use a heading offset as offset, or pass heading text as section, to jump to that section.", + "items": { + "additionalProperties": false, + "description": "One detected heading with its offset.", + "properties": { + "heading": { + "description": "Detected heading text.", + "type": "string" + }, + "offset": { + "description": "Character offset of this heading in the full document. Pass as offset to jump directly to this section.", + "type": "number" + } + }, + "required": [ + "heading", + "offset" + ], + "type": "object" + }, + "type": "array" +}
- Changed
secedgar_search_filings1 field changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Pagination offset. Increment by limit for the next page. EDGAR caps total accessible results at 10,000 — offsets past this return nothing. Under date sort, pagination is bounded to the first 100 hits."New value: +"Pagination offset. For sort=relevance, EDGAR pages server-side up to its 10,000-result cap. For date sorts (the default) and entity targeting, the tool fetches a single 100-row window and slices it client-side — offsets at or past the window return nothing; switch to sort=relevance for deep pagination, or narrow the search (forms, dates, entity targeting)."
Related MCP Connectors
SEC XBRL MCP — wraps SEC EDGAR XBRL API (data.sec.gov)
EDGAR MCP — SEC EDGAR public APIs (free, no auth)
XBRL filings index MCP — wraps the filings.xbrl.org JSON:API index run by
SEC MCP — SEC EDGAR public APIs (free, no auth)
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceAccess FEC campaign finance data through MCP. Query data about candidates, money trails, and election filings. STDIO & Streamable HTTP.81 npm2Apache 2.0
- FlicenseNot gradedqualityBmaintenanceAn MCP server that provides natural-language access to SEC EDGAR filings, including company lookups, financial figures, insider transactions, and filing comparisons, over streamable HTTP for any MCP client.-
- AlicenseNot gradedqualityAmaintenanceQuery US Treasury national debt, interest rates, exchange rates, and fiscal datasets via MCP with STDIO or Streamable HTTP.74 npm2Apache 2.0
- FlicenseNot gradedqualityBmaintenanceMCP server for SEC EDGAR data, providing company search, financial statements, XBRL concepts/frames, filings, Form 4 insider trades, and 13F filings via User-Agent authentication.-
Glama MCP Gateway
Add one secure layer between your agents and this server.