Access SEC filings efficiently (10-K, 10-Q, etc), save time and tokens, and get cited answers.
Scored across 5 tools
Each tool has a clear, distinct purpose: get_filing_toc provides structure, get_latest_filing gives metadata, list_filings enumerates filings, read_node_content retrieves content, and search_sec_event_filings searches for specific events. No two tools overlap in function; the descriptions clearly differentiate when to use each, eliminating ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case: get_filing_toc, get_latest_filing, list_filings, read_node_content, search_sec_event_filings. The verbs are clear and predictable, and the naming is uniform throughout, making the set easy to navigate.
With 5 tools, the server is well-scoped for SEC filings. This count is within the ideal range (3-15) and each tool serves a necessary function without redundancy or bloat, covering listing, metadata, content retrieval, TOC, and search.
The tool surface is comprehensive for the domain: listing filings, fetching latest metadata, retrieving TOC, reading node content, and searching event filings. This covers the full lifecycle of exploring and extracting data from SEC filings, with no obvious dead ends or missing operations for typical use cases.
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. 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?
With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: the fallback logic when artifact_document_id is omitted (resolves latest filing) and the registry-specific TOC node id formats (HTML vs sec-parser ids). These details go beyond the schema and annotations, disclosing expected output structure.
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 long, front-loaded with the primary purpose, then conditional behavior, then registry-specific notes. No filler or repetition exists; 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?
Despite lacking an output schema, the description communicates what the TOC contains (node ids) and how to interpret them per registry. It covers the essential edge cases (omitted artifact_document_id, FCA specifics) without overwhelming detail. A slight gap is not mentioning the overall return shape, but this is acceptable given the complexity and sibling context.
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 only 40%, leaving ticker, company, and artifact_document_id undocumented. The description compensates by explaining artifact_document_id's role in resolving the latest filing, and it clarifies filing_registry usage for FCA. While ticker/company are self-explanatory, the description effectively fills the gaps for the trickier 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 description opens with a specific verb+resource ('Return the full filing table of contents for one filing'), making the tool's core function immediately clear. It also distinguishes itself from siblings by explicitly referencing list_filings for discovery, and the mention of FCA node id formats highlights its unique role in returning TOC structure rather than content.
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 a direct usage guideline: 'Use list_filings first to discover a specific reporting period.' It also gives conditional guidance for FCA filings with 'pass filing_registry=fca_nsm'. However, it does not explicitly mention when to use get_latest_filing or read_node_content as alternatives, so it lacks full exclusionary guidance.
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. 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?
The description adds significant behavioral context beyond the annotations (readOnlyHint, destructiveHint). It explains the two distinct result structures (one metadata object vs. a filings list), details the document_type and announcement_type fields, and describes how parameter combinations affect behavior. 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 front-loaded with the main purpose and then systematically explains modes and field details. It is slightly verbose but every sentence adds value. The structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (two modes, multiple parameters, no output schema), the description is remarkably complete. It covers all parameter combinations, result structures, field meanings, and enum values. The agent has sufficient information to decide when and how to use the 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?
With 60% schema description coverage, the description compensates by explaining the effect of omitting ticker/company, the role of filing_registry, and the meaning of document_type values including FCA press subtypes. This adds value beyond the schema, though ticker and company parameters lack explicit descriptions.
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 returns the latest filing metadata for a company or ticker and explains both modes (with company/ticker and without). It is specific about the verb and resource, but does not explicitly differentiate from sibling tools like get_filing_toc or list_filings, so a 4 is appropriate.
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 explicit guidance on when to use each mode: with ticker/company for a specific company, or omit them for newly ingested filings. It also advises omitting filing_registry in the latter mode to include both SEC and FCA. This is clear contextual guidance, though it does not list alternative tools or when to avoid.
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. Each row includes Filing metadata object. Includes document_type (Canonical document type. SEC: 10-K, 10-Q, 20-F, 6-K, 8-K. 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 declare readOnlyHint=true and destructiveHint=false, so the description only needs to add behavioral details. It adds ordering ('newest first'), output fields (artifact_document_id, dates, Filing metadata object), and explains document_type and announcement_type semantics. 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 front-loaded with the main action, followed by usage guidance, then output details. It is somewhat lengthy due to enumerating announcement_type values, but all information is relevant. 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?
No output schema exists, so the description carries the burden of explaining return values. It does so by describing row contents (artifact_document_id, dates, Filing metadata, document_type, announcement_type). It also provides context for registry selection. However, it omits details on limit behavior and how ticker vs company interact, leaving small gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (document_type and filing_registry have descriptions; limit, ticker, company lack schema descriptions). The description clarifies filing_registry usage and expands on document_type and announcement_type values, but does not explain limit, ticker, or company parameter semantics, leaving partial compensation for the low coverage.
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 begins with 'List available filings for a ticker (newest first) with artifact_document_id and dates', clearly specifying the verb (List), resource (filings), and scope (ticker, ordering). It distinguishes from sibling tools like get_latest_filing and get_filing_toc by focusing on listing all filings, not a specific one.
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 usage guidance: 'Use filing_registry=fca_nsm for UK FCA NSM reports' and 'Use this first when you need a specific reporting period.' This indicates when to use it, though it does not explicitly state when not to use it or name alternatives.
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 8-K and 6-K current-report nodes for company events and disclosures. Use this to discover issuers across a date range. Do not use this for 10-K or 10-Q filings. How to search:
Always pass concept_groups. Every group is required (AND). Within each group's any_of list, one alternative must match (OR). All groups match inside one filing node. Use separate groups for the main context, action or direction, business object or metric, and a causal or limiting relation when that relation is essential.
Optionally pass query with likely verbatim disclosure phrases. Each item is an exact adjacent-token phrase. Put alternate full phrasings in the same list. Query plus concept_groups is hybrid search: exact phrase matches receive a score boost, and concept groups recover different wording. Do not put broad topic words such as "China", "AI", "customer", or "restructuring" alone in query.
Add real synonyms and alternate filing language to any_of. The concept path uses English stemming, so one base form usually covers inflections (decline/declined/declining and volume/volumes). Stemming does not add synonyms (sales does not mean revenue; reduce does not mean weaken).
Do not search with query only. Omit query for concept-only search. If query is omitted, the search is concept-only.
Use date filters for time and tickers to search only selected issuers. Pass ne_tickers (or prefix a symbol with !) to omit issuers.
Results are candidates, not final conclusions. Call read_node_content with each promising document_id and node_id(s). Verify negation, causal claims, comparisons across periods, and numeric thresholds such as a percentage or dollar amount in the source text. Cite CITATION_MARKDOWN. When you finish an issuer, search again with the same inputs and add its ticker to ne_tickers so later hits come from other issuers. Examples of useful group dimensions include geography + weakening signal + demand metric; CapEx + reduction + guidance; AI/automation + enablement + workforce + reduction; customer + loss/concentration; data centers + exposure + monetization; or restructuring + program/charge. Do not add a group for a detail that the filing may leave implicit, because every group is mandatory. Each result is one filing node: document_id, node_id, parent_node_id, ticker, type, filing_date, match_mode, query, score, and a short snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum unique matches to return across all query phrases. At most 3 matches come from one filing. | |
| 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"]. | |
| 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"]). 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. | |
| start_date | Yes | Inclusive start date on filing_date (YYYY-MM-DD) | |
| concept_groups | Yes | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, and the description adds valuable behavioral detail: concept groups are AND-ed across groups and OR-ed within any_of, query uses exact adjacent-token phrases with score boosting, stemming does not add synonyms, and results are candidates that must be verified in source text. 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 long but logically structured with numbered search rules, examples, and a result-field list. Every section earns its place for a complex search tool, and the main purpose and scope are front-loaded in the first sentences.
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 explicitly lists every result field and explains how to consume results via read_node_content. It also covers hybrid search behavior, required parameters, and workflow limitations, leaving no critical gap for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds substantial strategy beyond the schema: it explains how to build concept_groups, what not to put in query, how stemming behaves, and how tickers/ne_tickers should be used across repeated searches. The description compensates and enriches every parameter's meaning.
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: 'Search US SEC 8-K and 6-K current-report nodes for company events and disclosures.' It also names the intended use ('discover issuers across a date range') and an explicit scope exclusion ('Do not use this for 10-K or 10-Q filings'), which clearly separates it from sibling filing-lookup 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?
Provides explicit when-to-use context and a when-not ('Do not use for 10-K or 10-Q filings'). It gives a full search workflow, including forming concept groups, using query phrases, excluding tickers via ne_tickers, and following up with read_node_content. This is strong, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
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_contentAgent-native SEC filing data: statements assembled, filings read and synthesized. No API key.
SEC-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.
SEC filing intelligence for AI agents. Financials, screening, peer comparison for 5,000+ companies.
Add one secure layer between your agents and this server.
