capabilities

List SEC EDGAR filings for a US company by ticker or CIK

company_us_filings

Read-onlyIdempotent

Return the recent EDGAR filing history of a US company identified by stock ticker (AAPL) or CIK, optionally filtered by form type and filing date and paged. Use when: List every 8-K on this ticker's EDGAR index this year, with links to the documents. Not for: You need to know who submitted a filing — EDGAR's submissions index carries no filer identity, so a Form 4 or SCHEDULE 13G here tells you the filing exists, not who made it. Related: company_us_filings_latest; company_us_profile; company_us_resolve; company_uk_filings. Price: USD 0.005/call (x402), 0.004 (account key).

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	SEC CIK or exchange ticker symbol. All digits is read as a CIK (leading zeros and an EDGAR CIK prefix are both accepted: 320193, 0000320193, CIK0000320193); anything else is read as a ticker (1-10 characters starting with a letter) and matched exactly, case-insensitively, against the SEC listed-security index — AAPL, aapl and BRK-B all work. Company names are not accepted: resolve one with company.us.resolve. A ticker with no SEC index entry returns NOT_FOUND, which is not a billable result.
`form`	No	Comma-separated EDGAR form types to keep, e.g. "10-K,10-Q,8-K". Matching is exact and case-insensitive; omit to return every form.
`limit`	No	Maximum number of filings to return from the filtered set. Defaults to 5 so a first call stays small; raise it explicitly when you need more.
`since`	No	Keep only filings with a filing_date on or after this ISO date (YYYY-MM-DD).
`offset`	No	Zero-based offset into the filtered set, for paging. Pass page.next_offset from the previous response.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	Capability output; full JSON Schema at https://api.eckari.com/v1/capabilities/company.us.filings
`meta`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 18, 2026

removedInput schema / properties / cik

Removed value: -{
-  "description": "SEC Central Index Key, 1-10 digits, with or without leading zeros and with or without a CIK prefix. Obtain it from company.us.resolve.",
-  "maxLength": 13,
-  "minLength": 1,
-  "pattern": "^(?:[Cc][Ii][Kk])?[0-9]{1,10}$",
-  "type": "string"
-}

addedInput schema / properties / id

Added value: +{
+  "description": "SEC CIK or exchange ticker symbol. All digits is read as a CIK (leading zeros and an EDGAR CIK prefix are both accepted: 320193, 0000320193, CIK0000320193); anything else is read as a ticker (1-10 characters starting with a letter) and matched exactly, case-insensitively, against the SEC listed-security index — AAPL, aapl and BRK-B all work. Company names are not accepted: resolve one with company.us.resolve. A ticker with no SEC index entry returns NOT_FOUND, which is not a billable result.",
+  "maxLength": 13,
+  "minLength": 1,
+  "pattern": "^(?:(?:[Cc][Ii][Kk])?[0-9]{1,10}|[A-Za-z][A-Za-z0-9.-]{0,9})$",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "cik"
-]New value: +[
+  "id"
+]

Changed10 schema fields changedAug 18, 2026

changedInput schema / properties / limit / default
```
Previous value: -25New value: +5
```

changedInput schema / properties / limit / description

Previous value: -"Maximum number of filings to return from the filtered set."New value: +"Maximum number of filings to return from the filtered set. Defaults to 5 so a first call stays small; raise it explicitly when you need more."

changedInput schema / properties / offset / description

Previous value: -"Zero-based offset into the filtered set, for paging."New value: +"Zero-based offset into the filtered set, for paging. Pass page.next_offset from the previous response."

removedOutput schema / properties / data / additionalProperties
```
Removed value: -false
```

addedOutput schema / properties / data / description

Added value: +"Capability output; full JSON Schema at https://api.eckari.com/v1/capabilities/company.us.filings"

removedOutput schema / properties / data / properties

