de en es ko ru zh

toolstem-sec-mcp-server

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

Official

by toolstem

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP-сервер SEC EDGAR — инсайдерские сигналы, владение активами 13F и аналитика отчетности

Аналитика SEC EDGAR для ИИ-агентов. Пять инструментов, которые отвечают на важные вопросы: инсайдерские торговые сигналы по форме 4, флаги риска активности акционеров по форме SC 13D, скорость подачи отчетности 10-K/8-K, серьезность существенных событий в 8-K (КРАСНЫЙ/ЖЕЛТЫЙ/ЗЕЛЕНЫЙ) и сравнение раскрытия информации несколькими компаниями — все это возвращается в виде структурированного JSON напрямую из SEC EDGAR. API-ключ не требуется.

Зачем это нужно

Существующие инструменты для работы с данными SEC предоставляют агентам списки отчетности с разбивкой на страницы и «сырой» XML. Агентам приходится самостоятельно парсить, классифицировать и выводить сигналы, расходуя контекстное окно на бюрократическое извлечение данных вместо анализа.

Toolstem SEC MCP Server предварительно вычисляет пять высокоценных сигналов непосредственно из публичного API подачи отчетности SEC EDGAR, возвращая структурированный 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`	Количество отчетов 8-K за последние 90 дней
`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`

Анализ активности инсайдеров по формам 3/4/4A в заданном окне поиска.

Возвращает: recent_insider_filings (номера доступа + URL SEC для форм 3/4/4A), lookback_days и количество.

Примечание к v0.1: Если в окне поиска существует хотя бы один отчет по форме 3/4/4A, insider_signal будет null («направление неизвестно — парсинг XML формы 4 появится в v0.2»). Если в окне поиска нет отчетов инсайдеров, insider_signal будет "NEUTRAL" («подтвержденное отсутствие активности»). buy_count и sell_count в v0.1 равны 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`	`true`, если какой-либо отчет SC 13D или 13D/A был подан за последние 365 дней
`recent_13d_filings`	Список отчетов 13D с типом формы, датой и URL SEC

Примечание к 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" }
}

Ценообразование

Все вызовы оплачиваются за результат через систему Pay-Per-Event (PPE) от Apify. Оплата взимается в момент возврата инструментом результата.

Инструмент	Уровень	Цена за вызов
`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

Демо-запросы по умолчанию (запуск Actor без ввода tool) бесплатны — они возвращают кэшированный результат и не вызывают списание PPE. Это позволяет бесплатно проводить проверки работоспособности каталога и первичную оценку. Apify удерживает комиссию 20% со всех доходов PPE; указанные выше цены являются валовыми суммами.

Установка

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 запросов в секунду, запас безопасности 4 запроса в секунду ниже жесткого лимита SEC в 10 запросов в секунду). Каждый запрос включает заголовок User-Agent, идентифицирующий пакет, и контактный email согласно политике SEC. Переопределите контактный email через:

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

Нарушение политики справедливого доступа SEC может привести к блокировке вашего IP. Этот сервер разработан для автоматического соблюдения правил.

Дорожная карта v0.2

Парсинг XML формы 4 — инсайдерские сигналы с учетом направления (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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

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

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Edgar A
io.github.pipeworx-io
EDGAR MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
462
sec A
io.github.pipeworx-io
SEC MCP — SEC EDGAR public APIs (free, no auth)
Government Data Finance Open Data
342
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
1629
ko-mcp A
io.github.SharpLu
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Finance Government Data
242

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 3 months ago (2026-06-11 08:39 UTC)
25
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 a month ago (2026-08-02 04:10 UTC)
8
MIT
13flow
Finance Government Data Research & Data
bluetouff
A
license
Not graded
quality
C
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 2 days ago (2026-09-04 08:28 UTC)
3
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 20 days ago (2026-08-17 20:11 UTC)
25
1
MIT

Appeared in Searches

EarningsPrism MCP (Model Context Protocol) Configuration

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/toolstem/toolstem-sec-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP-сервер SEC EDGAR — инсайдерские сигналы, владение активами 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

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `get_company_filings_summary`

2. `get_insider_signal`

3. `get_institutional_signal`

4. `get_material_events_digest` ⚡ премиум ($0.50)

5. `compare_disclosure_signals`