protogrid

Search / io.github.pipeworx-io/edgar

Edgar

R0· no sign-in

EDGAR MCP — SEC EDGAR public APIs (free, no auth)

v0.3.12 · active · repository · website · descriptor JSON · versions

An agent can connect right now, no human step.Remote endpoint, no authentication, reachable on the last probe.
Quality–not scored
Trust97of 100
Uptime, 30 days97%
Latency p5034 ms

Connect

8 clients · secrets stay placeholders
{
  "mcpServers": {
    "edgar": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/edgar/mcp"
    }
  }
}
claude mcp add --transport http edgar https://gateway.pipeworx.io/edgar/mcp
[mcp_servers.edgar]
url = "https://gateway.pipeworx.io/edgar/mcp"
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "edgar": {
      "type": "remote",
      "url": "https://gateway.pipeworx.io/edgar/mcp",
      "enabled": true
    }
  }
}
{
  "mcpServers": {
    "edgar": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/edgar/mcp"
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=edgar&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vZ2F0ZXdheS5waXBld29yeC5pby9lZGdhci9tY3AifQ%3D%3D"
}
{
  "servers": {
    "edgar": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/edgar/mcp"
    }
  }
}
{
  "mcpServers": {
    "edgar": {
      "httpUrl": "https://gateway.pipeworx.io/edgar/mcp"
    }
  }
}
extensions:
  "edgar":
    enabled: true
    name: "edgar"
    type: streamable_http
    uri: "https://gateway.pipeworx.io/edgar/mcp"
    timeout: 300

Quality – / 100not scored

Not scored: fewer than three checks apply, usually because no remote answered a credential-free probe or the server is a local package.

protocol75 · weight 25
  • warn
    protocol.modernnewest supported version is 2025-03-26; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
  • n/a
    protocol.statelessonly applies to 2026-07-28 servers
  • pass
    protocol.transportstreamable HTTP
  • n/a
    protocol.list_ttlonly applies to 2026-07-28 servers
authorizationn/a · weight 15
  • n/a
    auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
  • n/a
    auth.secret_in_urlno templated URL
tool hygienen/a · weight 30
  • n/a
    tools.descriptions, tools.description_length, tools.schemas, tools.annotations, tools.directory_hints, tools.token_cost, tools.api_dumptool list unknown (behind auth, not probed, or empty)
stabilityn/a · weight 15
  • n/a
    stability.changes, stability.rug_pulltool list unknown
dependenciesn/a · weight 15
  • n/a
    deps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI package

Tool list unknown · tools last changed 2026-10-09 · checked 2026-10-20 09:31 UTC

