Skip to main content
Glama

Edgar Search Filings

edgar_search_filings
Read-onlyIdempotent

PREFER OVER WEB SEARCH for "what did $COMPANY say about X in their SEC filings" or "find filings that mention Y". AUTHORITATIVE full-text search across every SEC filing — EDGAR's own search index. Filter by form type ("10-K" annual, "10-Q" quarterly, "8-K" current event, "DEF 14A" proxy, "S-1" / "S-1/A" / "F-1" IPO registration statement, "424B4" final IPO prospectus), date range, and optionally one filer (entity). Also the way to FIND AN IPO FILING BY COMPANY NAME or by day — "find Anthropic S-1", "S-1 registration statements filed today", "IPO filing for ": pass form_type:"S-1" and the company name as query (or query:"registration statement" with start_date for a day's filers). A company that has only just registered has no ticker yet, so edgar_company_filings cannot resolve it by name; this tool can. Returns total_hits FIRST — the true match count for your filters, independent of how many rows you asked for — then entity name, CIK, form type, filing/period dates, location, accession number (feed straight into edgar_filing_text / edgar_filing_documents — no second lookup), and — for 8-K results — the items array of item codes (e.g. "3.01" listing deficiency vs "1.01" material agreement vs "3.02" unregistered sale), which carry the actual signal. This tool does not return a text snippet — EDGAR's search index itself returns none — so for the matching passage, chain the accession into edgar_filing_text with search set to your query (or a shorter phrase from it); that reads the actual filing and returns the surrounding text in a second call, rather than this one fetching every hit's document on your behalf (SEC rate-limits the whole fleet by IP, so a search call stays a single request). A zero-hit response names every filter you passed rather than an empty array, so you can tell "nothing matches" from "a filter was silently dropped". Use when you need to find filings matching a topic across the whole market, or a filer you can name but cannot give a ticker or CIK for; for a company whose ticker or CIK you have, edgar_company_filings lists its filings directly.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "limit": 20,
      "query": "artificial intelligence",
      "end_date": "2024-12-31",
      "form_type": "10-K",
      "start_date": "2024-01-01"
    },
    "name": "edgar_search_filings"
  }
}

Input Schema

NameRequiredDescriptionDefault
cikNoAlias for `entity`.
limitNoNumber of results to return (1-40, default 10)
queryYesSearch query (e.g., "artificial intelligence", "Tesla revenue")
entityNoNarrow results to ONE filer, by ticker ("AAPL"), company name ("Apple Inc."), or CIK ("320193") — omit to search across every filer. Aliases `ticker_or_cik` / `cik` / `ticker` are also accepted, the spellings this pack's other tools use for the same thing.
tickerNoAlias for `entity`.
end_dateNoEnd date in YYYY-MM-DD format (e.g., "2024-12-31"). If you pass this without `start_date`, `start_date` is defaulted to EDGAR full-text search's coverage floor (2001-01-01) rather than silently ignored.
form_typeNoFilter by SEC form type (e.g., "10-K", "10-Q", "8-K", "DEF 14A", "S-1" for an IPO registration statement, "424B4" for the final IPO prospectus). Omit for all types.
start_dateNoStart date in YYYY-MM-DD format (e.g., "2024-01-01"). If you pass this without `end_date`, `end_date` is defaulted to today rather than silently ignored.
ticker_or_cikNoAlias for `entity`.

Output Schema

