Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

edgar_daily_filing_index

Read-only

Retrieve SEC EDGAR filings filed on a specific date, filter by form type, CIK, or company name, and get exact match counts for monitoring and alerting.

Instructions

Per-day sibling of edgar_filing_index. Per-day cross-filer SEC filing index (keyless; www.sec.gov EDGAR daily-index master.YYYYMMDD.idx) — reads ONE calendar day's index (~8K rows), full-scans it, and returns offset-paginated filings matching CLIENT-SIDE filters with the EXACT total. Answers the monitoring/alerting question ('every 8-K filed on 2024-01-03'). Input: date (required ISO YYYY-MM-DD, ≥1994-01-01, not future); optional formType (exact), cik (numeric), companyContains (LITERAL case-insensitive), limit (≤1000, def 100), offset. Returns { found, date, year, quarter, indexFile, returned, totalAvailable, filings:[{ cik, cikPadded, companyName, formType, dateFiled, filename, filingUrl }] }. HONESTY: totalAvailable is EXACT match count — never a page length. The daily-index pervasive-403 model is disambiguated via the quarter's index.json existence oracle, RECENCY-AWARE: a day NEWER than the newest published index → found:false, complete:FALSE, retryable not-yet-disseminated note (NEVER a confident empty); an unlisted day INSIDE the covered range (real weekend/holiday) → found:false, complete:true; a LISTED day whose .idx 403s → honest rate_limited; oracle inconclusive → ambiguous upstream_unavailable. A non-real/future date → invalid_input pre-fetch; non-index/all-malformed body → schema_drift. dateFiled normalized from compact YYYYMMDD to ISO. 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).
dateYesRequired calendar day ISO YYYY-MM-DD (>= 1994-01-01 — EDGAR daily-index begins 1994 Q1). The handler derives year/quarter/yyyymmdd. A malformed / non-real day (2024-02-30, non-leap 2023-02-29) or a FUTURE date is rejected as invalid_input with 0 fetch. TODAY is allowed (its index may not be posted until ~22:00 US-Eastern).
limitNoPage size over the FILTERED, full-scanned matches (1..1000, default 100). Does NOT reduce the download — the whole day is scanned; this only windows the returned rows (page via _meta.pagination.nextOffset).
offsetNo0-based offset into the filtered matches (default 0).
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.4/5.0
Behavior5/5

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

Despite readOnlyHint/openWorldHint annotations already covering the safety profile, the description adds extraordinary behavioral context: full-scan-then-filter semantics, EXACT totalAvailable honesty guarantee, the recency-aware 403 disambiguation model (not-yet-disseminated vs. real weekend/holiday vs. rate_limited vs. ambiguous), the invalid_input/schema_drift error taxonomy, and the CIK-not-UEI keying caveat. An agent can predict edge-case outcomes before calling.

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?

Every sentence carries substantial content and the structure is sensible: purpose → inputs → output shape → honesty guarantee → error model → cross-domain note. It is long, but the length is earned by the genuinely complex 403/oracle behavior. It loses a point for the parameter summary block, which duplicates already-100%-covered schema descriptions without adding value.

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 tool of this complexity with no output schema, the description is remarkably complete: it specifies the full return shape, all three error classes (invalid_input, schema_drift, and the rate-limited/unavailable variants), pagination behavior, date normalization, and a cross-domain caveat. The 100%-detailed input schema handles parameters, and the description handles everything an agent needs to interpret results safely.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter is already richly documented (EXACT case-insensitive formType matching, padCik leading-zero safety, LITERAL contiguous companyContains, limit windowing semantics). The description's parameter summary ('formType (exact)...') largely restates what the schema already says, adding no new meaning, so the baseline of 3 applies.

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 by naming itself 'Per-day sibling of edgar_filing_index' and states exactly what it does: reads ONE calendar day's SEC daily index and returns offset-paginated filings matching client-side filters. The concrete example ('every 8-K filed on 2024-01-03') makes the resource and verb unmistakable, and the sibling differentiation is built into the first phrase.

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 'Per-day sibling of edgar_filing_index' positioning names the alternative and the scoping axis (one day vs. presumably multi-day), and the monitoring/alerting question gives a concrete when-to-use scenario. However, it never explicitly states the inverse rule — 'for date ranges, use edgar_filing_index' — leaving some routing inference to the agent.

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