de en es ko ru zh

toolstem-sec-mcp-server

Name: toolstem-sec-mcp-server
Author: toolstem

Official

by toolstem

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

SEC EDGAR MCP-Server – Insider-Signale, 13F-Bestände & Einreichungs-Intelligence

SEC EDGAR-Intelligence für KI-Agenten. Fünf Tools, die die wichtigen Fragen beantworten: Insider-Handelssignale (Form 4), SC 13D-Indikatoren für aktivistische Risiken, Einreichungsgeschwindigkeit von 10-K/8-K, Schweregrad wesentlicher 8-K-Ereignisse (ROT/GELB/GRÜN) und Vergleiche von Offenlegungen zwischen mehreren Unternehmen – alles als strukturiertes JSON direkt von SEC EDGAR. Kein API-Schlüssel erforderlich.

Warum gibt es das?

Bestehende SEC-Datentools liefern Agenten paginierte Einreichungslisten und rohes XML. Agenten müssen diese dann selbst parsen, klassifizieren und Signale ableiten – was wertvolles Kontextfenster für bürokratische Extraktion statt für Analysen verschwendet.

Der Toolstem SEC MCP-Server berechnet fünf hochwertige Signale direkt aus der öffentlichen Submissions-API von SEC EDGAR und liefert strukturiertes, für Agenten sofort nutzbares JSON. Keine Drittanbieter, keine API-Schlüssel, keine Gebühren pro Symbol – nur die maßgebliche Quelle von SEC EDGAR mit einem Ratenbegrenzer, der Sie von deren Sperrliste fernhält.

Related MCP server: northbridge-diligence

Die fünf Tools

1. `get_company_filings_summary`

Überblick über die Einreichungsaktivität eines Unternehmens: letzte 20 Einreichungen + berechnete Signale.

Signal	Beschreibung
`filing_velocity`	`ACCELERATING` / `NORMAL` / `SLOWING` im Vergleich zum gleitenden 365-Tage-Durchschnitt
`material_event_count_90d`	Anzahl der 8-K-Einreichungen in den letzten 90 Tagen
`disclosure_volume_trend`	`RISING` / `STABLE` / `FALLING` basierend auf dem Vergleich der 10-K-Größe
`latest_form_types`	Einzigartige Formulararten, die in den letzten 90 Tagen eingereicht wurden

Beispielausgabe (gekürzt):

{
  "ticker": "AAPL",
  "cik": "0000320193",
  "company_name": "Apple Inc.",
  "signals": {
    "filing_velocity": "NORMAL",
    "material_event_count_90d": 4,
    "disclosure_volume_trend": "RISING",
    "latest_form_types": ["8-K", "4", "DEF 14A"]
  },
  "meta": { "source": "sec_edgar_direct", "data_delay": "live" }
}

2. `get_insider_signal`

Untersucht die Insider-Einreichungsaktivität (Form 3/4/4A) innerhalb eines Rückblickzeitraums.

Liefert: recent_insider_filings (Zugriffsnummern + SEC-URLs für Formulare 3/4/4A), lookback_days und Anzahlen.

Hinweis zu v0.1: Wenn mindestens eine Form 3/4/4A-Einreichung im Rückblickzeitraum existiert, ist insider_signal null ("Richtung unbekannt – Form 4 XML-Parsing kommt in v0.2"). Wenn keine Insider-Einreichungen im Zeitraum existieren, ist insider_signal "NEUTRAL" ("bestätigte Abwesenheit von Aktivität"). buy_count und sell_count sind in v0.1 0.

Beispielausgabe (gekürzt):

{
  "ticker": "MSFT",
  "cik": "0000789019",
  "company_name": "MICROSOFT CORP",
  "lookback_days": 90,
  "insider_signal": null,
  "net_transaction_count": 0,
  "buy_count": 0,
  "sell_count": 0,
  "recent_insider_filings": [
    {
      "accession_number": "0001127602-26-001234",
      "filing_date": "2026-04-15",
      "sec_url": "https://www.sec.gov/Archives/edgar/data/789019/000112760226001234/0001127602-26-001234-index.htm"
    }
  ],
  "meta": { "source": "sec_edgar_direct", "data_delay": "live" }
}

3. `get_institutional_signal`