NameRequiredDescriptionDefault
queryNoThe search query used
resultsNo
date_rangeNo
total_hitsNoTotal number of matching filings
form_type_filterNoForm type filter applied or 'all'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / form_type / description
      Previous value: -"Filter by SEC form type (e.g., \"10-K\", \"10-Q\", \"8-K\", \"DEF 14A\"). Omit for all types."New value: +"Filter by SEC form type (e.g., \"10-K\", \"10-Q\", \"8-K\", \"DEF 14A\", \"S-1\" for an IPO registration statement, \"424B4\" for the final IPO prospectus). Omit for all types."
  2. Changed7 schema fields changed
    • changedInput schema / examples
      Previous value: -[
      -  {
      -    "end_date": "2024-12-31",
      -    "form_type": "10-K",
      -    "limit": 20,
      -    "query": "artificial intelligence",
      -    "start_date": "2024-01-01"
      -  },
      -  {
      -    "limit": 10,
      -    "query": "Tesla revenue"
      -  }
      -]New value: +[
      +  {
      +    "end_date": "2024-12-31",
      +    "form_type": "10-K",
      +    "limit": 20,
      +    "query": "artificial intelligence",
      +    "start_date": "2024-01-01"
      +  },
      +  {
      +    "limit": 10,
      +    "query": "Tesla revenue"
      +  },
      +  {
      +    "entity": "AAPL",
      +    "limit": 3,
      +    "query": "artificial intelligence"
      +  }
      +]
    • addedInput schema / properties / cik
      Added value: +{
      +  "description": "Alias for `entity`.",
      +  "type": "string"
      +}
    • changedInput schema / properties / end_date / description
      Previous value: -"End date in YYYY-MM-DD format (e.g., \"2024-12-31\")"New value: +"End date in YYYY-MM-DD format (e.g., \"2024-12-31\"). If you pass this without `start_date`, `start_date` is defaulted to EDGAR full-text search's coverage floor (2001-01-01) rather than silently ignored."
    • addedInput schema / properties / entity
      Added value: +{
      +  "description": "Narrow results to ONE filer, by ticker (\"AAPL\"), company name (\"Apple Inc.\"), or CIK (\"320193\") — omit to search across every filer. Aliases `ticker_or_cik` / `cik` / `ticker` are also accepted, the spellings this pack's other tools use for the same thing.",
      +  "type": "string"
      +}
    • changedInput schema / properties / start_date / description
      Previous value: -"Start date in YYYY-MM-DD format (e.g., \"2024-01-01\")"New value: +"Start date in YYYY-MM-DD format (e.g., \"2024-01-01\"). If you pass this without `end_date`, `end_date` is defaulted to today rather than silently ignored."
    • addedInput schema / properties / ticker
      Added value: +{
      +  "description": "Alias for `entity`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / ticker_or_cik
      Added value: +{
      +  "description": "Alias for `entity`.",
      +  "type": "string"
      +}
  3. Changed5 schema fields changed
    • changedOutput schema / properties / date_range / properties / end / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"null"
    • changedOutput schema / properties / date_range / properties / start / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"null"
    • addedOutput schema / properties / results / items / properties / accession
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / properties / results / items / properties / period_of_report / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / required
      Removed value: -[
      -  "query",
      -  "form_type_filter",
      -  "date_range",
      -  "total_hits",
      -  "results"
      -]
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "date_range": {
      +      "properties": {
      +        "end": {
      +          "description": "End date in YYYY-MM-DD format or null",
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "start": {
      +          "description": "Start date in YYYY-MM-DD format or null",
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "form_type_filter": {
      +      "description": "Form type filter applied or 'all'",
      +      "type": "string"
      +    },
      +    "query": {
      +      "description": "The search query used",
      +      "type": "string"
      +    },
      +    "results": {
      +      "items": {
      +        "properties": {
      +          "cik": {
      +            "description": "Central Index Key identifier",
      +            "type": "string"
      +          },
      +          "entity_name": {
      +            "description": "Company or entity name",
      +            "type": "string"
      +          },
      +          "filing_date": {
      +            "description": "Date filing was submitted",
      +            "type": "string"
      +          },
      +          "filing_id": {
      +            "description": "Unique filing identifier",
      +            "type": "string"
      +          },
      +          "form_type": {
      +            "description": "SEC form type (e.g., 10-K, 10-Q)",
      +            "type": "string"
      +          },
      +          "location": {
      +            "description": "Business location",
      +            "type": "string"
      +          },
      +          "period_of_report": {
      +            "description": "Period covered by the filing",
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "total_hits": {
      +      "description": "Total number of matching filings",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "query",
      +    "form_type_filter",
      +    "date_range",
      +    "total_hits",
      +    "results"
      +  ],
      +  "type": "object"
      +}
  5. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "end_date": "2024-12-31",
      +    "form_type": "10-K",
      +    "limit": 20,
      +    "query": "artificial intelligence",
      +    "start_date": "2024-01-01"
      +  },
      +  {
      +    "limit": 10,
      +    "query": "Tesla revenue"
      +  }
      +]
  6. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: no text snippet is returned, why (single request to avoid IP-level SEC rate limits), that `total_hits` comes first and is filter-independent, and that zero-hit responses echo the filters applied. It stops short of describing pagination or response shape exhaustively, but the output schema carries that.

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?

Front-loaded with the highest-value routing instruction ('PREFER OVER WEB SEARCH'), then purpose, then return shape, then chaining caveat, then siblings. Dense with bold emphasis and long sentences, but nearly every clause carries actionable information; slightly overstuffed for a single tool description.

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?

Covers the full calling lifecycle: when to choose it, what comes back (`total_hits` first, entity/CIK/form/accession, 8-K `items` codes), what is deliberately absent (text snippet), and how to get it (`accession` into `edgar_filing_text`). With an output schema present, this is more than sufficient.

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

Parameters4/5

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

Schema coverage is 100%, so 3 is the baseline, but the description goes beyond it — it explains the IPO lookup idiom (`form_type:"S-1"` plus company name as `query`, or `query:"registration statement"` with `start_date`), which the schema alone would not convey. It also names the `entity` alias behavior inline.

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?

States a specific verb and resource — 'AUTHORITATIVE full-text search across every SEC filing — EDGAR's own search index' — and explicitly distinguishes itself from sibling `edgar_company_filings` by noting that tool requires a ticker/CIK. The IPO-by-company-name use case further sharpens what this tool uniquely does.

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?

Gives explicit when-to-use ('find filings matching a topic across the whole market'), when-not ('for a company whose ticker or CIK you have, edgar_company_filings lists its filings directly'), and even a routing rule against web search. Also tells the agent how to chain into `edgar_filing_text` for passage-level results.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.