@pipeworx/mcp-edgar 0.3.12 → 0.3.14

package/README.md

@@ -2,7 +2,7 @@
 
 The Securities and Exchange Commission's filings database. Every public company in the US files here, every filing is timestamped and immutable, and every disclosure (revenue, debt, risk factors, executive compensation, M&A activity, insider trading) is structured for machine retrieval. Free and authoritative.
 
-Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1837+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.
+Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1878+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.
 
 ## Why this matters for AI agents
 
@@ -22,6 +22,8 @@ The two key flows — and the one call that does both:
 
 **5. Product-level revenue.** "How much revenue did Keytruda generate?" → `edgar_product_revenue({ticker_or_cik: "MRK", product_filter: "Keytruda"})`. `edgar_company_concept`/`edgar_company_facts` only expose undimensioned XBRL totals — a product/segment breakdown is tagged with an XBRL dimension (a "Keytruda [Member]"), invisible to those APIs. This reads SEC's own rendered Financial Report of that dimensional data straight out of the revenue-disaggregation note, with a citation (accession, filing date, report URL). With no `form_type` it resolves 10-K, then 20-F, then 40-F, so foreign private issuers work the same way (`edgar_product_revenue({ticker_or_cik: "NVS", product_filter: "Entresto"})` reads Novartis's 20-F); the form actually used comes back as `resolved_form`. Not every filer tags product-level revenue in XBRL — Neurocrine discloses revenue by major customer and United Therapeutics only its recognition policy, and both return an explicit `not_found` rather than an empty array.
 
+**6. Operating KPIs that never reach XBRL (press releases).** "Tesla's Q3 2026 vehicle deliveries and production" / "how much energy storage did Tesla deploy." A company's quarterly production, delivery, and shipment/deployment KPIs are reported in its *press release* — the exhibit attached to an 8-K — not in the structured financial statements, so `edgar_company_concept`/`edgar_company_facts` correctly have nothing to return for them. `edgar_filing_exhibit_text({ticker_or_cik: "TSLA", filed: "2026-10"})` reads the exhibit text directly (the 8-K's OWN primary document typically just says "see the attached exhibit" and carries none of the numbers) and defaults to the EX-99.* attachment, the universal convention for an Item 2.02/7.01 earnings or KPI release. Pass `search` for a specific figure ("vehicle deliveries", "Megapack", "same-store sales") instead of reading the whole release. Generalizes to any US filer's 8-K press release, not just Tesla's.
+
 Both flows are usually preceded by `edgar_ticker_to_cik` or `resolve_entity({type: "company", value: "AAPL"})` to get the canonical 10-digit CIK.
 
 ## Auth
