Skip to main content
Glama
Sign In
fairquery-edgar

fairquery-edgar

by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List the documents and exhibits of one SEC filing

edgar_get_filing_index
Read-onlyIdempotent

List every file in one SEC EDGAR filing index, including exhibits, XBRL data, and header facts, so you can locate and fetch a specific attachment.

Instructions

List every file of ONE SEC filing from its EDGAR filing index page: primary document, exhibits (EX-21 subsidiaries, EX-99.1 press release, ...) and XBRL data files, with SEC document type, description, size and a direct URL, plus filing header facts (form, filing date, acceptance time, period of report, 8-K items, filers). Use when you need an exhibit or attachment rather than the primary document ("Apple's list of subsidiaries", "the press release attached to this 8-K"), or the 8-K item numbers of a filing; then pass a row's url to edgar_get_filing_document. Behavior: one GET to the {accession}-index.htm page on www.sec.gov (throttled to <=5 requests/s, shared with the other edgar_* tools); company resolution may add one cached ticker-map request. RETURNS: one "filing_document" row per file, in SEC sequence order (documents first, then data files); meta holds the filing header. Errors: INVALID_INPUT, INVALID_URL, COMPANY_NOT_FOUND, NOT_FOUND (no such filing for that CIK), SEC_FETCH_FAILED (retryable). WHEN NOT TO USE: to find filings use edgar_list_filings first; to read a document's text use edgar_get_filing_document; for financial values use edgar_get_company_facts. COST: free - direct sec.gov requests from this MCP server, no APIFY_TOKEN, no Apify billing. PARAMETERS: give EITHER indexUrl (index_url from edgar_list_filings; wins if present) OR company + accessionNumber (both required together, else INVALID_INPUT). company only locates the filing folder: any CIK that filed or co-filed the accession works. docTypes filters rows by exact, case-insensitive SEC document type ("EX-21" does not match "EX-21.1"; use prefix matching yourself if needed) before paging; meta.document_count is SEC's own count and ignores the filter. doc_type of XBRL data files is e.g. "EX-101.SCH" or "XML". url points to the raw file (the inline-XBRL viewer prefix is removed), so it can be passed to edgar_get_filing_document as documentUrl. EXAMPLE: {"company":"AAPL","accessionNumber":"0000320193-24-000123","docTypes":["EX-21.1"]} -> 1 row {"doc_type":"EX-21.1","document":"a10-kexhibit21109282024.htm","url":"https://www.sec.gov/Archives/edgar/data/320193/000032019324000123/a10-kexhibit21109282024.htm"}, meta.form "10-K", meta.period_of_report "2024-09-28".

Input Schema

NameRequiredDescriptionDefault
limitNoOptional page size: items to return, integer 1-500 (default 100). Example: 10
offsetNoOptional zero-based number of items to skip, integer >= 0 (default 0); pass nextOffset from the previous response, e.g. 20
companyNoOptional, 1-200 chars; required together with accessionNumber when indexUrl is omitted. Ticker ("AAPL"), CIK ("320193") or registrant-name fragment ("Apple"; the first SEC ticker-map match is used).
docTypesNoOptional, default omitted = all files. 1-50 exact SEC document types, case-insensitive. Example: ["EX-21.1","EX-99.1"]
indexUrlNoOptional (alternative to company + accessionNumber). index_url from edgar_list_filings; must start with https://www.sec.gov/Archives/edgar/data/ and end with -index.htm or -index.html (else INVALID_URL). Example: https://www.sec.gov/Archives/edgar/data/320193/000032019324000123/0000320193-24-000123-index.htm
accessionNumberNoOptional; required together with company when indexUrl is omitted. Format 10-2-6 digits with optional dashes (pattern ^\d{10}-?\d{2}-?\d{6}$), e.g. "0000320193-24-000123" or "000032019324000123"

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context (company, source_url, ...)
countYesNumber of items in this page
itemsYesResult rows for this page
totalYesTotal items matching the filters (before paging)
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds behavior beyond them: one GET to the -index.htm page, throttling to <=5 req/s shared across edgar_* tools, a possible cached ticker-map request during company resolution, row ordering, enumerated error codes with the retryable one flagged, and an explicit cost statement (no APIFY_TOKEN/billing).

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 purpose, then labeled blocks (Behavior, RETURNS, WHEN NOT TO USE, COST, PARAMETERS, EXAMPLE) so an agent can skim to the needed section. It is dense and longer than average, but almost every clause carries non-redundant information; only the example at the end is somewhat expendable.

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 six-parameter, zero-required tool with an output schema, this leaves nothing an agent needs unanswered: invocation modes, filter caveats, error taxonomy, throttling, and the exact example response shape (including meta.form and meta.period_of_report) are all present.

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 coverage is 100%, yet the description adds real semantics beyond it: indexUrl wins over company+accessionNumber, both must be supplied together else INVALID_INPUT, company only locates the filing folder so any co-filer CIK works, docTypes matching is exact so 'EX-21' will not match 'EX-21.1', the filter is applied before paging and meta.document_count ignores it, and url is stripped of the inline-XBRL viewer prefix.

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 ('List every file of ONE SEC filing from its EDGAR filing index page') and enumerates the row types (primary document, exhibits, XBRL data files) plus the header facts returned. It is immediately distinguishable from edgar_get_filing_document, which reads a single document's text, and from edgar_list_filings, which finds filings.

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 concrete positive triggers ('when you need an exhibit or attachment rather than the primary document', with quoted examples) and an explicit WHEN NOT TO USE block routing to edgar_list_filings, edgar_get_filing_document and edgar_get_company_facts. The handoff ('pass a row's url to edgar_get_filing_document') closes the loop.

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

Deploy Server

Other Tools