What can you do with this server?

This server provides SEC EDGAR filing intelligence via five composite tools, computing high-value signals directly from SEC's public submissions API — no API key required, with per-call payments ($0.01 USDC on Base mainnet) via x402. * Get Company Filings Summary (get_company_filings_summary): Overview of a company's recent SEC filing activity, including the last 20 filings and computed signals: filing velocity (ACCELERATING / NORMAL / SLOWING), material event count (last 90 days), 10-K disclosure volume trend (RISING / STABLE / FALLING), and recent unique form types. * Get Insider Signal (get_insider_signal): Probe insider activity via Forms 3, 4, and 4/A over a configurable lookback window (1–730 days, default 90). Returns recent filing references and counts. Direction-aware buy/sell signals are planned for a future version. * Get Institutional Signal (get_institutional_signal): Detect activist investor risk by scanning SC 13D/13D/A filings over a configurable number of quarters (1–20, default 4). Returns a live activist_risk_flag and a list of 13D filings with SEC URLs. Institutional accumulation/distribution signals are planned for a future update. * Get Material Events Digest (get_material_events_digest) ⚡ Premium: Severity-ranked digest of all 8-K and 8-K/A filings over a configurable lookback window (default 365 days). Each event is tagged with item codes, plain-English labels, categories, and severity levels (RED / YELLOW / GREEN), with red-flag counts and category breakdowns. Useful for detecting cybersecurity incidents, restatements, bankruptcy, executive departures, and more. * Compare Disclosure Signals (compare_disclosure_signals): Side-by-side comparison of 2–5 companies across key signals — filing velocity, material event count (90 days), red-flag count (365 days), activist risk, and most recent filing date. Derives "winners" for quietest filer, most active filer, most red flags, and activist targets. All lookups run in parallel.

de en es ko ru zh

toolstem-sec-mcp-server

Official

by toolstem

Overview Schema Related Servers Score Discussions

TypeScript

Remote

SEC EDGAR MCP Server — Insider Signals, 13D Activist Risk & Filing Intelligence

npm version npm downloads License: MIT

SEC EDGAR intelligence for AI agents. Five composite tools that pre-compute high-value signals directly from SEC EDGAR's public submissions API, returned as structured JSON.

No SEC API key required. Data is sourced directly from SEC EDGAR's public submissions API. A built-in sliding-window rate limiter keeps traffic under SEC's 10 rps fair-access ceiling automatically.

Quickstart — hosted endpoint (recommended)

Point your MCP client or agent at the hosted endpoint. No API key, no infra, no setup. Billing is per-call via x402 — the agent's wallet pays directly in USDC on Base mainnet.

https://mcp.toolstem.com/mcp/sec

No SEC API key, no signup, no marketplace account — the agent's wallet pays directly.
No infrastructure — nothing to install, host, or keep running.
No setup — connect an MCP client and call a tool.
initialize and tools/list are free (discovery and schema introspection).
tools/call is tiered per tool (see Pricing below).

Claude Desktop

Drop this into your claude_desktop_config.json:

{
  "mcpServers": {
    "toolstem-sec": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.toolstem.com/mcp/sec"
      ]
    }
  }
}

Restart Claude Desktop, then ask: "Has TSLA disclosed any material 8-K events in the last 90 days?"

Any MCP client (LangChain.js)

The official @langchain/mcp-adapters library connects directly to the hosted URL:

import { MultiServerMCPClient } from "@langchain/mcp-adapters";
import { ChatOpenAI } from "@langchain/openai";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

const client = new MultiServerMCPClient({
  toolstem_sec: {
    transport: "http",
    url: "https://mcp.toolstem.com/mcp/sec",
    // Add your x402-signing middleware via headers, OR run an x402
    // proxy locally and point url at it. See https://www.x402.org/clients.
  },
});

const tools = await client.getTools();
const agent = createReactAgent({ llm: new ChatOpenAI({ model: "gpt-4o-mini" }), tools });
await agent.invoke({ messages: "Has TSLA disclosed any material 8-K events in the last 90 days?" });

LangChain quick-start (`langchain-toolstem`)

The langchain-toolstem wrapper handles x402 payment for you — pass a funded wallet key and the SEC tools are included automatically:

import { createToolstemTools } from 'langchain-toolstem';
const tools = await createToolstemTools({ walletPrivateKey: process.env.WALLET_KEY });
// SEC tools included automatically — agents pay per call in USDC

Prefer to run the server yourself over stdio/HTTP? See Advanced: self-host at the bottom.

Try the tools live in the Toolstem playground.

