Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SEC EDGAR MCP Server Show me Apple's latest 10-K filing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only Model Context Protocol server, over stdio, that
takes a stock ticker, resolves it to the SEC's Central Index Key (CIK), and returns filing
metadata with official EDGAR links. It exposes three tools, five resources and three prompts.
No API key is needed: SEC EDGAR is public, and the server only identifies itself with a
descriptive User-Agent. The server never reads, downloads or summarises filing contents; it
tells you which filings exist and where they are on sec.gov.
Published on PyPI as mcp-server-edgar; Registry identity io.github.SudiptoHaldar/mcp-server-edgar.
The server is a Python package with a console entry point. The simplest way to run it is with uv, which fetches Python 3.11 or newer when needed:
uvx mcp-server-edgarOr install it into any environment with Python 3.11 or newer:
pip install mcp-server-edgar
mcp-server-edgarThe executable speaks MCP on stdin and stdout and is meant to be launched by an MCP client, so on its own it waits for a client. To try it interactively, use the MCP Inspector:
npx -y @modelcontextprotocol/inspector uvx mcp-server-edgarRelated MCP server: Ticker Scout MCP server
Claude Desktop and most other JSON-configured clients take an mcpServers entry. The optional
env block sets the SEC fair-access contact (see Configuration):
{
"mcpServers": {
"sec-edgar": {
"command": "uvx",
"args": ["mcp-server-edgar"],
"env": {
"MCP_EDGAR_USER_AGENT": "acme-research/1.0 (ops@acme.example)"
}
}
}
}Claude Code:
claude mcp add sec-edgar -- uvx mcp-server-edgarAll three tools are read-only and return a JSON object whose status field says what happened
(see Results and errors). Years always refer to the filing date, the day the SEC received a
filing, never to the period the filing covers.
Newest filing for a ticker, optionally restricted to given form types.
Argument | Type | Default | Meaning |
| string | required | Stock ticker, e.g. |
| list of strings | all forms | Exact form types, case-insensitive: |
| string or integer | none | SEC CIK (1–10 digits), only after an |
Example call get_latest_filing("AAPL", ["10-K"]); result abridged, values as of 2026-11-01:
{
"status": "ok",
"company": {"cik": "0000320193", "name": "Apple Inc.", "ticker": "AAPL", "exchange": "Nasdaq"},
"forms": ["10-K"],
"filing": {
"form": "10-K",
"filing_date": "2025-10-31",
"report_date": "2025-09-27",
"accession_number": "0000320193-25-000079",
"filing_url": "https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/0000320193-25-000079-index.htm",
"primary_document_url": "https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/aapl-20250927.htm"
},
"message": "Newest 10-K by Apple Inc. (AAPL): filed 2025-10-31."
}filing is null when the company has no filing of the requested forms.
Every filing a company submitted during one calendar year, newest first, in pages.
Argument | Type | Default | Meaning |
| string | required | As above |
| integer | required | Calendar year of the filing date, 1993 or later; a future year returns an empty list |
| list of strings | all forms | As above |
| integer | 100 | Page size; larger values are clamped to the server's cap |
| integer | 0 | Filings to skip; pass the previous result's |
| string or integer | none | As above |
The year is the filing year, not the fiscal year: Apple's 10-K for the fiscal year ending
September 2025 was filed on 2025-10-31, so it belongs to year=2025; a 10-K filed in January
2026 for a fiscal year 2025 belongs to year=2026. Older years are served from the SEC's
history files automatically.
Example call list_filings_by_year("AAPL", 2025, ["10-K", "10-Q"]); result abridged, values as
of 2026-11-01:
{
"status": "ok",
"company": {"cik": "0000320193", "name": "Apple Inc.", "ticker": "AAPL", "exchange": "Nasdaq"},
"year": 2025,
"forms": ["10-K", "10-Q"],
"limit": 100,
"offset": 0,
"total_count": 4,
"returned_count": 4,
"next_offset": null,
"filings": [
{
"form": "10-K",
"filing_date": "2025-10-31",
"report_date": "2025-09-27",
"accession_number": "0000320193-25-000079",
"filing_url": "https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/0000320193-25-000079-index.htm",
"primary_document_url": "https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/aapl-20250927.htm"
}
],
"message": "Apple Inc. (AAPL): 4 filings of form 10-K, 10-Q with a filing date in 2025."
}To page, call again with offset set to next_offset until it is null. Pages never overlap.
A year with no filings is ok with total_count 0.
The EDGAR submission-type codes filed in recent quarters, most common first. Use it to learn
which values forms accepts: form is exactly the code EDGAR uses (10-K, 10-K/A,
SCHEDULE 13G/A, 424B2, NPORT-P).
Argument | Type | Default | Meaning |
| string | none | Case-insensitive text matched against the code and its description; |
| integer | 100 | Entries per page |
| integer | 0 | Entries to skip; pass the previous |
The catalogue is a snapshot bundled with the package, counted over the four completed
quarters before the release and refreshed with each release; catalogue.generated_on and
catalogue.quarters say which. Calling it makes no request to the SEC. description and
topics come from the SEC Forms List when the form number is known, otherwise null.
Example call list_form_types("10-K"); result abridged, values as of 2026-11-01:
{
"status": "ok",
"query": "10-K",
"total_count": 6,
"returned_count": 6,
"next_offset": null,
"catalogue": {"generated_on": "2026-11-01", "quarters": ["2025Q4", "2026Q1", "2026Q2", "2026Q3"]},
"form_types": [
{"form": "10-K", "description": "Annual report pursuant to Section 13 or 15(d)", "amendment": false, "filings": 6723},
{"form": "10-K/A", "description": "Annual report pursuant to Section 13 or 15(d)", "amendment": true, "filings": 616}
],
"message": "6 form types match '10-K' in 2025Q4-2026Q3."
}Every tool answers with a JSON object. Anticipated conditions are reported in status, never as
a protocol error, so a client can act on them:
| Meaning | Also carries |
| The request succeeded |
|
| No SEC issuer is listed under the ticker | — |
| Several issuers share the ticker; none is chosen |
|
| An argument was rejected before any request was made |
|
| SEC EDGAR did not answer in time, was rate-limited or returned bad data |
|
Every object also carries a one-line message. A filing record always has form,
filing_date, report_date (the period covered, context only, may be null),
accession_number and filing_url (the official filing index page on sec.gov);
primary_document_url points at the main document when the SEC lists one and the file name is
safe, otherwise it is null.
Clients that can attach resources as context may read these JSON documents directly, without a tool call. They are built by the same code path as the tools, so a resource and its tool always agree.
URI | Payload |
|
|
|
|
| The profile addressed by CIK (any 1–10-digit spelling) |
| The latest filing addressed by CIK |
|
|
Use the edgar://issuers/{cik}/… routes when a ticker is ambiguous; the CIK must be listed in
the SEC ticker map. Resources have no status envelope: an unknown ticker, a malformed or
unlisted CIK or an unmatched URI is a resource-not-found error, and an ambiguous ticker or an
SEC outage is a resource error, each carrying the same message text the tools use.
Prompts are reusable instructions a person selects from the client's prompt menu; the client inserts the rendered text and the model then uses the tools. They carry no live data.
Prompt | Title | Arguments | The rendered text asks the model to |
| Review latest SEC filing |
| call |
| Review filings for a calendar year |
| call |
| Explain EDGAR form types |
| call |
Every prompt ends with the same guardrails: metadata and official sec.gov links only, the server
does not read filing contents, cite the EDGAR link for every filing, give no investment advice,
and on an ambiguous answer ask which issuer is meant before calling again with that cik.
All settings are environment variables with defaults. Unset or empty values take the default; a bad value stops startup with exit code 1 and one line on stderr naming the variable.
Variable | Default | Accepted | Purpose |
|
| non-empty, must contain | SEC fair-access identification with a maintainer contact; set your own |
|
| number > 0 | HTTP timeout for SEC requests |
|
| integer ≥ 0 (0 = no cache) | Cache lifetime of the SEC ticker map |
|
| integer ≥ 0 | Cache lifetime of a company's submissions |
|
| integer 1..1000 | Largest page |
|
| integer 1..10 | Request ceiling; the SEC allows at most 10 requests per second and the server cannot be set higher |
|
|
| Log level |
The SEC asks every automated client to identify itself with a contact address, so set
MCP_EDGAR_USER_AGENT to your own product name and e-mail. Logs go to stderr only; stdout
carries the protocol.
Ticker to CIK: https://www.sec.gov/files/company_tickers_exchange.json, cached for a
day. One ticker listed under several CIKs is reported as ambiguous; one CIK with several
tickers (GOOGL, GOOG) is one issuer.
Filings: https://data.sec.gov/submissions/CIK##########.json (CIK zero-padded to ten
digits), cached for an hour. Older years are read from the history files the submissions
document lists, and only those whose date range overlaps the requested year.
Links: the filing index page …/Archives/edgar/data/<cik>/<accession>/<accession>-index.htm
is always returned; the primary document link is built from the SEC's file name after
rejecting anything that is not a plain file name.
Fair access: at most 10 requests per second, a descriptive User-Agent, in-memory
caching per process, and bounded retries with backoff on HTTP 429 and transient 5xx responses.
When the SEC still does not answer, the tool returns upstream_error with a retry hint rather
than an empty result. See the SEC's
EDGAR API documentation.
Metadata and links only: no filing contents, no XBRL financial facts, no summaries, no investment advice.
year means the calendar year the SEC received the filing, not the fiscal year it reports on.
Years before 1993 (the start of electronic filing) are rejected as invalid_input.
Only issuers in the SEC ticker map can be looked up; funds and private filers without a listed ticker are out of scope, and the server never queries an arbitrary CIK.
The form-type catalogue is a snapshot taken before each release, not a live list.
Transport is stdio only; there is no HTTP endpoint and no authentication.
Caches live in memory for the lifetime of one server process.
This project is not affiliated with or endorsed by the U.S. Securities and Exchange Commission.
git clone https://github.com/SudiptoHaldar/mcp_server_edgar
cd mcp_server_edgar
uv sync
uv run pytest -q # unit tests never touch the network
uv run pytest -q -m live # opt-in checks against the real SEC
uv run ruff check .
uv run mcp dev src/mcp_edgar/server.py # MCP Inspector GUI
uv run python scripts/inspector_checklist.py # 27-row CLI checklist (needs Node and network)Before a release, refresh the bundled form-type catalogue, then build:
uv run python scripts/refresh_form_types.py
uv buildIssues and pull requests: https://github.com/SudiptoHaldar/mcp_server_edgar/issues.
MIT, see LICENSE. SEC EDGAR data is public domain and is served here under the SEC's fair-access rules.
Newest SEC filing for a stock ticker, with official EDGAR links.
Resolves the ticker to its SEC CIK and returns the filing with the latest filing_date
(the date the SEC received it). forms restricts the search to exact form types,
case-insensitive: ["10-K"] matches 10-K but not 10-K/A; omit it to consider every
form. report_date (the period the filing covers) is returned as context only, so a 10-K
filed in January 2026 for the fiscal year ending September 2025 has a 2026 filing_date.
Args:
ticker: Stock ticker symbol, e.g. "AAPL". Case and surrounding whitespace are
ignored; BRK.B and BRK-B are equivalent.
forms: Optional list of SEC form types, e.g. ["10-K", "10-Q"].
cik: Optional SEC CIK (1-10 digits, string or integer) to pick one issuer when a
previous call returned "ambiguous"; it must be listed under ticker.
Returns:
A JSON object whose status is one of:
- "ok": company {cik, name, ticker, exchange}, forms (normalised list or null),
filing {form, filing_date, report_date, accession_number, filing_url,
primary_document_url} or null when the company has no filing of those forms;
filing_url (the filing index page) is always present, primary_document_url
may be null.
- "not_found": no SEC issuer is listed under ticker.
- "ambiguous": several issuers share the ticker; candidates lists them
(cik, name, ticker, exchange) and none is chosen; call again with the chosen cik.
- "invalid_input": field names the rejected argument (ticker, forms or cik).
- "upstream_error": SEC EDGAR did not answer; retryable tells whether a retry
may help and retry_after_seconds when (may be null).
Every object carries a one-line message.
Example:
get_latest_filing("AAPL", ["10-K"]) returns Apple's most recent annual report.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | ||
| forms | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by documenting the full status model (`ok`, `not_found`, `ambiguous`, `invalid_input`, `upstream_error`), retry behavior, ambiguity handling, and the distinction between `filing_date` and `report_date`. It is consistent with the read-only, open-world, idempotent annotations and adds substantial operational context.
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 definition is front-loaded with the purpose, then parameters, statuses, and an example, so an agent can scan it efficiently. It is somewhat long and includes a detailed Returns section even though an output schema exists, but the structure remains purposeful and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a read-only open-world lookup with three parameters and an output schema, the description covers the purpose, all parameter semantics, ambiguity resolution, error handling, and return statuses. An agent has enough context to call it correctly and interpret edge cases.
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 0%, so the description must carry all parameter meaning, and it does: `ticker` normalization and `BRK.B`/`BRK-B` equivalence, `forms` exact and case-insensitive matching, and `cik` digit/type/ambiguity constraints. This is comprehensive beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieve the newest SEC filing for a ticker, resolve it to a CIK, and return official EDGAR links. The singular 'latest filing' framing clearly distinguishes it from the sibling listing tools, which are oriented around year and form-type enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage context for optional parameters: `forms` restricts exact form types and should be omitted to consider all forms, while `cik` is for disambiguating a prior `"ambiguous"` result. It does not explicitly compare against the sibling tools, so it stops short of full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filings a company submitted to the SEC during one calendar year, newest first, paged.
year selects filings by filing_date, the date the SEC received the filing, not by
report_date (the period the filing covers): a 10-K for the fiscal year ending September
2025 that was filed in January 2026 belongs to year=2026. forms restricts the list to
exact form types, case-insensitive (["10-K"] matches 10-K but not 10-K/A). Older
years are served from the SEC's history files automatically.
Args:
ticker: Stock ticker symbol, e.g. "AAPL"; case and surrounding whitespace are ignored.
year: Calendar year of the filing date, 1993 or later; a future year returns an empty list.
forms: Optional list of SEC form types, e.g. ["10-K", "10-Q"]; omit it for every form.
limit: Page size (default 100); larger values are clamped to the server's cap.
offset: Filings to skip, for paging; pass the previous result's next_offset.
cik: Optional SEC CIK (1-10 digits, string or integer) to pick one issuer when a
previous call returned "ambiguous"; it must be listed under ticker.
Returns:
A JSON object whose status is one of:
- "ok": company {cik, name, ticker, exchange}, year, forms, limit (the
effective page size), offset, total_count, returned_count, next_offset (null
on the last page), filings (newest first; each has form, filing_date, report_date,
accession_number, filing_url, primary_document_url). An empty year is "ok" with
total_count 0.
- "not_found": no SEC issuer is listed under ticker.
- "ambiguous": several issuers share the ticker; candidates lists them; call again
with the chosen cik.
- "invalid_input": field names the rejected argument (ticker, year, forms,
limit, offset or cik).
- "upstream_error": SEC EDGAR did not answer; retryable says whether to retry.
Every object carries a one-line message. Page with offset=next_offset until null.
Example:
list_filings_by_year("AAPL", 2025, ["10-K", "10-Q"]) lists Apple's 2025 reports.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | ||
| year | Yes | ||
| forms | No | ||
| limit | No | ||
| offset | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the readOnly/openWorld/idempotent annotations, it discloses paging protocol (`offset=next_offset` until null), limit clamping, automatic use of SEC history files for older years, empty-year behavior, and the full status taxonomy including which status is retryable.
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 summary followed by clearly labeled Args/Returns/Example sections, so length is manageable. The Returns block partly restates the existing output schema, which is the main redundancy, but the rest of the text earns its space with semantics not found elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, open-world read tool with no schema descriptions, the definition covers input semantics, paging, ambiguity resolution, and error handling. Output schema exists, so the extra return documentation is a bonus rather than a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it does: ticker normalization, year lower bound 1993 and future-year empty result, forms exact/case-insensitive matching, limit clamping, offset paging, and the constraint that `cik` must be listed under `ticker`. Every one of the six parameters gets meaning the bare schema lacks.
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 (filings a company submitted to the SEC), scopes it to one calendar year, and declares ordering (newest first) and paging. An agent can immediately separate this from get_latest_filing or list_form_types.
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 concrete selection rules: `year` keys off filing_date not report_date (with a worked 10-K example), `forms` is exact match and case-insensitive, and `cik` is the fallback when a prior call returned `ambiguous`. It does not explicitly contrast itself against the sibling get_latest_filing, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EDGAR form types (submission-type codes) filed in recent quarters, most common first.
Use this to learn which values the forms argument of get_latest_filing and
list_filings_by_year accepts: form is exactly the code EDGAR uses (10-K, 10-K/A,
SCHEDULE 13G/A, 424B2, NPORT-P). The list is a snapshot bundled with the server (see
catalogue.generated_on and catalogue.quarters); filings counts filings of that type
over those quarters; description and topics come from the SEC Forms List when the form
number is known, otherwise null. Amendments end with /A. No request is made to the SEC.
Args:
query: Optional case-insensitive text matched against the code and description
("10-K" lists 10-K, 10-K/A, 10-KT, ...; "/A" lists amendments).
limit: Maximum entries per page (default 100; clamped to the server's cap).
offset: Entries to skip, for paging; pass the previous result's next_offset.
Returns:
A JSON object whose status is one of:
- "ok": query, limit, offset, total_count, returned_count, next_offset
(null on the last page), catalogue {generated_on, quarters, sources},
form_types (each: form, description, amendment, filings, topics).
- "invalid_input": field names the rejected argument (query, limit or
offset).
Every object carries a one-line message.
Example:
list_form_types("13G") lists the Schedule 13G submission types and their counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already marking this as read-only and idempotent, the description adds substantial context: the list is a bundled snapshot, `catalogue.generated_on` and `catalogue.quarters` identify its vintage, `filings` counts are scoped to those quarters, and no request is made to the SEC. It also explains null descriptions/topics and that amendments end with `/A`.
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 well-structured and front-loaded, moving from purpose to usage to argument details and examples. It is somewhat long, especially the Returns section, which partly duplicates the existing output schema, but almost every sentence adds useful 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?
Given three optional parameters, an output schema, and annotations covering safety, the description is complete. It covers purpose, usage, argument semantics, snapshot provenance, result shape, error status, and paging behavior.
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 0%, so the description must carry parameter meaning, and it does. It explains `query` as case-insensitive matching against code and description with examples, `limit` as page size with a server-side cap, and `offset` as paging tied to `next_offset`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: list EDGAR form types (submission-type codes) filed in recent quarters, ordered most common first. It also distinguishes the tool from siblings by explaining that it provides the accepted values for the `forms` argument of `get_latest_filing` and `list_filings_by_year`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool: to learn which values the `forms` argument accepts, with concrete examples such as `10-K` and `/A`. It also routes the agent by naming the sibling tools that consume these form codes.
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.
v0.1.0get_latest_filinglist_filings_by_yearlist_form_typesScored across 3 tools
The three tools target distinct operations: newest filing, per-year paged listing, and a form-type reference catalogue. There is mild overlap in that a 'latest filing' could be approximated by a year listing with limit=1, but the descriptions make the boundaries (single newest vs. paged by calendar year vs. metadata lookup) clear enough that misselection is unlikely.
All three names follow a consistent snake_case verb_object pattern (get_latest_filing, list_filings_by_year, list_form_types). The prepositional qualifier in list_filings_by_year is a parameter hint rather than a convention break, and the resource nouns are coherent.
Three tools is on the lean side, but the domain (filing discovery) is narrow and each tool earns its place: latest filing, historical listing, and form-type validation. It sits at the low end of the healthy 3-15 range rather than being padded or trivial.
Coverage of filing discovery is good and uniform (status/error/ambiguity handling is consistent across calls), but there are notable gaps: no company lookup by name, no date-range query beyond a single calendar year, and no way to retrieve filing document content (only URLs). Agents must leave the server to read a filing, which is a real dead end for many workflows.
Resolves all 10,000+ US public stock tickers to SEC CIK numbers, recent 10-K/10-Q/8-K filings, an.
SEC EDGAR 10-K/10-Q/8-K filings and XBRL company facts by ticker, CIK or company name.
Resolves stock tickers to SEC CIK numbers, recent 10-K/10-Q/8-K filings, and entity metadata.
Search SEC filings, read 10-K/8-K, query XBRL facts, track Form 4 insider trades.
