Skip to main content

de en es ko ru zh

toolstem-sec-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

Servidor MCP de la SEC EDGAR — Señales de información privilegiada, participaciones 13F e inteligencia de presentaciones

Inteligencia de la SEC EDGAR para agentes de IA. Cinco herramientas que responden a las preguntas importantes: señales de operaciones con información privilegiada (Formulario 4), indicadores de riesgo activista SC 13D, velocidad de presentación de 10-K/8-K, gravedad de eventos materiales en 8-K (ROJO/AMARILLO/VERDE) y comparaciones de divulgación entre múltiples empresas; todo devuelto como JSON estructurado, directamente desde la SEC EDGAR. No se requiere clave de API.

Por qué existe esto

Las herramientas de datos de la SEC existentes ofrecen a los agentes listas de presentaciones paginadas y XML sin procesar. Los agentes deben analizar, clasificar y derivar señales por sí mismos, consumiendo ventana de contexto en extracción burocrática en lugar de análisis.

El servidor MCP de Toolstem SEC precalcula cinco señales de alto valor directamente desde la API de presentaciones públicas de la SEC EDGAR, devolviendo JSON estructurado listo para agentes. Sin proveedores de datos de terceros, sin claves de API, sin tarifas por símbolo; solo la fuente autorizada de la SEC EDGAR con un limitador de tasa que lo mantiene fuera de su lista de bloqueo.

Related MCP server: northbridge-diligence

Las cinco herramientas

1. `get_company_filings_summary`

Resumen de la actividad de presentación de una empresa: últimas 20 presentaciones + señales calculadas.

Señal	Descripción
`filing_velocity`	`ACCELERATING` / `NORMAL` / `SLOWING` frente al promedio de los últimos 365 días
`material_event_count_90d`	Recuento de presentaciones 8-K en los últimos 90 días
`disclosure_volume_trend`	`RISING` / `STABLE` / `FALLING` basado en la comparación del tamaño del 10-K
`latest_form_types`	Tipos de formulario únicos presentados en los últimos 90 días

Ejemplo de salida (abreviado):

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

Analiza la actividad de presentación de información privilegiada de los Formularios 3/4/4A dentro de un período de tiempo determinado.

Devuelve: recent_insider_filings (números de acceso + URLs de la SEC para los Formularios 3/4/4A), lookback_days y recuentos.

Nota de la v0.1: Cuando existe al menos una presentación de Formulario 3/4/4A en el período de búsqueda, insider_signal es null ("dirección desconocida: el análisis XML del Formulario 4 se incluirá en la v0.2"). Cuando no existen presentaciones de información privilegiada en el período, insider_signal es "NEUTRAL" ("ausencia verificada de actividad"). buy_count y sell_count son 0 en la v0.1.

Ejemplo de salida (abreviado):

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

Analiza la actividad de inversores activistas a través de presentaciones SC 13D / 13D/A.

Campo	Descripción
`activist_risk_flag`	`true` si se presentó algún SC 13D o 13D/A en los últimos 365 días
`recent_13d_filings`	Lista de presentaciones 13D con tipo de formulario, fecha y URL de la SEC

Nota de la v0.1: institutional_signal y recent_13f_count son null/0. El análisis trimestral de 13F XBRL/XML (ACCUMULATING / HOLDING / DISTRIBUTING) se incluirá en la v0.2.

Ejemplo de salida (abreviado):

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

4. `get_material_events_digest` ⚡ premium ($0.50)

Resumen clasificado por gravedad de todas las presentaciones 8-K y 8-K/A dentro de un período de tiempo determinado. Asigna a cada código de elemento una etiqueta en lenguaje sencillo y una calificación de gravedad.

Gravedad	Ejemplos
🔴 ROJO	Incidente de ciberseguridad (1.05), reexpresión (4.02), quiebra (1.03), exclusión de cotización (3.01)
🟡 AMARILLO	Adquisición (2.01), nueva deuda (2.03), salida de ejecutivo (5.02)
🟢 VERDE	Publicación de resultados (2.02), Reg FD (7.01), voto de accionistas (5.07)

Devuelve: events[] (ordenados del más reciente al más antiguo), redflag_count, category_counts.

Ejemplo de salida (abreviado):

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

Comparación lado a lado de 2 a 5 empresas en todas las señales de divulgación clave. Todas las búsquedas se ejecutan en paralelo.

Devuelve por empresa: filing_velocity, material_event_count_90d, redflag_count_365d, activist_risk_flag, last_filing_date.

Devuelve los ganadores (como CIKs, no tickers; consulte la matriz companies[]): quietest_disclosure, most_active, most_redflags, activist_targets.

Ejemplo de salida (abreviado):

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

Precios

Todas las llamadas se facturan por resultado a través del sistema de Pago por Evento (PPE) de Apify. El precio se cobra en el momento en que la herramienta devuelve su resultado.

Herramienta	Nivel	Precio por llamada
`get_company_filings_summary`	Económico	$0.005
`get_insider_signal`	Estándar	$0.05
`get_institutional_signal`	Estándar	$0.05
`get_material_events_digest`	Premium	$0.50
`compare_disclosure_signals`	Premium	$0.50

Las pruebas de demostración predeterminadas (ejecuciones de Actor sin entrada tool) son gratuitas: sirven un resultado en caché y no generan un cargo de PPE. Esto mantiene las pruebas de verificación de estado del directorio y las evaluaciones iniciales sin costo. Apify retiene una comisión del 20% sobre todos los ingresos por PPE; los precios anteriores son importes brutos.

Instalación

npm (transporte stdio de MCP)

npm install -g toolstem-sec-mcp-server

Agréguelo a su configuración de cliente MCP (Claude Desktop, Cursor, etc.):

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

No se requiere clave de API.

Alojado en Apify

Ejecute el Actor directamente o conéctese a través de la puerta de enlace MCP:

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

Ejemplo de entrada del Actor:

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

Servidor HTTP (autoalojado)

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

Política de acceso justo de la SEC EDGAR

Todo el tráfico saliente pasa a través de un limitador de tasa de ventana deslizante compartido (objetivo de 8 rps, margen de seguridad de 4 rps por debajo del límite estricto de 10 rps de la SEC). Cada solicitud incluye un encabezado User-Agent que identifica el paquete y un correo electrónico de contacto según la política de la SEC. Anule el correo electrónico de contacto mediante:

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

Violar la política de acceso justo de la SEC puede resultar en el bloqueo de su IP. Este servidor está diseñado para mantenerse conforme automáticamente.

Hoja de ruta de la v0.2

Análisis XML del Formulario 4: señales de información privilegiada conscientes de la dirección (STRONG_BUYING / BUYING / NEUTRAL / SELLING / STRONG_SELLING) con recuentos netos de acciones.
Análisis XBRL 13F: señales de flujo institucional trimestral (ACCUMULATING / HOLDING / DISTRIBUTING) con recuento de instituciones.
Extracción de texto 8-K: resúmenes en lenguaje natural de cada evento material del documento HTML principal de la presentación.

Licencia y autor

Licencia MIT: consulte LICENSE.

Creado por Toolstem. Datos obtenidos directamente de 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

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

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