Related MCP server: northbridge-diligence

Pricing

MCP initialize and tools/list are free — discover the server and its tool surface without paying anything.
tools/call is tiered per tool, paid in USDC on Base mainnet via x402. No API key, no signup, no marketplace account — agents pay directly from their own wallet.

Tier	Price per call	Tools
Cheap	$0.005	`get_company_filings_summary`
Standard	$0.05	`get_insider_signal`, `get_institutional_signal`
Premium	$0.50	`get_material_events_digest`, `compare_disclosure_signals`

Per-tool breakdown:

Tool	Tier	Per call
`get_company_filings_summary`	Standard	$0.005 USDC
`get_insider_signal`	Standard	$0.05 USDC
`get_institutional_signal`	Standard	$0.05 USDC
`get_material_events_digest`	Premium	$0.50 USDC
`compare_disclosure_signals`	Premium	$0.50 USDC

How billing works

Toolstem uses the x402 payment protocol. Agents pay per call in USDC on Base — no API keys, no subscriptions, no invoices. The agent's wallet settles each call automatically via EIP-3009.

See the live pricing page on toolstem.com/sec/ for current rates.

The five tools

All five tools are composite/curated (they compute derived signals or aggregate across multiple EDGAR endpoints — no raw passthroughs). Annotations: readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true.

#	Tool	Required input	Optional input (default)	Tier (price/call)
1	`get_company_filings_summary`	`ticker_or_cik` (string)	—	Cheap ($0.005)
2	`get_insider_signal`	`ticker_or_cik` (string)	`lookback_days` (int 1–730, default 90)	Standard ($0.05)
3	`get_institutional_signal`	`ticker_or_cik` (string)	`quarters_back` (int 1–20, default 4)	Standard ($0.05)
4	`get_material_events_digest`	`ticker_or_cik` (string)	`lookback_days` (int 1–1825, default 365)	Premium ($0.50)
5	`compare_disclosure_signals`	`tickers_or_ciks` (string[2..5])	—	Premium ($0.50)

1. `get_company_filings_summary`

Overview of a company's filing activity: last 20 filings + computed signals.

Signal	Description
`filing_velocity`	`ACCELERATING` / `NORMAL` / `SLOWING` vs. trailing 365-day average
`material_event_count_90d`	Count of 8-K filings in the last 90 days
`disclosure_volume_trend`	`RISING` / `STABLE` / `FALLING` based on 10-K size comparison
`latest_form_types`	Unique form types filed in the last 90 days

Example output (abbreviated):

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

Probes Form 3 / 4 / 4/A insider filing activity within a configurable lookback window. Required: ticker_or_cik. Optional: lookback_days (1–730, default 90).

Returns: recent_insider_filings[] (accession numbers + SEC URLs), net_transaction_count, buy_count, sell_count, and insider_signal.

v0.1 limitation — counts only. v0.1 returns counts and Form 4 references only; direction-aware buy/sell signals ship in v0.2 (Form 4 XML parsing). Today, insider_signal is null when filings exist in the window (direction unknown) and "NEUTRAL" when no insider filings exist (verified absence). buy_count / sell_count are 0 in v0.1.

Example output (abbreviated):

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

Probes for activist investor activity via SC 13D / 13D/A filings. Required: ticker_or_cik. Optional: quarters_back (1–20, default 4 ≈ 1 year).

Field	Description
`activist_risk_flag`	`true` if any SC 13D or 13D/A was filed in the last 365 days
`recent_13d_filings`	List of 13D filings with form type, date, and SEC URL

v0.1 limitation — activist flag only. v0.1 ships the live activist_risk_flag (from 13D/13D-A) and a list of 13D filings. Quarterly 13F XBRL parsing — which produces institutional_signal (ACCUMULATING / HOLDING / DISTRIBUTING) and recent_13f_count — ships in v0.2. Today those two fields are null / 0.

Example output (abbreviated):

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

Premium tier — $0.50 USDC per call on Base mainnet, settled via x402. See the live pricing page on toolstem.com/sec/ for current rates.

Severity-ranked digest of all 8-K and 8-K/A filings within a configurable lookback window. Each item code is mapped to a plain-English label and severity rating. Required: ticker_or_cik. Optional: lookback_days (1–1825, default 365).

Severity	Examples
🔴 RED	Cybersecurity incident (1.05), restatement (4.02), bankruptcy (1.03), delisting (3.01)
🟡 YELLOW	Acquisition (2.01), new debt (2.03), executive departure (5.02)
🟢 GREEN	Earnings release (2.02), Reg FD (7.01), shareholder vote (5.07)