Tool changes

  • deep_researchremoved

    ACCOUNT REQUIRED (free — sign in via GitHub at https://pipeworx.io/signup; depth:"thorough" needs a paid plan). If you are not signed in, use ask_pipeworx instead — it works on every tier. Grounded multi-source research across Pipeworx's 1739 STRUCTURED data sources (SEC filings, FRED/BLS economics, FDA, USPTO patents, markets, science, government records, etc.) in ONE call — this is NOT open-web search. Decomposes your question into focused facets, routes each to the right one of 6,626 tools IN PARALLEL, and returns a findings packet: verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding, with explicit gaps[] for facets the data couldn't answer (never invented). Best for broad/multi-part questions over structured data ("compare X and Y's regulatory + financial exposure", "research the filings + market picture for ACME"). For a single lookup use ask_pipeworx (one LLM call, not many). For BREAKING or colloquial CURRENT-NEWS / "what's the world saying about X" topics, prefer ask_pipeworx — it routes to live news APIs and the *-news-feeds packs; deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog. Second-hop iteration: depth:"standard" re-angles unanswered gaps (gap recovery); depth:"thorough" additionally chases the best leads from the first pass — so multi-step questions resolve in one call. Every finding carries a `hop` field and a citation_uri — a resolvable pipeworx:// record URI, present only when the source emits one that resources/read can actually serve, so a citation you get back is always fetchable. "standard" and "thorough" also return contradictions[] flagging findings that disagree. Large records are semantically excerpted to the passages relevant to each facet (not head-truncated), so answers deep in a long filing/series aren't missed. Expect 15-60s (thorough with its follow-up + contradiction pass: up to ~90s).

  • resolution_auditremoved

    Extract the settlement clause of a single Polymarket or Kalshi market: who publishes the settling number (source), the clock time + timezone it is taken at, the precision of the computation (e.g. "1-minute candle close" vs "60-second trailing average" vs "election outcome"), the evidence standard (official_source | consensus_reporting | any_credible_report | unspecified), and void_handling (cancellation/postponement settlement — reused verbatim from bet_research's cancellation_rule detector, not re-derived). Parses Polymarket's `description` field (fetched via polymarket_market) or Kalshi's `rules_primary` + `rules_secondary` fields (fetched via kalshi_market) with regex + a small vocabulary — no LLM pass, so an unusual clause reports confidence:"low" rather than a guess. Pass `market` as a Polymarket slug/URL or a Kalshi market ticker (e.g. "KXBTCD-26SEP1317-T66999.99"); a Kalshi EVENT ticker (e.g. "KXBTCD-26SEP1317") also works — it picks one representative market under that event, since the settlement mechanism is normally shared across all strikes/legs in one event. Use this before treating a polymarket_kalshi_spread row as a real arbitrage: two ladders that look alike can settle on different sources, at different times, with different precision — this tool is how you check. Pair with resolution_diff to compare two markets directly. KNOWN GAP: idiosyncratic phrasing that doesn't match the vocabulary returns confidence:"low" and evidence_standard:"unspecified" rather than an LLM-guessed answer.

  • polymarket_edgesremoved

    Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price. Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets. FIVE MODEL FAMILIES grouped into three response segments under by_segment: (1) MODEL_DRIVEN — crypto_price (lognormal barrier from 90d FRED log-returns) and news_momentum (GDELT 7d/21d article-volume ratio, soft signal w/ halved Kelly). (2) STRUCTURAL_ARBITRAGE — partition_overround on mutually-exclusive events; per-leg favorite-longshot bias correction with per-sport α (tennis 1.02, soccer 1.10, MMA 1.15, default 1.0); placeholder-slug filter drops will-person-X / will-team-Y / will-manager-Z / will-someone-else- backstops; partitions with >20% placeholder fraction skipped entirely. (3) CONCENTRATED_LONGSHOT — basket trade when one leg ≥75% AND ≥2 longshots ≤8% AND portfolio return ≥25:1; rare-by-design (gates relaxed Run 8 from prior 85%/5%/50:1). EVERY OPPORTUNITY carries edge_pp_net (net of slippage AND Polymarket's own taker fee — fees_pp_applied itemises the fee component; see fees.ts for the published per-category schedule), kelly_fraction + kelly_fraction_half (capped at 0.25), market.liquidity, market.spread_pp, market.volume, plus a 24h-move warning ("Market moved X.Xpp in 24h") when the recent move alone exceeds the edge — your edge may already be in the price. TRADEABLE-EDGE KNOBS: min_liquidity / max_spread_pp drop opportunities where edge isn't realizable; min_partition_leg_kelly filters partitions by best per-leg Kelly. RESPONSE TOP-LEVEL: by_segment{model_driven,structural_arbitrage,concentrated_longshot}, fed_candidates/fed_note (Fed bets surface here, excluded from ranking — 1m-T vs EFFR signal is unreliable at meeting-month horizons without paid OIS/SOFR-futures data), and _diagnostics{concentrated_longshot:{...funnel counters},category_counts,filter_skips} so callers can see WHY a segment is empty (top-N stale, all candidates failed gates, knob dropped them). Cached 1h at the KV level keyed on all knobs.

  • entity_profileremoved

    "Tell me about X" / "research Acme" / "brief me on Tesla" / "what does Apple do" / "company profile for Microsoft" / "give me the rundown on NVDA" / "everything you know about $TICKER" — full cross-source profile of a US public company in ONE parallel call. ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view. Fans out across SEC EDGAR, XBRL, USPTO patents, federal contracts (USAspending), FDA-licensed biologics (Purple Book), H-1B hiring (DOL LCA), news and GLEIF, and returns: cik + company_name (+ resolved_from/resolved_to when `value` was a name); recent_filings (up to 5 with pipeworx://edgar/company/{cik}/filings/{accession} URIs); fundamentals (LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted period_end DESC); patents (USPTO PatentsView API sunset May 2025 — soft-fails until reactivated); federal_contracts (USAspending awards where the company is the recipient); fda_products (FDA-licensed biologics — vaccines, cell/gene therapies — from the Purple Book; a company with only small-molecule/generic drugs will show none here, that is expected, not a failure); hiring (H-1B sponsorship volume + salary range from DOL LCA filings); recent news mentions via GDELT→GNews fallback; LEI via GLEIF. `sources_used` / `sources_failed` say which of these actually returned data for THIS company — an empty section is a real "no data", not a bug. `sources_skipped` is the third state: a leg we deliberately did NOT run, each entry carrying a `reason` token and a plain-English `detail` (the Purple Book is skipped for a filer SEC classifies outside the life-science SIC bands, since it lists only 351(a)/(k) biologics licence holders). Pass a ticker ("AAPL"), zero-padded CIK ("0000320193"), OR a company name ("Moderna") — names now resolve via SEC EDGAR's company-name match; a private company (no CIK/ticker) returns resolved:false with an explicit `notes` line, not a bare failure. `type` accepts "company" or "ticker" interchangeably — both take the same `value` shapes above.

  • list_subscriptionsremoved

    List the caller's active subscriptions. Returns id, type, params, created_at, last_fired_at, fire_count for each. Use this to review what you're monitoring before adding more or to find an id to cancel.

  • ask_pipeworx_groundedremoved

    Hallucination-resistant answer mode for high-stakes reads. Same routing as ask_pipeworx — picks the right tool from 6,626 across 1739 sources, fills arguments, fetches the data — then EXTRACTS the answer using ONLY what the tool result contains. Returns {answer, evidence (verbatim quote), confidence, source, fetched_at, refusal_reason:null} on success, OR an explicit refusal {answer:null, refusal_reason:"not_in_source"|"no_tool_match"|"tool_error"|"data_truncated"|"llm_error"} when the data doesn't directly answer. Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts (financial verdicts, legal claims, medical lookups, public statements). Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.

  • edgar_filing_textremoved

    AUTHORITATIVE full text of a SEC filing's primary document (10-K / 10-Q / 8-K body), HTML stripped to clean plaintext — the source for disclosures that live in prose, not XBRL: going-concern language, ATM / at-the-market equity facilities, committed-equity share caps, public-float figures, subsequent events, the liquidity footnote, and MD&A KPIs XBRL never tags (test volume, units shipped, subscriber counts, same-store sales). Pass an accession (from edgar_search_filings / edgar_company_filings) plus the filer's ticker or CIK; OR omit accession and pass ticker + form_type to auto-resolve the latest matching filing. **For a specific fact inside a long filing, pass `search`** (a word or exact phrase, e.g. "tests processed" or "processed approximately") instead of paging blind — it scans the WHOLE document (before any offset/max_chars windowing) and returns every matching passage with surrounding context and its own `offset` in the document, so a KPI ~100k characters in is found in one call instead of paging through `max_chars` windows by hand. A zero-match `search` is a real answer (the filing does not use that exact wording) — retry with a shorter or different phrase rather than assuming the tool failed. **For a question asking two facts from the same filing** ("revenue and test volume in the latest 10-Q"), pass `search` as `|`-separated phrases (e.g. "revenue|tests processed") to get both in this one call under `searches[]` — and when a phrase names a financial total (revenue, net income, EPS, ...), the matching XBRL figure for this exact accession comes back under `xbrl` even if that total never appears as an absolute number in the prose (common: filings often state only the growth delta/percentage in text). Optionally set `section` to return just one part (going_concern | liquidity | capital_resources | subsequent_events); `search` runs within that slice when both are given. Large docs (a 10-Q is ~100k+ chars of text) are PAGED, not spilled, when `search` is not used: the result caps at `max_chars` (default 50000) from `offset`, and returns `truncated` + `next_offset` — pass next_offset back as `offset` to read the next window. An especially large filing (e.g. an S-1 with heavy inline-XBRL tagging can exceed 10MB of raw HTML) is also capped on the READ side — the response sets `raw_truncated:true` when only the first portion of the document was read at all, which bounds how far `offset` can page (and how far `search` can scan) and can make a late section or search term come back not-found even though it exists further in. Use for "does $TICKER disclose substantial doubt / going concern", "what ATM facility does $TICKER have", "read the liquidity section of the latest 10-Q", "how many tests did $TICKER process this quarter". For the list of documents/exhibits in a filing use edgar_filing_documents; for structured financial numbers use edgar_company_concept.

  • edgar_product_revenueremoved

    PRODUCT-LEVEL or segment-level revenue as STRUCTURED data — e.g. "how much revenue did Keytruda generate", "AAPL revenue by product line". Regular XBRL tools (edgar_company_concept, edgar_company_facts) only expose UNDIMENSIONED totals; a filer's product/segment breakdown is tagged with an XBRL dimension (e.g. a "Keytruda [Member]"), which those APIs cannot see no matter which concept is requested. This tool reads SEC's own standardized "Financial Report" rendering of that dimensional data straight out of the annual or quarterly segment-reporting / revenue-disaggregation note — 10-K and 10-Q for US filers, 20-F for foreign private issuers (Novartis, AstraZeneca, GSK, Sanofi, Novo Nordisk, Takeda) and 40-F for Canadian MJDS filers, resolved automatically and reported back as `resolved_form` — the same note human analysts read, but pre-parsed into rows. Pass `product_filter` (case-insensitive substring, matched against the dimension breadcrumb, e.g. "Keytruda") to get just one product/segment instead of the whole table. Every result carries a citation (accession, filing date, exact report + URL it came from). Not every filer discloses product-level revenue in XBRL, and a small fraction use a non-standard table layout this parser can't read — both are reported as an explicit status rather than a silent empty array, with a fallback to edgar_filing_text for the prose note.

  • edgar_companies_by_sicremoved

    AUTHORITATIVE peer / competitor lookup: find every SEC filer classified under one SIC (Standard Industrial Classification) industry code. PREFER OVER WEB SEARCH for "who are $COMPANY's public competitors/peers", "list companies in <industry>", "which filers are in SIC <code>". Pass EITHER `sic` directly (a 2-4 digit code, e.g. "3571" = Electronic Computers) OR `ticker_or_cik` for a company whose own SIC should be looked up first and then used to find its peers (self excluded by default). Returns each peer's CIK, and ticker + company_name when the filer has a listed ticker — results are sorted so currently-listed peers come first, since an SIC bucket covers every filer that EVER filed the form (many delisted/defunct); unlisted registrants still appear after them with ticker:null rather than being dropped. Source: SEC EDGAR company-search (browse-edgar), filtered to filers who have filed the given form_type (default "10-K", i.e. active public reporters — omitting this filter is unreliable upstream). Note: SIC is a broad, sometimes dated bucket assigned once at registration — treat this as a peer-set STARTING POINT, not a precise competitor list.

  • filer_to_sponsorsremoved

    The REVERSE of sponsor_to_filer: given a US-listed public FILER (parent company), list its operating subsidiaries as disclosed in Exhibit 21 of its most recent 10-K (Item 601(b)(21) — "significant subsidiaries"). Built for the same trial-sponsor/entity-resolution join, run the other direction: instead of ~10 calls guessing candidate subsidiary names and confirming each via sponsor_to_filer, get the parent's full disclosed subsidiary list (with jurisdiction of incorporation) in one call, straight from SEC — e.g. Merck (MRK/CIK 310158) -> "Merck Sharp & Dohme LLC" among hundreds of others. Pass `name_filter` (case-insensitive substring) to check whether a specific candidate name is among the subsidiaries without reading the whole list. Every result carries provenance (accession number, filing date, exhibit URL) so the join is auditable. Smaller filers or ones with no significant subsidiaries can genuinely have no Exhibit 21 — status distinguishes that from a lookup failure. Foreign private issuers (20-F filers) are not yet covered.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 97 / 100

provenance90
liveness99
freshness100
hygiene100

+repository +namespace-matches-repo +website +reachable +uptime-97% +updated-1d-ago

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Endpoints

remoteauthreachableuptime 30dp50protocollast ok
https://gateway.pipeworx.io/edgar/mcp streamable-httpnoneyes97%34 ms2025-03-262026-10-20

Tools (0)

No tools observed. Tools appear once a credential-free probe can list them.

Schemas: list_tools.

Similar MCP servers

More from io.github.pipeworx-io

And 1,855 more from this publisher.

Official server.json
{
  "name": "io.github.pipeworx-io/edgar",
  "title": "Edgar",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://gateway.pipeworx.io/edgar/mcp",
      "type": "streamable-http"
    }
  ],
  "version": "0.3.12",
  "repository": {
    "url": "https://github.com/pipeworx-io/mcp-edgar",
    "source": "github"
  },
  "websiteUrl": "https://pipeworx.io/packs/edgar",
  "description": "EDGAR MCP — SEC EDGAR public APIs (free, no auth)"
}