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 服务器 — 内幕信号、13F 持仓与申报情报

为 AI 智能体提供的 SEC EDGAR 情报。 五个工具可回答关键问题：内幕交易 Form 4 信号、SC 13D 激进投资者风险标记、10-K/8-K 申报频率、8-K 重大事件严重程度（红/黄/绿）以及多公司披露对比——所有数据均以结构化 JSON 格式直接从 SEC EDGAR 获取。无需 API 密钥。

为什么存在此工具

现有的 SEC 数据工具通常只为智能体提供分页的申报列表和原始 XML。智能体必须自行解析、分类并推导信号——这会消耗宝贵的上下文窗口用于繁琐的提取工作，而非分析。

Toolstem SEC MCP 服务器直接从 SEC EDGAR 的公共提交 API 预计算五个高价值信号，并返回结构化、可供智能体直接使用的 JSON。无需第三方数据提供商，无需 API 密钥，无需按代码收费——仅使用 SEC EDGAR 的权威来源，并配有速率限制器以防止被封禁。

Related MCP server: northbridge-diligence

五大工具

1. `get_company_filings_summary`

公司申报活动概览：最近 20 次申报 + 计算出的信号。

信号	描述
`filing_velocity`	`ACCELERATING`（加速）/ `NORMAL`（正常）/ `SLOWING`（减速），基于过去 365 天平均值
`material_event_count_90d`	过去 90 天内 8-K 申报的数量
`disclosure_volume_trend`	`RISING`（上升）/ `STABLE`（稳定）/ `FALLING`（下降），基于 10-K 大小对比
`latest_form_types`	过去 90 天内申报的唯一表格类型

输出示例（缩略）：

{
  "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`

在回溯窗口内探测 Form 3/4/4A 内幕申报活动。

返回：recent_insider_filings（Form 3/4/4A 的访问编号 + SEC URL）、lookback_days 和计数。

v0.1 注： 当回溯窗口内至少存在一份 Form 3/4/4A 申报时，insider_signal 为 null（“方向未知 — Form 4 XML 解析将在 v0.2 中发布”）。当窗口内不存在内幕申报时，insider_signal 为 "NEUTRAL"（“已验证无活动”）。在 v0.1 中 buy_count 和 sell_count 为 0。

输出示例（缩略）：

{
  "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`

通过 SC 13D / 13D/A 申报探测激进投资者活动。

字段	描述
`activist_risk_flag`	如果过去 365 天内提交过任何 SC 13D 或 13D/A，则为 `true`
`recent_13d_filings`	包含表格类型、日期和 SEC URL 的 13D 申报列表

v0.1 注： institutional_signal 和 recent_13f_count 为 null/0。季度 13F XBRL/XML 解析（ACCUMULATING（增持）/ HOLDING（持有）/ DISTRIBUTING（减持））将在 v0.2 中发布。

输出示例（缩略）：

{
  "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` ⚡ 高级版 ($0.50)

回溯窗口内所有 8-K 和 8-K/A 申报的严重程度排名摘要。将每个项目代码映射为通俗易懂的标签和严重程度评级。

严重程度	示例
🔴 RED	网络安全事件 (1.05)、重述 (4.02)、破产 (1.03)、退市 (3.01)
🟡 YELLOW	收购 (2.01)、新增债务 (2.03)、高管离职 (5.02)
🟢 GREEN	财报发布 (2.02)、Reg FD (7.01)、股东投票 (5.07)

返回：events[]（按最新排序）、redflag_count、category_counts。

输出示例（缩略）：

{
  "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`

针对 2-5 家公司在所有关键披露信号上的并排对比。所有查询均并行运行。

每家公司返回：filing_velocity、material_event_count_90d、redflag_count_365d、activist_risk_flag、last_filing_date。

返回优胜者（以 CIK 为准，而非股票代码 — 请与 companies[] 数组交叉参考）：quietest_disclosure（披露最少）、most_active（最活跃）、most_redflags（红旗最多）、activist_targets（激进投资者目标）。

输出示例（缩略）：

{
  "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" }
}

定价

所有调用均通过 Apify 的按事件付费 (PPE) 系统按每个结果计费。费用在工具返回结果时扣除。

工具	等级	每次调用价格
`get_company_filings_summary`	廉价	$0.005
`get_insider_signal`	标准	$0.05
`get_institutional_signal`	标准	$0.05
`get_material_events_digest`	高级	$0.50
`compare_disclosure_signals`	高级	$0.50

默认演示探测（无 tool 输入的 Actor 运行）是免费的——它们提供缓存结果且不触发 PPE 费用。这使得目录健康检查和首次评估无需成本。Apify 保留所有 PPE 收入的 20% 作为佣金；上述价格为总金额。

安装

npm (MCP stdio 传输)

npm install -g toolstem-sec-mcp-server

添加到您的 MCP 客户端配置（Claude Desktop, Cursor 等）：

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

无需 API 密钥。

托管在 Apify 上

直接运行 Actor 或通过 MCP 网关连接：

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

Actor 输入示例：

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

HTTP 服务器 (自托管)

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

SEC EDGAR 公平访问政策

所有出站流量均通过共享滑动窗口速率限制器（目标 8 rps，低于 SEC 10 rps 硬上限的 4 rps 安全余量）。每个请求都包含一个标识该包的 User-Agent 标头以及符合 SEC 政策的联系电子邮件。通过以下方式覆盖联系电子邮件：

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

违反 SEC 的公平访问政策可能导致您的 IP 被封禁。此服务器旨在自动保持合规。

v0.2 路线图

Form 4 XML 解析 — 具备方向性的内幕信号（STRONG_BUYING / BUYING / NEUTRAL / SELLING / STRONG_SELLING）及净持股数
13F XBRL 解析 — 季度机构流向信号（ACCUMULATING / HOLDING / DISTRIBUTING）及机构数量
8-K 文本提取 — 从申报的主要 HTML 文档中提取每个重大事件的自然语言摘要

许可证与作者

MIT 许可证 — 见 LICENSE。

由 Toolstem 构建。数据直接来源于 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 服务器 — 内幕信号、13F 持仓与申报情报

为什么存在此工具

五大工具

1. get_company_filings_summary

2. get_insider_signal

3. get_institutional_signal

4. get_material_events_digest ⚡ 高级版 ($0.50)

5. compare_disclosure_signals

定价

安装

npm (MCP stdio 传输)

托管在 Apify 上

HTTP 服务器 (自托管)

SEC EDGAR 公平访问政策

v0.2 路线图

许可证与作者

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` ⚡ 高级版 ($0.50)

5. `compare_disclosure_signals`