The Catalyst Edge MCP server provides source-linked market intelligence for AI agents, delivering deterministic catalyst evidence dossiers and immutable source records for public-company tickers (including ETFs like SPY, QQQ).
Tools:
catalyst_edge_score: Returns a compact dossier with a 0-100 score, direction (bullish/bearish/neutral), confidence, and evidence summary (headline, what changed, why it matters, what would invalidate). Evidence is categorized by families (SEC filings, insider trading, GDELT Web NGrams, issuer feeds, Bluesky social attention, options flow, technical analysis) and includes strength, confidence, source quality, and change descriptions. Reports data quality (coverage, missing/stale families, warnings) and suggests next checks. Configurable lookback (1-90 days), risk modes (research, alert_triage, thesis_review), and options to include/exclude sources or raw signals. Handles missing data gracefully (neutral score, not bearish).
catalyst_edge_claim_sources: Pages through immutable source records for a grouped claim (identified by claim_id), returning up to 20 sources per page with cursor-based pagination. Each record includes source ID, name, tier, URL, timestamps, SHA-256 hash, parser version, and policy decision.
Key characteristics: Read-only, deterministic and unbacktested scoring, full source provenance, typed missingness (never treats missing data as bearish), local/offline operation via stdio or HTTP, and explicit disclaimers (no investment advice).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Catalyst Edge MCP Show me the catalyst dossier for RKLB"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Source-linked market intelligence for AI agents.
Catalyst Edge is a local, read-only Model Context Protocol server for public-company research. Ask an agent what changed for a ticker, why it matters, what contradicts it, and which sources support the answer.
It combines direct SEC filings and ownership records with optional, policy-gated sources into a compact evidence dossier. Every result preserves its source links and missing-data warnings.
Local first. Evidence and configuration stay on your machine. Research only. The deterministic scorer is untrained and unbacktested; Catalyst Edge does not provide investment advice, trading signals, or execution.
Catalyst Edge requires Python 3.10+ and uv.
The SEC requires an identifiable User-Agent; use your organization and a monitored
email address.
codex mcp add catalyst-edge \
--env 'CATALYST_EDGE_SEC_USER_AGENT=YOUR_ORGANIZATION YOUR_EMAIL' \
--env 'CATALYST_EDGE_EVIDENCE_STORE=/absolute/local/path/evidence.sqlite3' \
-- uvx --from 'catalyst-edge-mcp==0.1.8' catalyst-edge-mcpStart a fresh task and verify that Codex discovers these two tools:
Tool | Use |
| Return a compact catalyst-evidence dossier for a ticker. |
| Page through the immutable source records behind a claim. |
Download catalyst-edge-mcp-0.1.8.mcpb,
then choose Settings → Extensions → Advanced settings → Install Extension….
Enter the same SEC identity when prompted. The extension is an unsigned custom bundle;
review the source and published checksum before accepting Claude Desktop's warning.
Related MCP server: edgar-events-mcp
Ask your agent a focused research question, for example:
What changed for NVDA in the last 14 days? Include sources, missing evidence, and anything that would weaken the conclusion.
The primary tool accepts a ticker, a 1–90 day lookback, source inclusion, and a research context:
{
"ticker": "NVDA",
"lookback_days": 14,
"include_sources": true,
"include_raw_signals": false,
"risk_mode": "research"
}risk_mode also supports alert_triage and thesis_review. Ticker validation runs
before any provider is composed; invalid inputs fail clearly rather than producing a
partial score.
# Run the local stdio MCP server
uvx --from 'catalyst-edge-mcp==0.1.8' catalyst-edge-mcp
# Get a dossier directly
uvx --from 'catalyst-edge-mcp==0.1.8' catalyst-edge-score NVDA --lookback-days 14Evidence | Default | Notes |
SEC filings and ownership records | Enabled with | Primary regulatory evidence. |
GDELT Web NGrams discovery | Enabled | Attributed, cache-only discovery metadata; set |
Issuer RSS/Atom feeds | Disabled | Enable explicitly with |
Bluesky public attention | Disabled | Enable explicitly with |
Options, technicals, and sentiment | Disabled | Not composed without an approved, rights-cleared provider. |
The default evidence store is local SQLite at
~/.local/state/catalyst-edge-mcp/evidence.sqlite3. Set
CATALYST_EDGE_EVIDENCE_STORE to choose another local path.
CATALYST_EDGE_SEC_USER_AGENT='YOUR_ORGANIZATION YOUR_EMAIL' \
uvx --from 'catalyst-edge-mcp==0.1.8' catalyst-edge-smoke NVDA --lookback-days 14The smoke check reports sanitized configuration, provenance, coverage, and readiness status. It never prints credentials or provider payloads.
Each dossier includes a deterministic score, direction, confidence, source-linked
evidence, missing or stale families, and next checks. research.disposition tells an
agent whether to review the evidence now, monitor it, or report insufficient evidence;
it prioritizes research only and is not a trade signal. model_status is always
not_trained in this release. A neutral or no-data result is a valid answer: missing
evidence is uncertainty, not bearish evidence.
Evidence is compact by design. Use catalyst_edge_claim_sources with a claim ID to
retrieve its paginated source records, including canonical URLs, timestamps, hashes,
parsers, and policy decisions.
{
"ticker": "NVDA",
"edge": {"score": 62, "direction": "bullish", "confidence": 0.69, "scoring_method": "deterministic_v1", "model_status": "not_trained"},
"research": {"disposition": "review_now", "primary_claim_id": "clm_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "supporting_claim_ids": [], "contradicting_claim_ids": [], "blocking_gaps": [], "next_action": "Open SEC accession 0001045810-26-000001 and review the filed item text and exhibits."},
"data_quality": {"coverage": "partial", "missing_families": [], "warnings": ["Deterministic v1 scoring is not backtested."]}
}{
"ticker": "NVDA",
"edge": {"score": 50, "direction": "neutral", "confidence": 0, "scoring_method": "deterministic_v1", "model_status": "not_trained"},
"research": {"disposition": "monitor", "primary_claim_id": null, "supporting_claim_ids": [], "contradicting_claim_ids": [], "blocking_gaps": ["options_flow"], "next_action": "Check whether a sector-wide event explains the observation."},
"data_quality": {"coverage": "none", "missing_families": ["options_flow"], "warnings": ["options_flow provider yfinance is private diagnostic only; no production evidence or coverage credit was granted."]}
}{
"ticker": "NVDA",
"edge": {"score": 50, "direction": "neutral", "confidence": 0, "scoring_method": "deterministic_v1", "model_status": "not_trained"},
"research": {"disposition": "insufficient_evidence", "primary_claim_id": null, "supporting_claim_ids": [], "contradicting_claim_ids": [], "blocking_gaps": ["filings_news", "insider_trading", "options_flow", "social", "technical"], "next_action": "Retry with lookback_days=30 to check a wider filing window."},
"data_quality": {"coverage": "none", "missing_families": ["filings_news", "insider_trading", "options_flow", "social", "technical"], "warnings": ["No live evidence adapters are configured."]}
}Results and SQLite evidence remain on your machine. Ticker and issuer queries may be
sent directly to whichever public-source providers you enable. The SEC identity is sent
only to sec.gov as its required request User-Agent.
Read the Catalyst Edge Privacy Policy.
uv sync --frozen --extra dev
uv run --frozen pytest
uv run --frozen ruff check .
uv build --no-sources --out-dir distDefault tests are offline and use sanitized fixtures. The release workflow tests Python 3.10 and 3.14, MCP contracts, a clean build, and the packaged artifact.
Use with a dossier claim ID to read one bounded page of its immutable source records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| claim_id | Yes |
| Name | Required | Description |
|---|---|---|
| cursor | Yes | |
| sources | No | |
| claim_id | Yes | |
| next_cursor | No | |
| attributions | No | |
| total_sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context by noting the records are 'immutable' and that results are a 'bounded page,' which clarifies pagination behavior and data characteristics. This adds value beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. There is no fluff or redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only paginated tool with an output schema, the description covers the essential usage (claim ID, bounded page). It does not explain how to navigate to subsequent pages via cursor, but that is inferable from the schema. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly references claim_id via 'dossier claim ID' and hints at pagination via 'bounded page,' but it does not explicitly explain limit or cursor semantics. The schema provides names, types, defaults, and constraints, which helps, but the description adds only marginal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('read'), the target resource ('source records'), and the scope ('grouped claim sources'), and it requires a dossier claim ID. This distinguishes it from the sibling tool 'catalyst_edge_score', which likely performs scoring rather than reading sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage context by specifying it must be used with a dossier claim ID and that it returns a 'bounded page' (implying pagination). However, it does not explicitly state when to use this tool instead of alternatives or provide any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for ticker research to assess recent evidence, provenance, and next checks.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| risk_mode | No | research | |
| lookback_days | No | ||
| include_sources | No | ||
| include_raw_signals | No |
| Name | Required | Description |
|---|---|---|
| edge | Yes | |
| as_of | Yes | |
| ticker | Yes | |
| summary | Yes | |
| evidence | Yes | |
| next_checks | Yes | |
| attributions | No | |
| data_quality | Yes | |
| lookback_days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about what the tool evaluates (evidence, provenance, next checks), which goes beyond the annotations and is consistent with them. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise and front-loaded. However, it is under-specified relative to the tool's complexity, omitting parameter details and decision context, so it is not appropriately sized for the information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, an enum risk_mode, and no parameter descriptions in either the schema or the description, the description is incomplete. It does not explain the meaning of risk_mode values, how lookback_days affects results, or when to use this tool versus the sibling catalyst_edge_claim_sources. The existence of an output schema helps with return values but not with parameter selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters: ticker, risk_mode (an enum), lookback_days, include_sources, or include_raw_signals. The phrase 'ticker research' implicitly relates to ticker but fails to define the semantics of the other parameters, leaving the agent without necessary guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for ticker research to assess recent evidence, provenance, and next checks, which is a specific action on a specific resource. It implicitly distinguishes from the sibling tool claim_sources by focusing on assessment rather than source retrieval, though the name's 'score' and 'edge' are not explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use for ticker research' provides a clear context for when to apply the tool. However, it does not mention when not to use it, nor does it reference the alternative sibling tool catalyst_edge_claim_sources, so exclusion and alternative guidance are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct function: one for generating/assessing research scores on a ticker, the other for retrieving source records for a specific claim ID. No overlap in purpose or inputs.
Both tools share the 'catalyst_edge_' prefix and use snake_case with a clear noun structure. The pattern is consistent and predictable, making it easy to infer each tool's role.
With only two tools, the server has a minimal but plausible scope. While each tool clearly serves a distinct purpose, the very low number makes the set feel thin and raises expectations for more coverage.
The two tools cover a core research workflow (get score, then read claim sources), but the server lacks other potentially useful operations such as listing dossiers or searching claims. Given the apparent narrow domain, the surface is reasonably complete for a read-only assistant, though a bit minimal.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Verify stock theses against public filings with a source-backed evidence ledger.
Read-only tokenized stock data: issuers, chains, contract addresses and corporate actions.
Audited SEC catalyst signals for agents — ranked filing intel with a public track record. Free tier.
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rm0nroe/catalyst-edge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