Untersucht auf aktivistische Investorenaktivität mittels SC 13D / 13D/A-Einreichungen.

Feld	Beschreibung
`activist_risk_flag`	`true`, wenn in den letzten 365 Tagen ein SC 13D oder 13D/A eingereicht wurde
`recent_13d_filings`	Liste der 13D-Einreichungen mit Formularart, Datum und SEC-URL

Hinweis zu v0.1: institutional_signal und recent_13f_count sind null/0. Quartalsweises 13F XBRL/XML-Parsing (ACCUMULATING / HOLDING / DISTRIBUTING) kommt in v0.2.

Beispielausgabe (gekürzt):

{
  "ticker": "NVDA",
  "cik": "0001045810",
  "company_name": "NVIDIA CORP",
  "quarters_back": 4,
  "institutional_signal": null,
  "recent_13f_count": 0,
  "activist_risk_flag": false,
  "recent_13d_filings": [],
  "meta": { "source": "sec_edgar_direct", "data_delay": "live" }
}

4. `get_material_events_digest` ⚡ Premium ($0,50)

Nach Schweregrad sortierte Zusammenfassung aller 8-K- und 8-K/A-Einreichungen innerhalb eines Rückblickzeitraums. Ordnet jeden Item-Code einem klar verständlichen Label und einer Schweregradbewertung zu.

Schweregrad	Beispiele
🔴 ROT	Cybersicherheitsvorfall (1.05), Korrektur (4.02), Insolvenz (1.03), Delisting (3.01)
🟡 GELB	Übernahme (2.01), neue Schulden (2.03), Ausscheiden von Führungskräften (5.02)
🟢 GRÜN	Ergebnisveröffentlichung (2.02), Reg FD (7.01), Aktionärsabstimmung (5.07)

Liefert: events[] (sortiert nach Aktualität), redflag_count, category_counts.

Beispielausgabe (gekürzt):

{
  "ticker": "TSLA",
  "cik": "0001318605",
  "company_name": "Tesla, Inc.",
  "lookback_days": 180,
  "redflag_count": 1,
  "category_counts": { "RED": 1, "YELLOW": 3, "GREEN": 7 },
  "events": [
    {
      "accession_number": "0001628280-26-005678",
      "filing_date": "2026-04-10",
      "form": "8-K",
      "items": [
        { "code": "4.02", "label": "Non-Reliance on Previously Issued Financial Statements", "category": "financial", "severity": "RED" }
      ],
      "sec_url": "https://www.sec.gov/Archives/edgar/data/1318605/000162828026005678/0001628280-26-005678-index.htm"
    }
  ],
  "meta": { "source": "sec_edgar_direct", "data_delay": "live" }
}

5. `compare_disclosure_signals`

Direkter Vergleich von 2-5 Unternehmen anhand aller wichtigen Offenlegungssignale. Alle Abfragen laufen parallel.

Liefert pro Unternehmen: filing_velocity, material_event_count_90d, redflag_count_365d, activist_risk_flag, last_filing_date.

Liefert Gewinner (als CIKs, nicht Ticker – bitte mit dem companies[]-Array abgleichen): quietest_disclosure, most_active, most_redflags, activist_targets.

Beispielausgabe (gekürzt):

{
  "companies": [
    {
      "ticker": "AAPL",
      "cik": "0000320193",
      "filing_velocity": "NORMAL",
      "material_event_count_90d": 4,
      "redflag_count_365d": 0,
      "activist_risk_flag": false,
      "last_filing_date": "2026-04-25"
    },
    {
      "ticker": "MSFT",
      "cik": "0000789019",
      "filing_velocity": "ACCELERATING",
      "material_event_count_90d": 7,
      "redflag_count_365d": 0,
      "activist_risk_flag": false,
      "last_filing_date": "2026-04-26"
    }
  ],
  "winners": {
    "quietest_disclosure": "0000320193",
    "most_active": "0000789019",
    "most_redflags": null,
    "activist_targets": []
  },
  "meta": { "source": "sec_edgar_direct", "data_delay": "live" }
}

Preisgestaltung

Alle Aufrufe werden auf Ergebnisbasis über das Pay-Per-Event (PPE)-System von Apify abgerechnet. Die Abrechnung erfolgt zum Zeitpunkt, an dem das Tool sein Ergebnis zurückgibt.

