Signalfeed

io.github.CloudCorpRecords由 GitHub 账号 CloudCorpRecords 发布v0.1.0更新于 Nov 4, 2026

US filing-event streams in one schema: insider clusters, 13D/G, 13F, 8-K, Form D, FDA and more.

已验证STDIO仅桌面金融数据与分析

概览

AI 生成的概览

DataSignals Events API 的客户端,让助手检索并读取十二类美国申报事件(如内部人集中买入、13D/G、13F、8-K)的评分记录。

可以做什么
  • 跨全部十二个数据流搜索申报事件,可按事件类型、股票代码、CIK 或最低评分筛选,并用游标分页
  • 按股票代码或 CIK 列出某家公司的全部申报事件,并按 event_id 查看单个事件详情
  • 查看各数据流的字段结构及评分是否可复算,并检查各数据流当前的更新时效
  • 查询每月事件额度的使用量与重置时间,并确认 API 密钥是否已配置、数据源是否可访问
适用场景
适合需要助手跟踪或研究美国监管申报及由申报衍生的信号(内部人交易、维权持股、机构持仓、重大事件、FDA 行动等)而不想自行搭建解析流程的场景。两个免密钥工具可先查看数据结构和新鲜度,再决定是否申请密钥。
运行要求
以 stdio 方式在本地运行,可通过 npx(npm 包)或 Docker 启动。需要密钥的工具要求通过环境变量 DATASIGNALS_KEY 提供 DataSignals API 密钥;DATASIGNALS_BASE_URL 可选,默认指向厂商 API 地址。需要能访问该 API 的网络。仅支持桌面端。
安装前请注意
API 密钥属于凭据,以 Bearer 请求头发送,请勿放入共享配置。带密钥的调用会消耗每月事件额度,额度耗尽时接口返回带提示的空页而非报错,结果可能静默为空。查询内容和标识符会发送给第三方 DataSignals API。该服务器为只读,不会修改数据。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Signalfeed,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

signalfeed

Twelve US filing-event streams, one schema, one key. signalfeed is a small client for the DataSignals Events API, which parses official filings into scored, decision-ready event records: insider buying clusters, planned insider sales (Form 144), activist stakes (13D/G), institutional holdings (13F), material events (8-K), private raises (Form D), FDA actions, biotech trial catalysts, NIH grants, federal contract awards, congressional trades and hiring signals. Every record links back to the filing it was parsed from, and where a record carries a score it also carries the terms that score was built from.

The feed is cursor-based: pass the cursor from one response back as since and you get exactly what arrived since — no duplicates, no gaps. Responses come back exactly as the API returned them: nothing is trimmed, renamed or summarised on the way through.

Configuration

  • DATASIGNALS_KEY — your API key. Required for the keyed tools; sent on those requests as Authorization: Bearer <key> and never as a query parameter, so it does not end up in server logs or browser history. The keyless tools never send it.
  • DATASIGNALS_BASE_URL (optional) — API base URL. Defaults to https://datasignalslab.com.

A keyed tool called without a key fails locally with DATASIGNALS_KEY is not set, before any request is made. Two tools — list_event_types and feed_health — work without a key, so you can see the shape of the data and how fresh it is before you decide.

Tools

  • search_events — search filing events across all twelve streams. All filters are optional: event_type (one of the twelve stream ids), ticker, cik, min_score, plus since (the cursor from a previous response) and limit for paging. Only the filters you set are sent.
  • company_events — everything filed on one company, across all streams. company is a ticker or a CIK; since and limit page the result.
  • get_event — show everything on one event, by its event_id (for example insider_cluster:CAMP:2026-08-03).
  • list_event_types — which fields each stream carries, and whether its score can be recomputed. Works without a key.
  • feed_health — how current each stream is right now. Works without a key.
  • usage — how much of the monthly event allowance is used, and when it resets.
  • check_setup — whether the API key is configured and whether the feed answers. Always answers with a JSON object {key_configured, feed_reachable, detail}; the key value is never printed and no key is sent by the check itself.

Behaviour worth knowing:

  • A quota-exhausted feed does not throw an error mid-sync: it answers a 200 empty page with your cursor intact and a plain notice, and signalfeed passes it through like any other page.
  • The API scales to zero when idle. The first request after a quiet period may get a starting_up answer (with a Retry-After header) while it wakes, which can take about fifteen seconds; signalfeed returns that body as a normal result rather than an error, and the call is not counted against your allowance. Just call again.
  • Any other non-2xx reply fails with datasignals error: HTTP <status>, and an unreachable API with datasignals unreachable.

Endpoint provenance

The vendor's Events API page pins the endpoints, the filter names, the cursor model and the twelve stream ids; the original MCP project's README pins the seven tools, both environment variables, the Bearer-header auth rule and the two keyless tools. The MCP-layer argument names follow the documented API names (a labelled reconstruction, since the MCP layer itself is unpublished):

  • GET <base>/v1/events with only the set filters as query parameters (used by search_events).
  • GET <base>/v1/companies/{ticker or cik}/events with since/limit when set (used by company_events).
  • GET <base>/v1/events/{event_id} (used by get_event).
  • GET <base>/v1/event-types (used by list_event_types, keyless).
  • GET <base>/v1/health (used by feed_health, keyless, and by check_setup).
  • GET <base>/v1/usage (used by usage).

event_id and company path segments are URL-encoded.

CLI

Each tool is a subcommand taking one JSON argument string:

bash
npx @reneturcios/signalfeed search_events '{"event_type":"fda_action","min_score":70}'npx @reneturcios/signalfeed company_events '{"company":"NVDA"}'npx @reneturcios/signalfeed get_event '{"event_id":"insider_cluster:CAMP:2026-08-03"}'npx @reneturcios/signalfeed list_event_types '{}'npx @reneturcios/signalfeed feed_health '{}'npx @reneturcios/signalfeed usage '{}'npx @reneturcios/signalfeed check_setup '{}'npx @reneturcios/signalfeed --version

Output is the tool's result text (the upstream body on success). Exit codes: 0 on success, 1 on a runtime error, 2 on a usage error.

MCP server

bash
npx -y @reneturcios/signalfeed mcp

MCP client config:

json
{  "mcpServers": {    "signalfeed": {      "command": "npx",      "args": ["-y", "@reneturcios/signalfeed", "mcp"],      "env": {        "DATASIGNALS_KEY": "<your key>"      }    }  }}

Docker

bash
docker run -i ghcr.io/cloudcorprecords/signalfeeddocker run --rm ghcr.io/cloudcorprecords/signalfeed feed_health '{}'

Development

bash
npm installnpm run build   # tsc -> dist/npm test        # tsx --test test/*.test.ts (fake fetch only, no network)npm run dev     # run the CLI from source

License

MIT — Copyright (c) 2026 Rene Turcios

来源:README.md,提交 8f89d1a

工具

7

search_events

Search filing events across all twelve streams; filter by event type, ticker, CIK or minimum score, and page with a cursor.

输入参数ciklimitsincetickermin_scoreevent_type

company_events

Everything filed on one company, across all streams.

输入参数limitsincecompany必填

get_event

Show everything on one event, by its event_id.

输入参数event_id必填

list_event_types

Which fields each stream carries, and whether its score can be recomputed. Works without a key.

无需输入参数。

feed_health

How current each stream is right now. Works without a key.

无需输入参数。

usage

How much of the monthly event allowance is used, and when it resets.

无需输入参数。

check_setup

Whether the API key is configured and whether the feed answers.

无需输入参数。

版本历史

1
  1. v0.1.0最新Nov 4, 2026

评分

已满足适用检查项的 90%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分
  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分