Returns: events[] (sorted newest-first), redflag_count, category_counts.

Example output (abbreviated):

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

Side-by-side comparison of 2–5 companies across all key disclosure signals. Required: tickers_or_ciks (string[2..5]). All lookups run in parallel.

Returns per-company: filing_velocity, material_event_count_90d, redflag_count_365d, activist_risk_flag, last_filing_date.

Returns winners (as CIKs, not tickers — cross-reference with the companies[] array): quietest_disclosure, most_active, most_redflags, activist_targets.

Example output (abbreviated):

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

Advanced: self-host

Most users should use the hosted endpoint above — it needs no API key, no infrastructure, and no setup. This section is for users who specifically want to run the server themselves. When self-hosting you are responsible for running the process and for supplying an EDGAR fair-access contact (SEC_USER_AGENT_CONTACT).

Claude Desktop (self-hosted over stdio)

Run locally over stdio — no x402 charges, you bring your own EDGAR fair-access contact:

{
  "mcpServers": {
    "toolstem-sec": {
      "command": "npx",
      "args": ["-y", "toolstem-sec-mcp-server"],
      "env": {
        "SEC_USER_AGENT_CONTACT": "you@yourorg.com"
      }
    }
  }
}

npm (MCP stdio transport)

npm install -g toolstem-sec-mcp-server
toolstem-sec-mcp-server

Self-hosted HTTP

Three modes:

Local-only (default — safest):

toolstem-sec-mcp-server --http
# Binds 127.0.0.1:3000 — reachable only from this machine

Remote with auth:

ALLOW_REMOTE=1 MCP_AUTH_TOKEN=my-secret toolstem-sec-mcp-server --http
# Binds 0.0.0.0:3000 — requires Bearer token on every /mcp request

Remote without auth (use at your own risk):

ALLOW_REMOTE=1 MCP_AUTH_DISABLED=1 toolstem-sec-mcp-server --http
# Binds 0.0.0.0:3000 — no authentication

Variable	Description
`PORT`	HTTP port (default `3000`)
`ALLOW_REMOTE`	Set to `1` to bind `0.0.0.0` instead of `127.0.0.1`
`MCP_AUTH_TOKEN`	Bearer token for `/mcp` routes (required when `ALLOW_REMOTE=1`)
`MCP_AUTH_DISABLED`	Set to `1` to skip auth even with `ALLOW_REMOTE=1` (not recommended)
`SEC_USER_AGENT_CONTACT`	Contact email for SEC EDGAR User-Agent header

SEC EDGAR fair-access policy

All outbound traffic goes through a shared sliding-window rate limiter (8 rps target, 4 rps safety margin below SEC's 10 rps hard cap). Every request includes a User-Agent header identifying the package and a contact email per SEC policy. Override the contact email via:

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

Violating SEC's fair-access policy can result in your IP being blocked. This server is designed to stay compliant automatically.

v0.2 roadmap

Form 4 XML parsing — direction-aware insider signals (STRONG_BUYING / BUYING / NEUTRAL / SELLING / STRONG_SELLING) with net share counts
13F XBRL parsing — quarterly institutional flow signals (ACCUMULATING / HOLDING / DISTRIBUTING) with institution count
8-K text extraction — natural-language summaries of each material event from the filing's primary HTML document

License & author

MIT License — see LICENSE.

Built by Toolstem. Data sourced directly from 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.

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
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 19 days ago (2026-08-15 11:13 UTC)
3
AGPL 3.0
SEC EDGAR Data MCP
Finance Government Data Search
SEC-API-io
A
license
Not graded
quality
A
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 17 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

SEC EDGAR MCP Server — Insider Signals, 13D Activist Risk & Filing Intelligence

Quickstart — hosted endpoint (recommended)

Claude Desktop

Any MCP client (LangChain.js)

LangChain quick-start (langchain-toolstem)

Pricing

How billing works

The five tools

1. get_company_filings_summary

2. get_insider_signal

3. get_institutional_signal

4. get_material_events_digest ⚡ Premium tier

5. compare_disclosure_signals

Advanced: self-host

Claude Desktop (self-hosted over stdio)

npm (MCP stdio transport)

Self-hosted HTTP

SEC EDGAR fair-access policy

v0.2 roadmap

License & author

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

LangChain quick-start (`langchain-toolstem`)

1. `get_company_filings_summary`

2. `get_insider_signal`

3. `get_institutional_signal`

4. `get_material_events_digest` ⚡ Premium tier

5. `compare_disclosure_signals`