Tool	Stufe	Preis pro Aufruf
`get_company_filings_summary`	Günstig	$0,005
`get_insider_signal`	Standard	$0,05
`get_institutional_signal`	Standard	$0,05
`get_material_events_digest`	Premium	$0,50
`compare_disclosure_signals`	Premium	$0,50

Standard-Demo-Abfragen (Actor-Ausführungen ohne tool-Eingabe) sind kostenlos – sie liefern ein zwischengespeichertes Ergebnis und lösen keine PPE-Gebühr aus. Dies hält Verzeichnis-Gesundheitsprüfungen und erste Evaluierungen kostenfrei. Apify behält eine Provision von 20 % auf alle PPE-Einnahmen; die oben genannten Preise sind Bruttobeträge.

Installation

npm (MCP stdio-Transport)

npm install -g toolstem-sec-mcp-server

Fügen Sie dies Ihrer MCP-Client-Konfiguration hinzu (Claude Desktop, Cursor, etc.):

{
  "mcpServers": {
    "toolstem-sec": {
      "command": "toolstem-sec-mcp-server"
    }
  }
}

Kein API-Schlüssel erforderlich.

Gehostet auf Apify

Führen Sie den Actor direkt aus oder verbinden Sie sich über das MCP-Gateway:

https://mcp.apify.com/?tools=toolstem/toolstem-sec-mcp-server

Beispiel für Actor-Eingabe:

{
  "tool": "get_material_events_digest",
  "ticker_or_cik": "TSLA",
  "lookback_days": 365
}

HTTP-Server (selbst gehostet)

npm install -g toolstem-sec-mcp-server
toolstem-sec-mcp-server --http
# Listens on http://0.0.0.0:3000/mcp

SEC EDGAR Fair-Access-Richtlinie

Der gesamte ausgehende Datenverkehr läuft über einen gemeinsamen Ratenbegrenzer mit gleitendem Fenster (Ziel 8 Anfragen/Sek., 4 Anfragen/Sek. Sicherheitsabstand unter dem harten Limit der SEC von 10 Anfragen/Sek.). Jede Anfrage enthält einen User-Agent-Header, der das Paket und eine Kontakt-E-Mail gemäß SEC-Richtlinie identifiziert. Überschreiben Sie die Kontakt-E-Mail über:

SEC_USER_AGENT_CONTACT=you@yourorg.com toolstem-sec-mcp-server

Ein Verstoß gegen die Fair-Access-Richtlinie der SEC kann dazu führen, dass Ihre IP blockiert wird. Dieser Server ist so konzipiert, dass er automatisch konform bleibt.

v0.2 Roadmap

Form 4 XML-Parsing – richtungsabhängige Insider-Signale (STRONG_BUYING / BUYING / NEUTRAL / SELLING / STRONG_SELLING) mit Netto-Aktienanzahl
13F XBRL-Parsing – quartalsweise institutionelle Flusssignale (ACCUMULATING / HOLDING / DISTRIBUTING) mit Anzahl der Institutionen
8-K Textextraktion – natürlichsprachliche Zusammenfassungen jedes wesentlichen Ereignisses aus dem primären HTML-Dokument der Einreichung

Lizenz & Autor

MIT-Lizenz – siehe LICENSE.

Erstellt von Toolstem. Daten stammen direkt von SEC EDGAR.

Available Tools

5 tools

compare_disclosure_signalsCompare Disclosure SignalsA

Side-by-side comparison of 2-5 companies across key SEC disclosure signals: filing velocity, material event count (90d), red-flag count (365d), activist risk flag, and most recent filing date. Returns derived "winners" for each dimension — quietest disclosure, most active filer, most red flags, and companies with active activist investors. All lookups run in parallel. Use for competitive intelligence or risk triage across a watchlist.

ParametersJSON Schema

Name	Required	Description	Default
`tickers_or_ciks`	Yes	2-5 ticker symbols or CIKs to compare (e.g. ["AAPL", "MSFT", "GOOGL"]).

Output Schema

ParametersJSON Schema

