Skip to main content
Glama
cliwant

mcp-sam-gov

edgar_filing_index

Read-only

Scan a full quarter of SEC EDGAR filings and retrieve paginated results matching filters for form type, CIK, company name, or filing date, with exact total match counts.

Instructions

Bulk sweep — per-filer edgar tools need a CIK. Bulk cross-filer SEC filing index for a quarter (keyless; www.sec.gov EDGAR full-index master.idx). Reads the WHOLE quarter's index (~370K rows: every filer's every filing — CIK|Company|Form|Date|Filename), full-scans it, and returns offset-paginated filings matching CLIENT-SIDE filters with the EXACT total. Input: year (≥1993, ≤current year), quarter (1..4); optional formType (exact, e.g. '8-K'), cik (numeric, leading-zero-safe), companyContains (LITERAL case-insensitive substring), dateFrom/dateTo (ISO YYYY-MM-DD), limit (≤1000, def 100), offset. Returns { year, quarter, indexFile, returned, totalAvailable, filings:[{ cik, cikPadded, companyName, formType, dateFiled, filename, filingUrl }] }. HONESTY: totalAvailable is the EXACT match count over the full quarter scan — never a page length, never a byte-capped subset (SEC ignores HTTP Range). A 0-match result is a genuine EXACT ZERO (complete:true), NOT a truncation. A bounds-valid but unpublished quarter returns HTTP 403 and is surfaced as an AMBIGUOUS error (quarter-not-published OR the 10 req/s rate-block) — never a bare rate-limit and never a fake-empty. A non-index or all-malformed body → schema_drift. A future year / bad quarter → invalid_input pre-fetch. The CURRENT quarter grows daily (totalAvailable is exact as-of-snapshot). filingUrl is a resolvable archive URL. NOTE: EDGAR keys on CIK, NOT SAM UEI/DUNS — no authoritative CIK↔UEI join.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoOptional CLIENT-SIDE filter: numeric SEC CIK (1-10 digits or a number), matched leading-zero-safe via padCik on both sides (so '320193' and '0000320193' match the same filer).
yearYesFiling year (>= 1993 — EDGAR full-index begins 1993 Q1). Must be <= the current year; a future year is rejected as invalid_input with 0 fetch. Path segment.
limitNoPage size over the FILTERED, full-scanned matches (1..1000, default 100). Does NOT reduce the download — the whole quarter is scanned; this only windows the returned rows (page via _meta.pagination.nextOffset).
dateToNoOptional CLIENT-SIDE filter: keep filings whose Date Filed <= this ISO YYYY-MM-DD.
offsetNo0-based offset into the filtered matches (default 0).
quarterYesCalendar quarter 1..4 (path segment QTR<quarter>). A same-year FUTURE quarter returns a well-formed EMPTY result (genuine-empty, complete:true), NOT an error.
dateFromNoOptional CLIENT-SIDE filter: keep filings whose Date Filed >= this ISO YYYY-MM-DD (string compare; the column is already YYYY-MM-DD).
formTypeNoOptional CLIENT-SIDE filter: case-insensitive EXACT match on the Form Type column (e.g. '8-K', '10-K'). '8-K' does NOT match '8-K/A' — pass each amendment variant separately.
companyContainsNoOptional CLIENT-SIDE filter: case-insensitive LITERAL substring on the Company Name column. A multi-word value matches as ONE contiguous string (NOT AND/OR-tokenized).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the burden of behavioral disclosure. It goes far beyond that by revealing the full-quarter scan, exact match totals, truncation honesty, HTTP 403 ambiguity, schema_drift handling, future-quarter empty results, and current-quarter daily growth. No annotation contradiction exists.

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 description is long, but it is densely informative and well organized, front-loading the core purpose before covering filters, return shape, and edge cases. Every major claim addresses a concrete agent decision point. Minor redundancy with the schema descriptions keeps it from a perfect score.

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?

Despite having no output schema, the description explicitly defines the return object shape including year, quarter, indexFile, returned, totalAvailable, and filings with all subfields. It also covers input validation, error ambiguity, pagination semantics, and growth behavior, making the tool fully actionable for an agent.

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%, but the description meaningfully supplements it: filters are explicitly 'CLIENT-SIDE', formType is exact and amendment-aware, companyContains is a literal contiguous substring, and limit does not reduce download size. It also explains leading-zero-safe CIK matching and exact-total semantics, adding real value beyond the input schema.

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-resource pair: a bulk cross-filer SEC filing index for a quarter, sourced from EDGAR's keyless full-index master.idx. It distinguishes itself from per-filer EDGAR tools that require a CIK, and from siblings like edgar_daily_filing_index by emphasizing the whole-quarter bulk sweep. The resource and scope are unambiguous.

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?

The opening line signals when to choose this tool: per-filer EDGAR tools need a CIK, while this is a keyless bulk cross-filer sweep. It also explains the filtering model and error semantics, giving an agent a clear sense of appropriate use. It stops short of explicitly naming competing bulk-index alternatives, but the intended context is well communicated.

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