Removed value: -{
-  "cik": {
-    "description": "SEC Central Index Key, zero-padded to 10 digits.",
-    "type": "string"
-  },
-  "filings": {
-    "description": "Filings in EDGAR order, newest first. This is the company's EDGAR index, not a list of filings the company itself submitted: forms filed by third parties about the company (SCHEDULE 13G/13D by an institutional holder, Forms 3/4/5 by insiders, UPLOAD for SEC staff correspondence) appear here too, and EDGAR does not publish who submitted each one.",
-    "items": {
-      "additionalProperties": false,
-      "properties": {
-        "accession_number": {
-          "description": "EDGAR accession number in dashed form (e.g. 0000320193-25-000079).",
-          "type": "string"
-        },
-        "act": {
-          "description": "Securities act the filing is made under (33 or 34), or null when EDGAR states none.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "document_url": {
-          "description": "Direct https://www.sec.gov link to the primary document, or null when EDGAR reports no primary document.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "file_number": {
-          "description": "SEC file number, or null when EDGAR states none.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "filing_date": {
-          "description": "Date the filing was accepted by EDGAR (YYYY-MM-DD).",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "form": {
-          "description": "EDGAR form type exactly as filed (e.g. 10-K, 10-Q, 8-K, DEF 14A, SCHEDULE 13G).",
-          "type": "string"
-        },
-        "index_url": {
-          "description": "Direct https://www.sec.gov link to the filing index page listing every document in the submission.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "is_inline_xbrl": {
-          "description": "True when EDGAR flags the filing as inline XBRL.",
-          "type": "boolean"
-        },
-        "is_xbrl": {
-          "description": "True when EDGAR flags the filing as containing XBRL data.",
-          "type": "boolean"
-        },
-        "items": {
-          "description": "8-K item codes reported by the filing (e.g. 2.02, 9.01). Empty for forms that carry no item codes.",
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "primary_doc_description": {
-          "description": "EDGAR's description of the primary document, or null when blank upstream.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "primary_document": {
-          "description": "File name — or path relative to the filing's EDGAR Archives directory, which older submissions use — of the filing's primary document. document_url is the resolved link; prefer it over building one from this value.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "report_date": {
-          "description": "Period or event date the filing reports on (YYYY-MM-DD), or null when the form has none.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "size_bytes": {
-          "description": "Size of the filing package in bytes as reported by EDGAR, or null when absent.",
-          "type": [
-            "integer",
-            "null"
-          ]
-        }
-      },
-      "required": [
-        "accession_number",
-        "form",
-        "filing_date",
-        "report_date",
-        "act",
-        "file_number",
-        "items",
-        "primary_document",
-        "primary_doc_description",
-        "is_xbrl",
-        "is_inline_xbrl",
-        "size_bytes",
-        "document_url",
-        "index_url"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "has_more": {
-    "description": "Derived; true when filings matching the current form and since filters remain beyond this page within the recent window. filings.length < limit is NOT a valid end-of-page test on its own — compare offset + filings.length with total_count, or just read this field.",
-    "type": "boolean"
-  },
-  "has_more_history": {
-    "description": "True when EDGAR holds older filings outside the recent window that could still match this query. It is gated on the since filter: EDGAR declares the date range of each older page, so a since date newer than every older page means the recent window already holds every matching filing and this is false. Older pages are not traversed by this capability version; narrow the query with since or form instead.",
-    "type": "boolean"
-  },
-  "name": {
-    "description": "Current filer name on EDGAR.",
-    "type": "string"
-  },
-  "next_offset": {
-    "description": "Derived; the offset to pass to the next request to continue after the last filing returned. Null when has_more is false.",
-    "type": [
-      "integer",
-      "null"
-    ]
-  },
-  "offset": {
-    "description": "The offset applied to this page.",
-    "minimum": 0,
-    "type": "integer"
-  },
-  "total_count": {
-    "description": "Number of filings matching the form and since filters within EDGAR's recent filing window (see has_more_history), before limit and offset are applied.",
-    "minimum": 0,
-    "type": "integer"
-  }
-}

removedOutput schema / properties / data / required

Removed value: -[
-  "cik",
-  "name",
-  "total_count",
-  "offset",
-  "has_more",
-  "next_offset",
-  "has_more_history",
-  "filings"
-]

addedOutput schema / properties / meta / properties / attribution_url
```
Added value: +{
+  "format": "uri",
+  "type": "string"
+}
```
addedOutput schema / properties / meta / properties / retrieved_at / format
```
Added value: +"date-time"
```

addedOutput schema / properties / meta / required

Added value: +[
+  "capability",
+  "version",
+  "retrieved_at",
+  "source",
+  "freshness",
+  "request_id"
+]

First observedAug 18, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld, idempotent, and not destructive. The description adds pricing info, states that NOT_FOUND is not billable, and implies result includes document links. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences: purpose, use when, not for, related tools, pricing. Front-loaded with essential info, no fluff, each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, output schema exists, and annotations cover safety, the description covers usage, limitations, pricing, and non-billable case. It is complete for an agent to decide on tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents each parameter. The description adds no new semantic details beyond summarizing optional filters and paging. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns recent EDGAR filing history for a US company by ticker or CIK, with optional filtering and paging. The verb 'Return' and resource 'EDGAR filing history' are specific. It also lists related tools for differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use when' example (list every 8-K this year) and 'Not for' scenario (need filer identity, which is not provided). Also mentions related tools and pricing, giving clear context for when to use this tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All capabilities tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?