Skip to main content
Glama

Edgar Filing Text

edgar_filing_text
Read-onlyIdempotent

AUTHORITATIVE full text of a SEC filing's primary document (10-K / 10-Q / 8-K body), HTML stripped to clean plaintext — the source for disclosures that live in prose, not XBRL: going-concern language, ATM / at-the-market equity facilities, committed-equity share caps, public-float figures, subsequent events, the liquidity footnote, and MD&A KPIs XBRL never tags (test volume, units shipped, subscriber counts, same-store sales). Pass an accession (from edgar_search_filings / edgar_company_filings) plus the filer's ticker or CIK; OR omit accession and pass ticker + form_type to auto-resolve the latest matching filing. For a specific fact inside a long filing, pass search (a word or exact phrase, e.g. "tests processed" or "processed approximately") instead of paging blind — it scans the WHOLE document (before any offset/max_chars windowing) and returns every matching passage with surrounding context and its own offset in the document, so a KPI ~100k characters in is found in one call instead of paging through max_chars windows by hand. A zero-match search is a real answer (the filing does not use that exact wording) — retry with a shorter or different phrase rather than assuming the tool failed. Optionally set section to return just one part (going_concern | liquidity | capital_resources | subsequent_events); search runs within that slice when both are given. Large docs (a 10-Q is ~100k+ chars of text) are PAGED, not spilled, when search is not used: the result caps at max_chars (default 50000) from offset, and returns truncated + next_offset — pass next_offset back as offset to read the next window. An especially large filing (e.g. an S-1 with heavy inline-XBRL tagging can exceed 10MB of raw HTML) is also capped on the READ side — the response sets raw_truncated:true when only the first portion of the document was read at all, which bounds how far offset can page (and how far search can scan) and can make a late section or search term come back not-found even though it exists further in. Use for "does $TICKER disclose substantial doubt / going concern", "what ATM facility does $TICKER have", "read the liquidity section of the latest 10-Q", "how many tests did $TICKER process this quarter". For the list of documents/exhibits in a filing use edgar_filing_documents; for structured financial numbers use edgar_company_concept.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoFiler CIK number (e.g. "1652935"). Provide this OR ticker.
findNoAlias for `search`.
offsetNoCharacter offset to start from (default 0). Pass the prior result's next_offset to page forward.
phraseNoAlias for `search`.
searchNoFind a specific fact instead of paging blind. Pass a short 2-4 word phrase likely to appear VERBATIM in the prose ("processed approximately", "tests processed", "going concern") rather than restating the question. Case-insensitive substring match over the WHOLE document text (or the whole `section` slice), run BEFORE max_chars/offset windowing; returns matching passages (context + their own offset) instead of the paged `text`, ranking passages with a nearby figure first. If a multi-word phrase has no verbatim match, it falls back to the phrase's individual words and returns the passages holding the most of them (search.match_mode "words") — read those passages for the fact rather than treating them as confirmed. Use a returned offset with a follow-up call (no `search`) to read more surrounding text. Accepted aliases: `contains`, `find`, `phrase`.
tickerNoFiler ticker (e.g. "ACTU"). Provide this OR cik. ONLY pass a ticker you are CERTAIN of — a wrong remembered ticker silently retrieves a DIFFERENT company's filing as a clean success (a "SpaceX" question filled with SPCE returns Virgin Galactic's S-1). For a recent IPO or any uncertain ticker, resolve first: edgar_company_filings accepts the company NAME and returns the cik — pass that cik here.
sectionNoReturn only this section (located by heading). Omit for the whole document. Unmatched sections fall back to the whole document (section_found:false).
containsNoAlias for `search`.
accessionNoSEC accession number, dashed or not (e.g. "0001683168-26-003909"). Omit to auto-resolve the latest filing of form_type for the given ticker/cik.
form_typeNoWhen accession is omitted, the form type of the latest filing to fetch — "10-K", "10-Q", "8-K", "DEF 14A", etc. For "the most recent 10-K OR 10-Q" (or any "whichever of these is newer" question), pass a `|`-separated SET, e.g. "10-K|10-Q" — do NOT guess a single type ("10-K" by habit skips a newer 10-Q) and do NOT omit this field to get "any type", since a company files far more 8-Ks/Form 4s/Form 144s between annual or quarterly reports than it files the reports themselves and an empty form_type returns the single most recent filing of ANY kind (verified live 2026-09-25, fleet #2450: NTRA's single most recent SEC filing was a Form 144 insider-sale notice, filed weeks after its real 10-Q and completely unrelated to the question asked).
max_charsNoMax characters to return in this page (1000–100000, default 50000). Doc text past this is available via next_offset.
ticker_or_cikNoAlias for `ticker` / `cik` — the single-argument spelling edgar_company_filings and edgar_insider_transactions use. Takes either a ticker or a CIK.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / form_type / description
      Previous value: -"When accession is omitted, the form type of the latest filing to fetch — \"10-K\", \"10-Q\", \"8-K\", \"DEF 14A\", etc. A question asking for the \"most recent 10-K OR 10-Q\" (or otherwise not committed to one type) should OMIT this field entirely rather than guess \"10-K\" by habit — omitting form_type (along with accession) returns the single most recent filing of ANY type, and a 10-Q is very often more recent than the last 10-K since it files quarterly while the 10-K only files once a year (verified live 2026-09-25, fleet #2450: NTRA's most recent 10-Q was filed 2026-08-07, five months after its 2026-02-27 10-K — passing form_type:\"10-K\" here silently skips the newer filing and the KPI it asked about)."New value: +"When accession is omitted, the form type of the latest filing to fetch — \"10-K\", \"10-Q\", \"8-K\", \"DEF 14A\", etc. For \"the most recent 10-K OR 10-Q\" (or any \"whichever of these is newer\" question), pass a `|`-separated SET, e.g. \"10-K|10-Q\" — do NOT guess a single type (\"10-K\" by habit skips a newer 10-Q) and do NOT omit this field to get \"any type\", since a company files far more 8-Ks/Form 4s/Form 144s between annual or quarterly reports than it files the reports themselves and an empty form_type returns the single most recent filing of ANY kind (verified live 2026-09-25, fleet #2450: NTRA's single most recent SEC filing was a Form 144 insider-sale notice, filed weeks after its real 10-Q and completely unrelated to the question asked)."
    • changedInput schema / properties / search / description
      Previous value: -"Find a specific fact instead of paging blind. This is a SUBSTRING match, not a relevance search — pass the exact 2-4 word phrase most likely to appear VERBATIM in the prose (\"tests processed\", \"processed approximately\", \"going concern\"), never a compound of every concept in the question. A phrase that ANDs several unrelated question-words together (\"oncology Signatera revenue test volume\") returns ZERO matches even in the CORRECT filing, because the filing's own sentence never contains all of those words together — verified live 2026-09-25 (fleet #2450) on a real Natera 10-Q that DOES report the exact number asked for: \"Signatera revenue\" and the 4-word compound above both found nothing, while the filing's own wording (\"processed approximately\", \"tests processed\") is what actually appears. When unsure of the filing's exact phrasing, prefer the SHORTEST distinctive 2-3 word fragment of the metric name itself (a unit, a verb+noun like \"processed approximately\") over restating the question. Case-insensitive substring match over the WHOLE document text (or the whole `section` slice, if both are given), run BEFORE max_chars/offset windowing. Returns every matching passage (surrounding context + its own offset in the document) instead of the normal paged `text` — use the returned offsets with a follow-up call (no `search`, `offset` set to one of them) if you need more surrounding text than the passage gives. Zero matches means try again with a SHORTER, more literal phrase before concluding the filing does not disclose it — this is a real answer about wording, not a tool failure. Accepted aliases: `contains`, `find`, `phrase`."New value: +"Find a specific fact instead of paging blind. Pass a short 2-4 word phrase likely to appear VERBATIM in the prose (\"processed approximately\", \"tests processed\", \"going concern\") rather than restating the question. Case-insensitive substring match over the WHOLE document text (or the whole `section` slice), run BEFORE max_chars/offset windowing; returns matching passages (context + their own offset) instead of the paged `text`, ranking passages with a nearby figure first. If a multi-word phrase has no verbatim match, it falls back to the phrase's individual words and returns the passages holding the most of them (search.match_mode \"words\") — read those passages for the fact rather than treating them as confirmed. Use a returned offset with a follow-up call (no `search`) to read more surrounding text. Accepted aliases: `contains`, `find`, `phrase`."
  2. Changed6 schema fields changed
    • changedInput schema / examples
      Previous value: -[
      -  {
      -    "form_type": "10-Q",
      -    "section": "liquidity",
      -    "ticker": "ACTU"
      -  },
      -  {
      -    "accession": "0001683168-26-003909",
      -    "cik": "1652935",
      -    "max_chars": 30000,
      -    "section": "going_concern"
      -  }
      -]New value: +[
      +  {
      +    "form_type": "10-Q",
      +    "section": "liquidity",
      +    "ticker": "ACTU"
      +  },
      +  {
      +    "accession": "0001683168-26-003909",
      +    "cik": "1652935",
      +    "max_chars": 30000,
      +    "section": "going_concern"
      +  },
      +  {
      +    "accession": "0001628280-26-054525",
      +    "search": "processed approximately",
      +    "ticker": "NTRA"
      +  }
      +]
    • addedInput schema / properties / contains
      Added value: +{
      +  "description": "Alias for `search`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / find
      Added value: +{
      +  "description": "Alias for `search`.",
      +  "type": "string"
      +}
    • changedInput schema / properties / form_type / description
      Previous value: -"When accession is omitted, the form type of the latest filing to fetch — \"10-K\", \"10-Q\", \"8-K\", \"DEF 14A\", etc."New value: +"When accession is omitted, the form type of the latest filing to fetch — \"10-K\", \"10-Q\", \"8-K\", \"DEF 14A\", etc. A question asking for the \"most recent 10-K OR 10-Q\" (or otherwise not committed to one type) should OMIT this field entirely rather than guess \"10-K\" by habit — omitting form_type (along with accession) returns the single most recent filing of ANY type, and a 10-Q is very often more recent than the last 10-K since it files quarterly while the 10-K only files once a year (verified live 2026-09-25, fleet #2450: NTRA's most recent 10-Q was filed 2026-08-07, five months after its 2026-02-27 10-K — passing form_type:\"10-K\" here silently skips the newer filing and the KPI it asked about)."
    • addedInput schema / properties / phrase
      Added value: +{
      +  "description": "Alias for `search`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / search
      Added value: +{
      +  "description": "Find a specific fact instead of paging blind. This is a SUBSTRING match, not a relevance search — pass the exact 2-4 word phrase most likely to appear VERBATIM in the prose (\"tests processed\", \"processed approximately\", \"going concern\"), never a compound of every concept in the question. A phrase that ANDs several unrelated question-words together (\"oncology Signatera revenue test volume\") returns ZERO matches even in the CORRECT filing, because the filing's own sentence never contains all of those words together — verified live 2026-09-25 (fleet #2450) on a real Natera 10-Q that DOES report the exact number asked for: \"Signatera revenue\" and the 4-word compound above both found nothing, while the filing's own wording (\"processed approximately\", \"tests processed\") is what actually appears. When unsure of the filing's exact phrasing, prefer the SHORTEST distinctive 2-3 word fragment of the metric name itself (a unit, a verb+noun like \"processed approximately\") over restating the question. Case-insensitive substring match over the WHOLE document text (or the whole `section` slice, if both are given), run BEFORE max_chars/offset windowing. Returns every matching passage (surrounding context + its own offset in the document) instead of the normal paged `text` — use the returned offsets with a follow-up call (no `search`, `offset` set to one of them) if you need more surrounding text than the passage gives. Zero matches means try again with a SHORTER, more literal phrase before concluding the filing does not disclose it — this is a real answer about wording, not a tool failure. Accepted aliases: `contains`, `find`, `phrase`.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / ticker_or_cik
      Added value: +{
      +  "description": "Alias for `ticker` / `cik` — the single-argument spelling edgar_company_filings and edgar_insider_transactions use. Takes either a ticker or a CIK.",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / ticker / description
      Previous value: -"Filer ticker (e.g. \"ACTU\"). Provide this OR cik."New value: +"Filer ticker (e.g. \"ACTU\"). Provide this OR cik. ONLY pass a ticker you are CERTAIN of — a wrong remembered ticker silently retrieves a DIFFERENT company's filing as a clean success (a \"SpaceX\" question filled with SPCE returns Virgin Galactic's S-1). For a recent IPO or any uncertain ticker, resolve first: edgar_company_filings accepts the company NAME and returns the cik — pass that cik here."
  5. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "form_type": "10-Q",
      +    "section": "liquidity",
      +    "ticker": "ACTU"
      +  },
      +  {
      +    "accession": "0001683168-26-003909",
      +    "cik": "1652935",
      +    "max_chars": 30000,
      +    "section": "going_concern"
      +  }
      +]
  6. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, and the description goes well beyond: pagination via max_chars/offset/next_offset, the read-side `raw_truncated` cap on especially large filings, zero-match `search` semantics as a real answer, word-fallback match mode, section fallback with section_found:false, and the silent-wrong-company ticker hazard. This is unusually rich behavioral disclosure.

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 purpose then progressively narrower guidance, so the most important content reads first. It is long and does duplicate some `search` mechanics already in the schema, but for a 12-parameter tool with alias handling the length is largely earned.

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?

No output schema exists, so the description carries the return-value burden and does so: `text` windowing, `truncated`+`next_offset`, `raw_truncated`, per-match `offset` and `match_mode`. Combined with the mutation-free annotations, nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so baseline is 3; the description lifts it by documenting cross-parameter interactions the schema does not (search runs over the WHOLE document before offset/max_chars windowing, and within the `section` slice when both are given). It adds the phrase-construction guidance ('2-4 word verbatim phrase') and the correct form_type set syntax for '10-K|10-Q'.

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+resource ('AUTHORITATIVE full text of a SEC filing's primary document') with the transformation applied ('HTML stripped to clean plaintext') and the exact content classes it surfaces (going-concern, ATM facilities, MD&A KPIs). It explicitly distinguishes itself from siblings edgar_filing_documents (exhibits) and edgar_company_concept (structured numbers).

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 routing: prefer `search` over paging for a specific fact, use `section` for a single part, and defer to edgar_filing_documents/edgar_company_concept for other needs. It even supplies representative question phrasings and the accession-vs-ticker/form_type selection rule.

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.