Name	Required	Description
`companies`	Yes
`winners`	Yes
`meta`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses parallel lookups, which is a useful behavioral trait. However, it does not mention data freshness, authentication needs, rate limits, or potential side effects. Given the mutation-like nature of comparison tools, more transparency could be warranted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences (about 60 words) with no wasted words. It front-loads the core purpose, then adds behavioral detail and use cases. Every sentence earns its place.

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?

The tool is moderately complex (multi-company, multiple signals), and the description covers input, signals, derived outputs, parallel execution, and use cases. Given an output schema exists, the description does not need to explain return values but still provides sufficient context for correct invocation.

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

Parameters4/5

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

The input schema has one parameter with 100% description coverage. The description adds value by clarifying the parameter as 'ticker symbols or CIKs' and reinforcing the 2-5 range. It also explains how the parameter is used to generate derived winners, enriching the 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 clearly states the tool compares 2-5 companies across specific SEC disclosure signals, listing each signal and noting it returns derived 'winners.' This specific verb+resource combination distinguishes it from single-company sibling tools like get_company_filings_summary.

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 description suggests use cases ('competitive intelligence or risk triage across a watchlist') and specifies the input range (2-5 tickers). It implicitly differentiates from siblings, but lacks explicit exclusions or when-not-to-use guidance.

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

get_company_filings_summaryCompany Filings SummaryA

Retrieve a structured overview of a company's SEC filing activity. Returns the most recent 20 filings and pre-computed signals: filing velocity (ACCELERATING / NORMAL / SLOWING vs. trailing 365-day average), material event count in the last 90 days, 10-K disclosure volume trend (RISING / STABLE / FALLING), and the unique form types filed in the last 90 days. Use this as a first-pass signal before digging into insider or material-event detail.

ParametersJSON Schema

Name	Required	Description	Default
`ticker_or_cik`	Yes	Ticker symbol (e.g. "AAPL") or numeric CIK (e.g. "320193" or "0000320193").

Output Schema

ParametersJSON Schema

Name	Required	Description
`ticker`	Yes
`cik`	Yes
`company_name`	Yes
`recent_filings`	Yes
`signals`	Yes
`meta`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Despite no annotations, the description fully explains the tool's read-only behavior and output. It details the returned signals and their nature, making the agent aware of what to expect. No side effects are implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph that front-loads the main action and lists outputs efficiently. Every sentence adds value without redundancy.

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?

Given the simple single-parameter input and existing output schema, the description covers all necessary context: what it returns, key signals, and its role as a first-pass tool. It is complete for an agent to decide usage.

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 coverage is 100%, so the baseline is 3. The description does not add further parameter guidance beyond the schema's description. It is adequate but not enhanced.

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 clearly states the tool retrieves a structured overview of SEC filing activity, listing specific outputs (recent 20 filings, velocity, material event count, etc.). It distinguishes itself from siblings by positioning as a first-pass signal before insider or material event detail.

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 description explicitly advises using this as a first-pass signal before deeper tools, providing clear context. It does not explicitly list when not to use, but the guidance is strong enough.

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

get_insider_signalInsider SignalA

Probe insider filing activity (Form 3, 4, 4/A) for a company over a configurable lookback window. Answers: "Are insiders filing recently?" Returns recent Form 4 filing references and counts. NOTE: Direction-aware buy/sell signals (insider_signal, buy_count, sell_count) are null/0 in v0.1 — Form 4 XML parsing ships in v0.2.

ParametersJSON Schema

Name	Required	Description	Default
`ticker_or_cik`	Yes	Ticker symbol (e.g. "MSFT") or numeric CIK.
`lookback_days`	No	Number of calendar days to look back (default 90, max 730).

Output Schema

ParametersJSON Schema

Name	Required	Description
`ticker`	Yes
`cik`	Yes
`company_name`	Yes
`lookback_days`	Yes
`insider_signal`	Yes
`net_transaction_count`	Yes
`buy_count`	Yes
`sell_count`	Yes
`recent_insider_filings`	Yes
`meta`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that directional signals are null/0 in v0.1 and mentions returns (references and counts). It lacks details like auth or rate limits, but for a read-only probe this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences plus a note. It is front-loaded with purpose, then returns, then limitation. Every sentence adds 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?