@@ -63,6 +65,7 @@ For insider trades specifically, see the dedicated `insider-trading` pack — it
 - **A filing you did not NAME is a filing we CHOSE, and the envelope now says which (fleet #3319).** `edgar_filing_text` and `edgar_filing_documents` auto-resolve the LATEST filing of `form_type` when `accession` is omitted, and every field then describes that filing as though it had been asked for. Measured live 2026-10-18: a grounded question about "Tesla's September 29 2026 8-K" reached `edgar_filing_text({ticker:"TSLA", form_type:"8-K", search:"credit facility"})`, resolved to the 2026-10-02 8-K — a different filing, 3,061 chars, zero matches — and refused `not_in_source` 5 tries out of 5, while the filing asked about sat one row further down the same index with all three credit tranches in it. So every response carries `accession_source` (`"caller"` | `"auto_selected"`) plus, when we chose, an `auto_selected` block naming what was requested, what was picked, what was read with its exact-match count, and the candidates that were not read. **Pass `filed`** ("2026-09-29", "2026-09", "September 29, 2026") whenever the question names a date; for an 8-K the newest filing is routinely not the one meant. When only a `search` is available, `edgar_filing_text` reads on past a candidate whose text contains no exact match (bounded to 4 documents, exact matches only), and if none match it falls back to the newest WITH a warning that a zero-match result there is inconclusive about the company rather than about that filing.
 - **`edgar_company_filings` used to drop a named `accession` on the floor.** It declared neither `accession` nor `include_primary_text`, so a caller that named one filing got the same unnarrowed list as one that named nothing — HTTP 200, reads as a clean success. That is how the fleet #3319 question finally died: the grounded ladder's last attempt routed here with `{accession:"0001628280-26-063820", ticker:"TSLA", include_primary_text:true}` (AE `blob12` — the router had already resolved the right 8-K) and the extraction model received a generic 10-row filings list carrying no facility amounts. Both arguments are real now, plus `filed`; a one-row result says so in `narrowed_note`, and an accession the filer never filed is a loud `not_found:` error rather than an unfiltered list.
 - **`fiscal_year` and `fiscal_period` are filters AND response fields.** They are the names of two fields on every row in `values`, and the description's advice to "match the requested fiscal_year and fiscal_period" used to make argument-fillers send them as arguments, where they were undeclared and silently dropped — so the caller got all 89-230 reported periods back with nothing saying its filter had been ignored. They are now real optional filters: pass either or both and `values`/`latest` come back scoped to it, with a `period_filter` block echoing what was applied. An unmatched filter returns NO rows plus the list of fiscal years and periods the filer actually reports, rather than falling back to every period — `fiscal_year` is the filer's OWN label (NVDA's FY2024 ended January 2024), so a caller thinking in calendar years needs to see the labels rather than be handed a neighbouring year's number.
+- **`edgar_search_filings` ignores `size`/`limit` upstream, and silently drops a one-sided date filter, if you don't account for both (fleet #3251).** EDGAR's search index (`efts.sec.gov`) returns a FIXED page of up to 100 hits no matter what `size` is requested — verified live — so the tool now trims to the caller's `limit` itself and reports `total_hits` (the true match count) separately from `returned`; a `note` says so whenever the fixed page held more than was asked for. Separately, `dateRange=custom` with only one of `startdt`/`enddt` set is silently IGNORED by efts (the filter never applies and filings from 2001 onward appear) — passing only `start_date` or only `end_date` now defaults the other end (EDGAR full-text coverage's floor, 2001-01-01, or today) rather than losing the filter. Pass `entity` (ticker, company name, or CIK; aliases `ticker_or_cik`/`cik`/`ticker`) to scope the market-wide search to one filer — resolved the same way `edgar_ticker_to_cik` resolves a company, with the delisted/non-listed fallback for filers absent from `company_tickers.json`. Because efts's response cache is keyed on `q`/dates/`forms`/`from` but NOT on `ciks`/`entityName` (`reference_efts_cache_key_leak`, fleet #619 — a `ciks`-filtered request can be served a cached UNFILTERED result as a clean 200), an entity filter appends a negated cache-busting token to `q` and every row is re-checked client-side against the requested CIK; a dropped mismatch is reported as `entity_filter_guard_dropped` rather than silently vanishing. The tool returns no text snippet — EDGAR's index has none — so chain a result's `accession` into `edgar_filing_text` with `search` set to the query for the matching passage, instead of this tool fetching every hit's document on your behalf (SEC rate-limits the whole fleet by one shared egress IP).
 
 ## Quick Start
 
@@ -108,7 +111,7 @@ directly, instead of just this one's:
 }
 ```
 
-Both URLs reach the same gateway and the same 1837+ data sources. The
+Both URLs reach the same gateway and the same 1878+ data sources. The
 only difference is which pack's tools are listed **directly**; `ask_pipeworx`
 reaches all of them from either one.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pipeworx/mcp-edgar",
-  "version": "0.3.12",
+  "version": "0.3.14",
   "description": "EDGAR MCP — SEC EDGAR public APIs (free, no auth)",
   "type": "module",
   "main": "src/index.ts",
@@ -26,7 +26,7 @@
     "@cloudflare/workers-types": "^4.20260405.1"
   },
   "pipeworx": {
-    "sourceHash": "v1-91337e87e2be0647d629be7b6c821ab5c696b671f31a18ead8dedd775cd40966",
-    "sourceCommit": "0f33463aa47677f38e4f177a4b4a7160dd80819f"
+    "sourceHash": "v1-22732e078cc175e931b642bd5804d7ba1b2610fd58415c9f8811ec32ff5939f5",
+    "sourceCommit": "29fb434ca65fe0f61191f19c3502f583f5fb99d7"
   }
 }

package/server.json

@@ -3,7 +3,7 @@
   "name": "io.github.pipeworx-io/edgar",
   "title": "Edgar",
   "description": "EDGAR MCP — SEC EDGAR public APIs (free, no auth)",
-  "version": "0.3.12",
+  "version": "0.3.14",
   "websiteUrl": "https://pipeworx.io/packs/edgar",
   "repository": {
     "url": "https://github.com/pipeworx-io/mcp-edgar",