Access SEC filings efficiently (10-K, 10-Q, etc), save time and tokens, and get cited answers.
Scored across 5 tools
The five tools mostly target distinct operations (list, latest, TOC, read content, search), but get_latest_filing and list_filings overlap in returning filing metadata for a ticker and could be confused at selection time. Descriptions do clarify the boundary (latest-only vs full list), so ambiguity is limited to this one pair.
All tools follow a clean verb_noun snake_case pattern: get_filing_toc, get_latest_filing, list_filings, read_node_content, search_sec_event_filings. The convention is predictable and readable throughout with no mixed styles.
Five tools map neatly onto a filings retrieval pipeline (discover -> metadata -> TOC -> read -> search), with each earning its place. The set is slightly thin for a research-oriented server but well-scoped rather than padded.
Core lifecycle is covered: list filings, latest metadata, TOC navigation, node content reading, and node-level search with pagination and filtering. Minor gaps remain, such as search excluding DEF 14A and FCA filings and the absence of any export/raw-document or cross-filing comparison operation.
Return the full filing table of contents for one filing. If artifact_document_id is omitted, resolves the single latest filing for ticker/company (and optional document_type) only. Use list_filings first to discover a specific reporting period. Pass document_type=DEF 14A for US proxy statements. For DEF 14A, TOC rows are native proxy section labels when the filing has a linked HTML TOC; otherwise they use sec-parser headings. For FCA filings, pass filing_registry=fca_nsm; TOC node ids are HTML page element ids (e.g. pf2a, page12, pageView1) for annual ESEF reports or sec-parser ids (e.g. sp-0000001) for half-year RNS HTML reports.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| company | No | ||
| document_type | No | Optional document type filter (canonical values only). See Field reference for allowed values per registry. | |
| filing_registry | No | Filing source registry. sec_edgar — US SEC EDGAR filings. fca_nsm — UK FCA National Storage Mechanism. Omit to search both registries. | sec_edgar |
| artifact_document_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the implicit latest-filing resolution when artifact_document_id is omitted, and the differing TOC row/id formats by document type and registry. Auth, rate limits, and pagination are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose before the conditional details. The registry-specific id examples (pf2a, page12, sp-0000001) are dense but useful; the description is long for a single paragraph, though nearly every clause carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries return-value burden and partially does so by describing what TOC rows contain (native proxy section labels vs. sec-parser headings, HTML element ids vs. sec-parser ids). It stops short of describing the overall response shape, such as node id/title structure or whether content is included.
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 only 40%, so the description must compensate and largely does: it explains omission behavior for artifact_document_id, the special DEF 14A value for document_type, and the fca_nsm value for filing_registry. ticker vs. company precedence is implied ('ticker/company') but never spelled out.
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: 'Return the full filing table of contents for one filing.' The scoping sentence about omitted artifact_document_id ('resolves the single latest filing for ticker/company') makes the tool's behavior distinguishable from siblings like list_filings and get_latest_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?
Explicitly routes the agent: 'Use list_filings first to discover a specific reporting period,' and gives conditional guidance for proxies ('Pass document_type=DEF 14A') and UK filings ('pass filing_registry=fca_nsm'). An agent knows both the prerequisite and the branch conditions without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return latest filing metadata for a company or ticker. If ticker and company are omitted, return newly ingested filings newest-first. Omit filing_registry in that mode to include both SEC and FCA. Company results include one metadata object; newly ingested results include a filings list. Each row includes Filing metadata object. Includes document_type (Canonical document type. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K, DEF 14A. FCA: annual, half-year, press.) and, for FCA press rows, announcement_type (FCA press subtype when document_type is press; null for annual and half-year. Values: 1st Quarter Results, 2nd Quarter Results, 3rd Quarter Results, 4th Quarter Results, Final Results, Preliminary Results, Share Buyback, Trading Update.).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max newly ingested filings when ticker and company are omitted | |
| ticker | No | ||
| company | No | ||
| document_type | No | Optional document type filter (canonical values only). See Field reference for allowed values per registry. | |
| filing_registry | No | Filing source registry. sec_edgar — US SEC EDGAR. fca_nsm — UK FCA NSM. Omit with no ticker/company to list newly ingested filings from both registries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the two result shapes ('one metadata object' vs 'a filings list'), the newest-first ordering, and the cross-registry inclusion rule. It stops short of a 5 because it omits pagination and any failure/empty-result 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 mode logic is front-loaded and easy to follow, but the long parenthetical enumerating every document_type and announcement_type value duplicates enum values already present in the schema, adding bulk without new information. The trailing 'Each row includes Filing metadata object' is also a loose fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so reasonably well, distinguishing the single-object and list shapes and the metadata fields returned. It is incomplete on pagination, ordering guarantees for the company mode, and error behavior, but covers the essentials for a 5-param, all-optional read 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?
Schema coverage is 60%; limit and filing_registry carry schema descriptions and document_type has a full enum, so the schema does most of the work. The description restates the canonical document_type values (already in the schema enum) and explains the omit-filing_registry behavior, but adds no meaning for the undescribed ticker and company parameters. 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 and resource ('Return latest filing metadata for a company or ticker') and clearly delineates two operating modes (company/ticker lookup vs. newly-ingested listing). It does not name any sibling (list_filings, search_sec_event_filings) to explain how it differs from them, which keeps it just short of a 5.
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 conditional behavior — omit ticker/company to get newly-ingested filings, omit filing_registry to include both SEC and FCA — which is useful mode-selection guidance. However, it never says when to prefer this over list_filings or search_sec_event_filings, so alternative selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available filings for a ticker (newest first) with artifact_document_id and dates. Use filing_registry=fca_nsm for UK FCA NSM reports. Use this first when you need a specific reporting period, including DEF 14A proxy statements (pass document_type=DEF 14A). Each row includes Filing metadata object. Includes document_type (Canonical document type. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K, DEF 14A. FCA: annual, half-year, press.) and, for FCA press rows, announcement_type (FCA press subtype when document_type is press; null for annual and half-year. Values: 1st Quarter Results, 2nd Quarter Results, 3rd Quarter Results, 4th Quarter Results, Final Results, Preliminary Results, Share Buyback, Trading Update.).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | No | ||
| company | No | ||
| document_type | No | Optional document type filter (canonical values only). See Field reference for allowed values per registry. | |
| filing_registry | No | Filing source registry. sec_edgar — US SEC EDGAR filings. fca_nsm — UK FCA National Storage Mechanism. Omit to search both registries. | sec_edgar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds ordering (newest first) and the shape of each row (Filing metadata object with document_type/announcement_type), but says nothing about pagination behavior, auth, or the ticker-vs-company selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action and routing rule are front-loaded, which is good. But the trailing parentheticals enumerate document_type and announcement_type values that the input schema's enum already lists, adding length without new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully describes returned fields, and it covers registry and document_type filtering. It still omits the ticker/company relationship and limit behavior for a 5-parameter, zero-required tool, leaving the definition adequate but incomplete.
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 only 40%, so the description must compensate; it does explain document_type usage (DEF 14A example, canonical values) and the filing_registry= fca_nsm switch well. However, ticker, company, and limit are left unexplained in both schema and description, so the gap is only partially closed.
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 resource (filings) with scope (for a ticker, newest first) plus returned identifiers (artifact_document_id and dates). It implicitly distinguishes itself from get_latest_filing by framing this as the full listing and by 'Use this first when you need a specific reporting period', though it does not name the siblings outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance ('Use this first when you need a specific reporting period') and a registry-selection rule ('Use filing_registry=fca_nsm for UK FCA NSM reports'). It stops short of naming alternatives like get_latest_filing or search_sec_event_filings and when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return content for one or more navigation nodes in a filing. Pass one node via node_id or several via node_ids, using the node ids from TOC lines (the same values shown as NODE_ID lines in this tool's output). Returns plain MCP text: an ARTIFACT_DOCUMENT_ID header, then per-node blocks with NODE_ID, TITLE, CITATION_URL, CITATION_MARKDOWN, CONTENT_START … CONTENT_END. Each block's CITATION_URL links to the reader location for that node; CITATION_MARKDOWN is the same link as ready-to-paste markdown TITLE. A requested TOC node may expand into more granular child NODE_ID blocks, each with its own TITLE, CITATION_URL, and CITATION_MARKDOWN. Responses that include citations end with a CITATIONS_IN_THIS_RESPONSE list.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | No | Single node id from TOC / NODE_ID lines. For FCA filings this is the HTML page id (e.g. pf2a, page12, pageView1). | |
| node_ids | No | Batch read: multiple node ids for one filing (same identifiers as NODE_ID / TOC). | |
| artifact_document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by detailing the output format (ARTIFACT_DOCUMENT_ID, NODE_ID, TITLE, CITATION_URL, etc.), the behavior of expanding TOC nodes into child blocks, and the inclusion of a CITATIONS_IN_THIS_RESPONSE list. This enriches the agent's understanding of what to expect from the invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but well-structured with clear sequences: input method, output format, expansion behavior, and citations. Every sentence adds value, though it is longer than strictly necessary. Still, it avoids redundancy and effectively front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly explains the return format, including field names and meanings, citation link behavior, and node expansion. This gives the agent everything needed to invoke the tool and interpret results without ambiguity.
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 67% (node_id and node_ids have descriptions, artifact_document_id does not). The description compensates by explaining how node_id and node_ids relate to TOC/NODE_ID lines, and it clarifies their usage with examples like 'pf2a, page12'. artifact_document_id is implied through the context 'in a filing,' though not explicitly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return content for one or more navigation nodes in a filing.' It specifies the resource (navigation nodes within a filing) and the action (return content), distinguishing it from sibling tools like get_filing_toc and list_filings, which handle different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining how to pass node ids from TOC lines and the distinction between single and batch reads. It doesn't explicitly exclude alternatives, but the purpose (reading content) implies when it should be used versus TOC retrieval. This meets the 'clear context, no exclusions' benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search US SEC filing nodes for a disclosure claim. The search covers 8-K, 6-K, 10-K, 10-Q, and 20-F. Omit document_type to search all of those forms. Pass document_type to search only the forms you name. Do not use this for DEF 14A. How to search:
Always pass concept_groups. Every group is required (AND). Within each group's any_of list, one alternative must match (OR). Use 2-5 groups for separate parts of the claim: topic, action, metric, and a causal link when that link is essential. Example: geography + weaker demand + decline, or AI + productivity + margin. Add synonyms. English stemming covers inflections (decline/declined), not synonyms (sales is not revenue). Do not add a group for a detail the filing may leave implicit.
query is optional. Each item is an exact adjacent-token phrase. Put alternate full phrasings in the same list. Query plus concept_groups is hybrid search: an exact phrase ranks first, so a generic phrase such as "margin expansion" can outrank the causal sentence you want. Prefer phrases that state the relationship. Do not pass a broad topic word alone. Do not search with query only. Omit query for concept-only search.
start_date and end_date are required. tickers limits issuers. Optional document_type limits the search to one or more of 8-K, 6-K, 10-K, 10-Q, and 20-F. Omit it to search all of those forms. How to continue:
Each call returns one page. There is no total count. If HAS_MORE is true, call again with cursor set to NEXT_CURSOR and the same concept_groups, dates, query, tickers, ne_tickers, document_type, and match_scope. A cursor from different inputs is rejected. An empty page with HAS_MORE true is not the end: call again with that cursor. Stop when HAS_MORE is false or when later pages are not relevant.
If a page is mostly co-occurrence (the terms appear, but not the claim), start a new search with no cursor. Add a concept group or exact causal phrases. If a page is too sparse, start a new search with no cursor and drop the least essential group. Do not change filters while passing a cursor.
ne_tickers excludes issuers you have already reviewed. It does not load the next page. Results are candidates. Call read_node_content with document_id and node_id. node_id may start with sp-. Verify negation, causality, comparisons across periods, and numeric thresholds in the source text. Cite CITATION_MARKDOWN.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches on this page. Not a total count. At most 3 matches come from one filing. When HAS_MORE is true, pass cursor to read the next page. | |
| query | No | Optional exact disclosure phrases for hybrid search (max 8). Each phrase requires adjacent tokens in order and does not use stemming. Send complete event phrasings, not standalone topics. Omit this field for concept-only search. Examples: ["reduced capital expenditures", "lower capital spending"]; ["lost a major customer", "termination by our largest customer"]; ["workforce reduction", "reduce headcount"]. | |
| cursor | No | Page id from the previous NEXT_CURSOR line. Copy it unchanged. Pass it only with the same concept_groups, dates, query, tickers, ne_tickers, document_type, and match_scope. A mismatch is rejected. Omit it to start a new search. | |
| tickers | No | Optional. Search only these issuers (example: ["NVDA", "MSFT"]). Prefix a symbol with ! to omit it (same as ne_tickers). Max 50. Omit to search all issuers. | |
| end_date | Yes | Inclusive end date on filing_date (YYYY-MM-DD) | |
| ne_tickers | No | Optional. Omit these issuers (example: ["HOOD"] or ["!HOOD"]). This does not load the next page. Use cursor for that. Exclude wins if a ticker is in both lists. Max 50. | |
| start_date | Yes | Inclusive start date on filing_date (YYYY-MM-DD) | |
| match_scope | No | node (default): Atlas ranks every matching filing node. window is accepted for compatibility and behaves like node. | node |
| document_type | No | Optional. Limit the search to one or more of "8-K", "6-K", "10-K", "10-Q", and "20-F". Omit to search all of those forms. | |
| concept_groups | Yes | Required stemmed concept groups. Every group must match (AND). Any one alternative inside any_of can satisfy its group (OR). Atlas ranks the matching filing nodes. Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/destructiveHint; the description goes well beyond by disclosing pagination semantics (one page per call, no total count, HAS_MORE/NEXT_CURSOR, cursor rejected on mismatched inputs, empty page with HAS_MORE still requiring another call), a max-3-matches-per-filing cap, and the hybrid-ranking behavior where a generic exact phrase can outrank the intended sentence.
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?
Long but deliberately structured with numbered sections, front-loaded purpose, and no filler sentences; each rule carries operational weight. Slightly verbose repetition of the document_type/all-forms rule (stated twice) is the only 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?
With no output schema and 10 parameters, the description still covers return shape (paged candidates, HAS_MORE/NEXT_CURSOR, CITATION_MARKDOWN), the verification requirement for negation/causality/numeric claims, and the follow-up call signature. Nothing an agent needs to invoke or continue correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description meaningfully extends it: it explains why query plus concept_groups is hybrid search, warns that generic phrases can dominate, states that query must state a relationship and never be used alone, and clarifies ne_tickers does not page. These are semantics an agent cannot infer from the schema alone.
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?
Specific verb+resource (search US SEC filing nodes for a disclosure claim) with explicit coverage of the five form types and an explicit exclusion (DEF 14A). It also names the downstream sibling read_node_content, so an agent can place it in a workflow without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use, when-not (DEF 14A), how to build concept_groups vs query, and full continuation rules including cursor reuse constraints and the no-cursor restart strategy for poor pages. Alternative tool (read_node_content) is named along with the verification it performs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_filing_toc1 field changedInput schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "annual",
- "half-year",
- "press"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "annual",
- "half-year",
- "press"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "DEF 14A",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "DEF 14A",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]get_latest_filing1 field changedInput schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "annual",
- "half-year",
- "press"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "annual",
- "half-year",
- "press"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "DEF 14A",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "DEF 14A",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]list_filings1 field changedInput schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "annual",
- "half-year",
- "press"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "annual",
- "half-year",
- "press"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "DEF 14A",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "DEF 14A",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]search_sec_event_filings5 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque NEXT_CURSOR from the previous response. Pass it with the same concept_groups, dates, query, tickers, ne_tickers, document_type, and match_scope to read the next page. Omit it to start from the first page."New value: +"Page id from the previous NEXT_CURSOR line. Copy it unchanged. Pass it only with the same concept_groups, dates, query, tickers, ne_tickers, document_type, and match_scope. A mismatch is rejected. Omit it to start a new search."Input schema / properties / document_type / descriptionPrevious value: -"Optional. Search only these current-report forms: \"8-K\", \"6-K\", or both. Omit to search 8-K and 6-K."New value: +"Optional. Limit the search to one or more of \"8-K\", \"6-K\", \"10-K\", \"10-Q\", and \"20-F\". Omit to search all of those forms."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "minLength": 1,
- "type": "string"
- },
- {
- "items": {
- "minLength": 1,
- "type": "string"
- },
- "maxItems": 2,
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / limit / descriptionPrevious value: -"Maximum matches to return on this page. At most 3 matches come from one filing. When has_more is true, pass cursor to read the next page."New value: +"Maximum matches on this page. Not a total count. At most 3 matches come from one filing. When HAS_MORE is true, pass cursor to read the next page."Input schema / properties / ne_tickers / descriptionPrevious value: -"Optional. Omit these issuers (example: [\"HOOD\"] or [\"!HOOD\"]). This filter does not load the next page. Use cursor for that. Exclude wins if a ticker is in both lists. Max 50."New value: +"Optional. Omit these issuers (example: [\"HOOD\"] or [\"!HOOD\"]). This does not load the next page. Use cursor for that. Exclude wins if a ticker is in both lists. Max 50."search_sec_event_filings6 fields changedInput schema / properties / concept_groups / descriptionPrevious value: -"Required stemmed concept groups. Every group must match in the same node (AND). Any one alternative inside any_of can satisfy its group (OR). Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content."New value: +"Required stemmed concept groups. Every group must match (AND). Any one alternative inside any_of can satisfy its group (OR). Atlas ranks the matching filing nodes. Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content."Input schema / properties / cursorAdded value: +{
+ "description": "Opaque NEXT_CURSOR from the previous response. Pass it with the same concept_groups, dates, query, tickers, ne_tickers, document_type, and match_scope to read the next page. Omit it to start from the first page.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / document_typeAdded value: +{
+ "description": "Optional. Search only these current-report forms: \"8-K\", \"6-K\", or both. Omit to search 8-K and 6-K.",
+ "oneOf": [
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 2,
+ "minItems": 1,
+ "type": "array"
+ }
+ ]
+}Input schema / properties / limit / descriptionPrevious value: -"Maximum unique matches to return across all query phrases. At most 3 matches come from one filing."New value: +"Maximum matches to return on this page. At most 3 matches come from one filing. When has_more is true, pass cursor to read the next page."Input schema / properties / match_scopeAdded value: +{
+ "default": "node",
+ "description": "node (default): Atlas ranks every matching filing node. window is accepted for compatibility and behaves like node.",
+ "enum": [
+ "window",
+ "node"
+ ],
+ "type": "string"
+}Input schema / properties / ne_tickers / descriptionPrevious value: -"Optional. Omit these issuers (example: [\"HOOD\"] or [\"!HOOD\"]). After you finish read_node_content for a ticker, search again with that ticker here. Exclude wins if a ticker is in both lists. Max 50."New value: +"Optional. Omit these issuers (example: [\"HOOD\"] or [\"!HOOD\"]). This filter does not load the next page. Use cursor for that. Exclude wins if a ticker is in both lists. Max 50."search_sec_event_filings3 fields changedInput schema / properties / concept_groups / descriptionPrevious value: -"Optional stemmed concept fallback for broad discovery. Every group must match in the same node (AND). Any one alternative inside any_of can satisfy its group (OR). Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content."New value: +"Required stemmed concept groups. Every group must match in the same node (AND). Any one alternative inside any_of can satisfy its group (OR). Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content."Input schema / properties / query / descriptionPrevious value: -"Required exact disclosure phrases (max 8). Each phrase requires adjacent tokens in order and does not use stemming. Send complete event phrasings, not standalone topics. Examples: [\"reduced capital expenditures\", \"lower capital spending\"]; [\"lost a major customer\", \"termination by our largest customer\"]; [\"workforce reduction\", \"reduce headcount\"]."New value: +"Optional exact disclosure phrases for hybrid search (max 8). Each phrase requires adjacent tokens in order and does not use stemming. Send complete event phrasings, not standalone topics. Omit this field for concept-only search. Examples: [\"reduced capital expenditures\", \"lower capital spending\"]; [\"lost a major customer\", \"termination by our largest customer\"]; [\"workforce reduction\", \"reduce headcount\"]."Input schema / requiredPrevious value: -[
- "query",
- "start_date",
- "end_date"
-]New value: +[
+ "concept_groups",
+ "start_date",
+ "end_date"
+]search_sec_event_filings8 fields changedInput schema / properties / concept_groupsAdded value: +{
+ "description": "Optional stemmed concept fallback for broad discovery. Every group must match in the same node (AND). Any one alternative inside any_of can satisfy its group (OR). Use 2-5 focused groups in most searches. Supply synonyms and alternate filing terms, but omit simple inflections because English stemming handles them. Do not use this field to prove numeric thresholds, negation, causality, or changes across several filings; retrieve candidates and verify those claims with read_node_content.",
+ "examples": [
+ [
+ {
+ "any_of": [
+ "capital expenditure",
+ "CapEx",
+ "capital spending"
+ ],
+ "name": "capital_spending"
+ },
+ {
+ "any_of": [
+ "reduce",
+ "lower",
+ "cut"
+ ],
+ "name": "direction"
+ },
+ {
+ "any_of": [
+ "guidance",
+ "outlook",
+ "expect"
+ ],
+ "name": "forward_looking"
+ }
+ ]
+ ],
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "any_of": {
+ "description": "Synonyms or short phrases for one required concept. Any one can match. Multiword values are adjacent-token phrases. English stemming applies.",
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 16,
+ "minItems": 1,
+ "type": "array"
+ },
+ "name": {
+ "description": "Short role label, such as geography, direction, business_metric, technology, or customer_event.",
+ "maxLength": 64,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "any_of"
+ ],
+ "type": "object"
+ },
+ "maxItems": 6,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / limit / defaultPrevious value: -20New value: +30Input schema / properties / limit / descriptionPrevious value: -"Maximum exact-match results to return"New value: +"Maximum unique matches to return across all query phrases. At most 3 matches come from one filing."Input schema / properties / ne_tickersAdded value: +{
+ "description": "Optional. Omit these issuers (example: [\"HOOD\"] or [\"!HOOD\"]). After you finish read_node_content for a ticker, search again with that ticker here. Exclude wins if a ticker is in both lists. Max 50.",
+ "oneOf": [
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ }
+ ]
+}Input schema / properties / query / descriptionPrevious value: -"Exact phrase to search for, e.g. private credit"New value: +"Required exact disclosure phrases (max 8). Each phrase requires adjacent tokens in order and does not use stemming. Send complete event phrasings, not standalone topics. Examples: [\"reduced capital expenditures\", \"lower capital spending\"]; [\"lost a major customer\", \"termination by our largest customer\"]; [\"workforce reduction\", \"reduce headcount\"]."Input schema / properties / query / oneOfAdded value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / query / typeRemoved value: -"string"Input schema / properties / tickersAdded value: +{
+ "description": "Optional. Search only these issuers (example: [\"NVDA\", \"MSFT\"]). Prefix a symbol with ! to omit it (same as ne_tickers). Max 50. Omit to search all issuers.",
+ "oneOf": [
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ }
+ ]
+}get_latest_filing3 fields changedInput schema / properties / filing_registry / defaultRemoved value: -"sec_edgar"Input schema / properties / filing_registry / descriptionPrevious value: -"Filing source registry. sec_edgar — US SEC EDGAR filings. fca_nsm — UK FCA National Storage Mechanism. Omit to search both registries."New value: +"Filing source registry. sec_edgar — US SEC EDGAR. fca_nsm — UK FCA NSM. Omit with no ticker/company to list newly ingested filings from both registries."Input schema / properties / limitAdded value: +{
+ "default": 25,
+ "description": "Max newly ingested filings when ticker and company are omitted",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}search_sec_event_filingsget_filing_toc3 fields changedInput schema / properties / document_type / descriptionPrevious value: -"Optional filing type filter. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. FCA: Annual Report."New value: +"Optional document type filter (canonical values only). See Field reference for allowed values per registry."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "Annual Report"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "Annual Report"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / filing_registry / descriptionPrevious value: -"Filing source registry. Use sec_edgar (default) for US SEC filings or fca_nsm for UK FCA NSM annual reports."New value: +"Filing source registry. sec_edgar — US SEC EDGAR filings. fca_nsm — UK FCA National Storage Mechanism. Omit to search both registries."get_latest_filing3 fields changedInput schema / properties / document_type / descriptionPrevious value: -"Optional filing type filter. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. FCA: Annual Report."New value: +"Optional document type filter (canonical values only). See Field reference for allowed values per registry."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "Annual Report"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "Annual Report"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / filing_registry / descriptionPrevious value: -"Filing source registry. Use sec_edgar (default) for US SEC filings or fca_nsm for UK FCA NSM annual reports."New value: +"Filing source registry. sec_edgar — US SEC EDGAR filings. fca_nsm — UK FCA National Storage Mechanism. Omit to search both registries."list_filings3 fields changedInput schema / properties / document_type / descriptionPrevious value: -"Optional filing type filter. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. FCA: Annual Report."New value: +"Optional document type filter (canonical values only). See Field reference for allowed values per registry."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "Annual Report"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K",
- "Annual Report"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "annual",
+ "half-year",
+ "press"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / filing_registry / descriptionPrevious value: -"Filing source registry. Use sec_edgar (default) for US SEC filings or fca_nsm for UK FCA NSM annual reports."New value: +"Filing source registry. sec_edgar — US SEC EDGAR filings. fca_nsm — UK FCA National Storage Mechanism. Omit to search both registries."read_node_content2 fields changedInput schema / properties / node_id / descriptionPrevious value: -"Single node id (same values as NODE_ID in tool output and TOC lines); alternative to node_ids."New value: +"Single node id from TOC / NODE_ID lines. For FCA filings this is the HTML page id (e.g. pf2a, page12, pageView1)."Input schema / properties / node_ids / descriptionPrevious value: -"Batch read: multiple node ids for one filing (same identifiers as NODE_ID)."New value: +"Batch read: multiple node ids for one filing (same identifiers as NODE_ID / TOC)."get_filing_toc3 fields changedInput schema / properties / document_type / descriptionPrevious value: -"Optional SEC filing type filter. One of 10-K, 10-Q, 20-F, 6-K, 8-K; comma-separated (e.g. 10-K,10-Q); or a JSON array string."New value: +"Optional filing type filter. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. FCA: Annual Report."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "Annual Report"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "Annual Report"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / filing_registryAdded value: +{
+ "default": "sec_edgar",
+ "description": "Filing source registry. Use sec_edgar (default) for US SEC filings or fca_nsm for UK FCA NSM annual reports.",
+ "enum": [
+ "sec_edgar",
+ "fca_nsm"
+ ],
+ "type": "string"
+}get_latest_filing3 fields changedInput schema / properties / document_type / descriptionPrevious value: -"Optional SEC filing type filter. One of 10-K, 10-Q, 20-F, 6-K, 8-K; comma-separated (e.g. 10-K,10-Q); or a JSON array string."New value: +"Optional filing type filter. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. FCA: Annual Report."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "Annual Report"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "Annual Report"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / filing_registryAdded value: +{
+ "default": "sec_edgar",
+ "description": "Filing source registry. Use sec_edgar (default) for US SEC filings or fca_nsm for UK FCA NSM annual reports.",
+ "enum": [
+ "sec_edgar",
+ "fca_nsm"
+ ],
+ "type": "string"
+}list_filings3 fields changedInput schema / properties / document_type / descriptionPrevious value: -"Optional SEC filing type filter. One of 10-K, 10-Q, 20-F, 6-K, 8-K; comma-separated (e.g. 10-K,10-Q); or a JSON array string."New value: +"Optional filing type filter. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. FCA: Annual Report."Input schema / properties / document_type / oneOfPrevious value: -[
- {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
- ],
- "type": "string"
- },
- {
- "items": {
- "enum": [
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "Annual Report"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K",
+ "Annual Report"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / filing_registryAdded value: +{
+ "default": "sec_edgar",
+ "description": "Filing source registry. Use sec_edgar (default) for US SEC filings or fca_nsm for UK FCA NSM annual reports.",
+ "enum": [
+ "sec_edgar",
+ "fca_nsm"
+ ],
+ "type": "string"
+}get_filing_toc4 fields changedInput schema / properties / document_type / descriptionAdded value: +"Optional SEC filing type filter. One of 10-K, 10-Q, 20-F, 6-K, 8-K; comma-separated (e.g. 10-K,10-Q); or a JSON array string."Input schema / properties / document_type / enumRemoved value: -[
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
-]Input schema / properties / document_type / oneOfAdded value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / document_type / typeRemoved value: -"string"get_latest_filing4 fields changedInput schema / properties / document_type / descriptionAdded value: +"Optional SEC filing type filter. One of 10-K, 10-Q, 20-F, 6-K, 8-K; comma-separated (e.g. 10-K,10-Q); or a JSON array string."Input schema / properties / document_type / enumRemoved value: -[
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
-]Input schema / properties / document_type / oneOfAdded value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / document_type / typeRemoved value: -"string"list_filings4 fields changedInput schema / properties / document_type / descriptionAdded value: +"Optional SEC filing type filter. One of 10-K, 10-Q, 20-F, 6-K, 8-K; comma-separated (e.g. 10-K,10-Q); or a JSON array string."Input schema / properties / document_type / enumRemoved value: -[
- "10-K",
- "10-Q",
- "20-F",
- "6-K",
- "8-K"
-]Input schema / properties / document_type / oneOfAdded value: +[
+ {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "10-K",
+ "10-Q",
+ "20-F",
+ "6-K",
+ "8-K"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / document_type / typeRemoved value: -"string"get_filing_tocget_latest_filinglist_filingsread_node_contentSEC-signed profiles for 8,000+ US public companies from EDGAR filings. Token-efficient.
Primary-source SEC filing intelligence for AI agents, with exact evidence and provenance.
Agent-native SEC data, 20 tools: statements assembled, any line item, filings synthesized. No key.
SEC-filed company financials with filing citations, plus market data, for AI agents
Add one secure layer between your agents and this server.