Given the tool's simplicity (2 params, output schema present), the description covers purpose, returns, and a key limitation. No gaps remain for typical usage.

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 coverage is 100%, so the schema already explains parameters well. The description mentions configurable lookback but adds no new semantic meaning beyond the schema's descriptions.

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 specifies the verb 'Probe' and resource 'insider filing activity' with clear forms (3, 4, 4/A) and a configurable lookback window. It answers a direct question and states returns. It differentiates from siblings like get_institutional_signal by focusing on insider filings.

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 description implies usage for recent insider filing activity but does not explicitly state when not to use or compare with alternatives. The note about v0.2 hints at limitations, but no direct guidance on preferring other tools.

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

get_institutional_signalInstitutional SignalA

Probe institutional and activist investor signals for a company. Returns a live activist_risk_flag (true if any SC 13D or 13D/A was filed in the last 365 days — an activist investor has disclosed a large stake). Also lists the 13D filings and their SEC URLs. NOTE: Institutional accumulation/distribution signal (institutional_signal) and recent_13f_count are null/0 in v0.1 — quarterly 13F XBRL parsing ships in v0.2.

ParametersJSON Schema

Name	Required	Description	Default
`ticker_or_cik`	Yes	Ticker symbol (e.g. "NVDA") or numeric CIK.
`quarters_back`	No	Number of calendar quarters to look back (default 4 ≈ 1 year, max 20).

Output Schema

ParametersJSON Schema

Name	Required	Description
`ticker`	Yes
`cik`	Yes
`company_name`	Yes
`quarters_back`	Yes
`institutional_signal`	Yes
`recent_13f_count`	Yes
`activist_risk_flag`	Yes
`recent_13d_filings`	Yes
`meta`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description bears the burden. It discloses that institutional_signal and recent_13f_count are null/0 in v0.1, and explains the activist_risk_flag logic. This provides important behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences plus a note, front-loading the main purpose and providing essential details without waste. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown), the description adequately covers key outputs and version caveats. It lacks error handling info but is sufficient for a tool of this complexity.

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%, so the baseline is 3. The description adds minimal new semantics beyond the schema, merely restating the parameters in context. It does not compensate for low coverage.

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 clearly states it probes institutional and activist investor signals for a company, listing specific outputs like activist_risk_flag and 13D filings. It distinguishes from siblings like get_insider_signal by focusing on institutional actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not provide explicit guidance on when to use it versus sibling tools like compare_disclosure_signals or get_company_filings_summary. Usage context is implied but not directly addressed.

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

get_material_events_digestMaterial Events DigestA

Retrieve a severity-ranked digest of all 8-K and 8-K/A filings for a company within a configurable lookback window. Each event is tagged with item codes mapped to plain-English labels, categories, and severity (RED / YELLOW / GREEN). Returns redflag_count (events with any RED item) and category_counts for quick categorical analysis. Answers: "Has this company disclosed a cybersecurity incident, restatement, or going-concern risk recently?" Premium-tier tool. See the actor pricing page for current per-call cost.

ParametersJSON Schema

Name	Required	Description	Default
`ticker_or_cik`	Yes	Ticker symbol (e.g. "TSLA") or numeric CIK.
`lookback_days`	No	Number of calendar days to include (default 365, max 1825 / 5 years).

Output Schema

ParametersJSON Schema

Name	Required	Description
`ticker`	Yes
`cik`	Yes
`company_name`	Yes
`lookback_days`	Yes
`events`	Yes
`category_counts`	Yes
`redflag_count`	Yes
`meta`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explains the output includes severity tags, redflag_count, and category_counts, and mentions that events are tagged with item codes mapped to labels. It does not specify permissions, rate limits, or error cases, but provides sufficient detail about the tool's function and output.

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 well-structured, front-loading the main purpose and then adding details on output format, example question, and pricing. It is not overly verbose; each sentence serves a purpose. Minor room for improvement but overall concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (though details not provided to us), the description is fairly complete. It covers the tool's purpose, output (redflag_count, category_counts), and an example use case. It does not discuss error handling or limits, but it adequately sets expectations for a digest tool.

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%, so the baseline is 3. The description does not add additional meaning to the parameters beyond what the schema already provides (ticker_or_cik and lookback_days). It focuses on the output and use case, not parameter details, so no extra value is given.

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 clearly identifies the tool as retrieving a severity-ranked digest of 8-K and 8-K/A filings, specifying the resource (filings), action (retrieve digest), and output format (tags, severity levels, counts). It also provides a concrete example question, distinguishing it from sibling tools like get_insider_signal or get_company_filings_summary, which focus on different data types.

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 description implies usage by providing an example question about recent cybersecurity incidents or restatements, and notes it is a premium-tier tool with per-call cost. However, it does not explicitly compare to sibling tools or state when not to use it, leaving room for ambiguity in tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.2May 1, 2026
- First observedcompare_disclosure_signals
- First observedget_company_filings_summary
- First observedget_insider_signal
- First observedget_institutional_signal
- First observedget_material_events_digest

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-05-01 01:55 across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect of SEC disclosure analysis: cross-company comparison, filing activity overview, insider signals, institutional/activist signals, and material event digest. Descriptions clearly differentiate their purposes with no overlapping functionality.

