SEC EDGAR MCP Server

Latest SEC filing

get_latest_filing

Read-onlyIdempotent

Resolve a stock ticker to its SEC CIK and return the filing with a filing date later than any other, optionally filtered by form type, with official EDGAR links.

Instructions

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.

Input Schema

Name	Required	Description	Default
`cik`	No
`forms`	No
`ticker`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server