Skip to main content
Glama

Edgar Filing Exhibit Text

edgar_filing_exhibit_text
Read-onlyIdempotent

Full text of an EXHIBIT attached to a filing — not the filing's own primary document (use edgar_filing_text for that). This is the only way to read an 8-K's Exhibit 99.1/99.2 press release — a quarterly production-and-delivery report, an earnings release, a KPI update — because the 8-K body itself routinely just says "see the attached exhibit" and carries none of the numbers; the figures live in the exhibit document. Pass the filer's ticker or cik plus either an accession (from edgar_company_filings) or a form_type to auto-resolve the latest matching filing (defaults to "8-K" when both accession and form_type are omitted, since that is overwhelmingly when an exhibit holds the operative content). Set exhibit to pick a specific attachment by its SEC-assigned type — "99.1", "99", "10.1" — read off the filing's own document index (case-insensitive, the "EX-" prefix optional); omit it to default to the first EX-99.* exhibit, which is the convention Item 2.02 (earnings) and Item 7.01 (Reg FD) 8-Ks use for a press release. When the requested exhibit is not found (or none exists), the response lists every exhibit actually in the filing under available_exhibits rather than failing silently. For a specific number inside the exhibit, pass search (a short phrase likely to appear verbatim, e.g. "vehicle deliveries", "Megapack", "energy storage") the same way edgar_filing_text does — it scans the whole exhibit and returns matching passages ranked by a nearby figure, with |-separated phrases for more than one fact in one call; a zero-match search is a real answer when raw_truncated is absent (try different wording); with raw_truncated: true it is status: "not_found_within_scanned_portion" and inconclusive and falls back to a word-level match when the exact phrase misses. Without search, the exhibit text is returned paged (max_chars/offset, same convention as edgar_filing_text) since a press release can run several thousand words. Use for "Tesla's Q3 2026 vehicle deliveries and production", "what did $TICKER's earnings press release say about [KPI]", "read the exhibit attached to $TICKER's latest 8-K". Source: U.S. Securities and Exchange Commission, EDGAR filing exhibits (the same primary-source filings edgar_filing_text and edgar_filing_documents read).

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": {
      "search": "vehicle deliveries|energy storage",
      "ticker": "TSLA",
      "accession": "0001628280-26-064366"
    },
    "name": "edgar_filing_exhibit_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
cikNoThe filer's CIK number (e.g. "1318605"). Provide this OR ticker.
findNoAlias for `search`.
filedNoOnly consider filings filed on this date, in this month, or in this year — "2026-10-02", "2026-10", "2026" (US spellings accepted). Pass this whenever the question names a date or quarter ("Tesla's Q3 2026 deliveries report") — Tesla and most large filers submit TWO 8-Ks a quarter (a day-2 production-and-delivery release, then a day-~22 full earnings release), so without a date the newest one is used and it may not be the one the question means.
offsetNoCharacter offset to start from when `search` is not used (default 0). Pass the prior result's next_offset to page forward.
phraseNoAlias for `search`.
searchNoFind a specific fact instead of paging blind — same convention as edgar_filing_text's `search`. A short 2-4 word phrase likely to appear VERBATIM (e.g. "vehicle deliveries", "energy storage deployments"), case-insensitive, scanned over the WHOLE exhibit text before any paging. Falls back to a word-level match (reported as such) when the exact phrase has no match. Separate multiple facts with `|` (e.g. "vehicle deliveries|energy storage deployments") to get both from this one exhibit in one call, each reported independently under `searches[]`.
tickerNoThe filer's ticker (e.g. "TSLA") or company name. Provide this OR cik. Tickers are auto-resolved to CIKs.
exhibitNoWhich exhibit to read, by its SEC-assigned type — "99.1", "EX-99.1", "99", "10.1" (case-insensitive, "EX-" prefix optional). Omit to default to the first EX-99.* exhibit (the press-release convention). If nothing matches, the response lists every exhibit the filing actually has under `available_exhibits` instead of failing with no leads.
containsNoAlias for `search`.
accessionNoOptional SEC accession number of a specific filing, with or without dashes (e.g. "0001628280-26-064366"). Omit it to auto-resolve the latest filing matching form_type (and filed, if given) — the response says `accession_source:"auto_selected"` when this happens.
form_typeNoWhen accession is omitted, the form type of the filing to resolve — "8-K", "10-K", "10-Q", etc., or a `|`-separated set. Defaults to "8-K" when both accession and form_type are omitted, since an exhibit holding the operative content (a press release) is overwhelmingly an 8-K attachment.
max_charsNoMax characters to return in this page when `search` is not used (1000–100000, default 50000). Text past this is available via next_offset.
filing_dateNoAlias for `filed`.
ticker_or_cikNoAlias for `ticker` / `cik` — the single-argument spelling edgar_filing_documents and edgar_filing_text use. Takes either a ticker or a CIK.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile needs no restating. The description adds genuine beyond-annotation context: the missing-exhibit path returns `available_exhibits` instead of failing, `accession_source:"auto_selected"` marks auto-resolution, a zero-match search is only conclusive when `raw_truncated` is absent, and a truncated scan yields `status:"not_found_within_scanned_portion"`. Only the word/phrase fallback ranking and paging defaults are partly repeated from the schema, keeping this just shy of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The critical distinction and the search-vs-page fork are front-loaded, which is the right structure. But it is a dense ~400-word block for one tool, with the `search` contract explained twice (description and schema) and the raw_truncated status codes spelled out at a level of detail that duplicates the parameter docs. It borders on over-specification.

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?

For a 14-parameter, zero-required, read-only tool with no output schema, this covers everything an agent needs: filer identification path, filing resolution and its default, exhibit selection and its default, the search-vs-paging fork, pagination continuation, and the exact failure/fallback shapes. Nothing material is left to inference.

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 the baseline is 3, but the description adds real decision semantics the schema can't: why `filed` matters (Tesla and peers file two 8-Ks a quarter, so the newest may be the wrong one), that omitting both accession and form_type defaults to 8-K, that `exhibit` is case-insensitive with an optional 'EX-' prefix, and that `|`-separated search phrases are reported independently. It does not mention the alias parameters (find/phrase/contains/filing_date/ticker_or_cik), but the schema documents those itself.

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?

Opens with a specific verb+resource and immediately draws the boundary against the nearest sibling: 'Full text of an EXHIBIT attached to a filing — not the filing's own primary document (use edgar_filing_text for that).' It then explains the concrete business case (8-K body says 'see the attached exhibit' while the numbers live in Exhibit 99.1), so an agent knows exactly what this tool returns and why it differs from edgar_filing_text and edgar_filing_documents.

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 routing in both directions: use this for exhibits, use edgar_filing_text for the primary document. It also gives conditional guidance inside the tool — pass `search` for a specific figure, omit it to page, pass `filed` whenever the question names a date or quarter, and omit accession/form_type only when defaulting to 8-K is acceptable. It even supplies example user phrasings that should select this tool.

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.