Naming Consistency5/5

All tool names follow the same snake_case verb_noun pattern (e.g., get_company_filings_summary, get_insider_signal). The prefix 'get_' is used consistently, making the naming predictable and easy to understand.

Tool Count5/5

With 5 tools, the server is well-scoped for its focus on SEC disclosure signals. Each tool provides a necessary, non-redundant function, covering the key aspects of the domain without overwhelming the user.

Completeness4/5

The tool set covers the major areas of SEC disclosure analysis: comparison, filings summary, insider, institutional, and material events. Minor gaps exist (e.g., detailed insider signals and institutional accumulation are noted as upcoming), but the current surface is functional for core use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Edgar A
io.github.pipeworx-io
EDGAR MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
562
Sec A
io.github.pipeworx-io
SEC MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
2
Insidewell A
dev.workers.cybermax-tools.cybermax
Insider trading API + MCP: SEC Form 4 buys/sells, cluster buys. Keys $19/mo; 100 free/day.
Finance Government Data
31
secedgar-mcp-server A
io.github.cyanheads
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Finance Government Data Open Data
16210

Related MCP Servers

sec-edgar-mcp
Finance Government Data Open Data
guptaprakhariitr
A
license
Not graded
quality
D
maintenance
Hosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
Updated 4 months ago (2026-06-11 08:39 UTC)
6 npm
1
MIT
northbridge-diligence
Finance Open Data
chidrupa99
A
license
A
quality
B
maintenance
An MCP server that wraps SEC EDGAR APIs to provide company financial data, screening metrics, and disclosure signals for investment diligence, with every figure traced to its source filing.
Updated 2 months ago (2026-08-02 04:10 UTC)
8
MIT
13flow
Finance Government Data Research & Data
bluetouff
A
license
Not graded
quality
B
maintenance
MCP server that reconstructs hedge-fund/superinvestor portfolios from SEC EDGAR 13F filings, offering tools to query fund holdings, consensus activity, and quarter-over-quarter changes through a read-only API.
Updated 7 days ago (2026-10-04 12:38 UTC)
4
AGPL 3.0
SEC EDGAR Data MCP
Finance Government Data Search
SEC-API-io
A
license
Not graded
quality
C
maintenance
Hosted MCP server granting AI agents access to 20M+ SEC EDGAR filings, 100M+ exhibits, and comprehensive entity data through 49 tools, with support for raw documents, extracted sections, and structured JSON.
Updated 2 months ago (2026-08-17 20:11 UTC)
6 npm
1
MIT

Appeared in Searches

EarningsPrism MCP (Model Context Protocol) Configuration

SEC EDGAR MCP-Server – Insider-Signale, 13F-Bestände & Einreichungs-Intelligence

Warum gibt es das?

Die fünf Tools

1. get_company_filings_summary

2. get_insider_signal

3. get_institutional_signal

4. get_material_events_digest ⚡ Premium ($0,50)

5. compare_disclosure_signals

Preisgestaltung

Installation

npm (MCP stdio-Transport)

Gehostet auf Apify

HTTP-Server (selbst gehostet)

SEC EDGAR Fair-Access-Richtlinie

v0.2 Roadmap

Lizenz & Autor

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

1. `get_company_filings_summary`

2. `get_insider_signal`

3. `get_institutional_signal`

4. `get_material_events_digest` ⚡ Premium ($0,50)

5. `compare_disclosure_signals`