Click on "Deploy 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., "@WhaleSignal MCP What's the conviction score on AMZN right now?"
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.
Turn raw Unusual Whales data into one decision-ready conviction score — spoken in plain English to any AI.
Conviction heatmap rendered by scripts/render_heatmap.py from the actual /api/rank --demo output (same code the web dashboard serves). Run python -m whalesignal.web --demo for the interactive version. Full terminal tour: docs/DEMO.md.
Unusual Whales already ships a great hosted MCP that returns raw data. WhaleSignal goes one step further: it fuses six Unusual Whales datasets into a single explainable 0–100 conviction score per ticker, so an LLM (or a human) gets an answer, not a spreadsheet.
Ask Claude / Cursor / ChatGPT: "What's the conviction on AMZN?" and get this (actual --demo output):
== AMZN — Strong Bullish (BULLISH) ==
[#########################-----] 83.1/100 coverage 100%
sub-signals:
- options_flow_alerts +0.68 w=0.30
- net_premium +1.00 w=0.28
- options_volume +0.84 w=0.14
- dark_pool +0.09 w=0.12
- gamma_regime +0.50 w=0.10
- congress +0.00 w=0.06
why:
* net_premium: bullish (+1.00)
* options_flow_alerts: bullish (+0.68)
* options_volume: bullish (+0.84)
* gamma_regime: bullish (+0.50)
* dark_pool: bullish (+0.09)Numbers above are deterministic synthetic demo data (seeded per ticker), reproducible with
python -m whalesignal.cli AMZN --demo. Different tickers produce different scores; e.g.NVDAis24.3 / Strong Bearish.
It's an answer, not a dump. Judges see instant, explainable signals — every score ships with a per-signal breakdown and a rationale. No black boxes.
Data fusion is the moat. Options flow alerts + net premium + call/put volume + dark pool accumulation + dealer gamma regime + congressional trades, blended with tunable weights.
Fails honestly. A bad/expired token (401) surfaces as an error — never a fake neutral score. Permission-gated (403) or transient endpoint failures drop just that one sub-signal and weights renormalise. The score never silently lies.
Correct aggregation. Cumulative intraday series (net premium, Market Tide) use the latest snapshot, not a sum of snapshots.
Honest math. Where directionality is ambiguous (dark pool without NBBO, gamma magnitude), we use conservative sign-only contributions instead of fake precision.
Uses real endpoints only. Built straight off the official skill.md whitelist — zero hallucinated routes, correct Authorization + UW-CLIENT-API-ID: 100001 headers, all GET.
Proven against real payloads. The extractors read the actual UW field names (total_ask_side_prem, call_gamma_oi, amounts ranges …); tests replay the official example responses through the real UWClient (via httpx.MockTransport) — the same code path live data uses.
Bounded & efficient. A MAX_TICKERS cap plus a shared (fetch-once) congressional feed and a concurrency semaphore keep a batch from bursting the rate limit.
Tested logic. 34 tests, all runnable with no API key and no network.
Related MCP server: Infoway MCP Server
Sub-signal | Endpoint | What it measures |
|
| Aggressive call vs put whale premium |
|
| Cumulative net call vs net put premium |
|
| Call/put volume balance (P/C ratio) |
|
| Accumulation vs distribution off-exchange |
|
| Dealer long/short gamma (stability) |
|
| Recent congressional buys vs sells |
Weights live in whalesignal/config.py (ConvictionWeights) — tune to taste.
WhaleSignal ships a demo mode: a deterministic synthetic data source with the exact
same interface as the live client, so the whole fetch -> fuse -> score pipeline runs
offline. Great for demos and CI; output is clearly stamped ** DEMO DATA **.
git clone https://github.com/kvandre12-commits/whalesignal-mcp.git
cd whalesignal-mcp
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
python -m whalesignal.cli NVDA AAPL TSLA AMZN MSFT --demoWhaleSignal ranking (5 tickers, best first):
1. AMZN 83.1 Strong Bullish
2. AAPL 77.0 Strong Bullish
3. MSFT 53.4 Neutral / Mixed
4. NVDA 24.3 Strong Bearish
5. TSLA 23.2 Strong Bearishpython -m whalesignal.cli --brief --demo # default watchlist
python -m whalesignal.cli NVDA AMD AMZN --brief --demoWhaleSignal Market Briefing - 2026-09-18 [DEMO DATA - synthetic, not live]
========================================================
Market pulse: RISK-ON / BULLISH. Net call premium $4.62M, net put premium -$4.60M.
Whales leaning bullish: AMZN (83), AMD (82), AAPL (77).
Whales leaning bearish: NVDA (24), TSLA (23), META (20).
Top conviction: AMZN - Strong Bullish (83.1/100). net_premium: bullish (+1.00); options_flow_alerts: bullish (+0.68).
Congress desk: 19 buys vs 10 sells recently. Notable: Buy NVDA ($100,001 - $250,000); ...A zero-dependency (stdlib-only) single-page dashboard: a bullish/bearish heatmap of your watchlist plus the live market briefing. Click any tile for its sub-signal breakdown and rationale.
python -m whalesignal.web --demo # then open http://127.0.0.1:8000
python -m whalesignal.web --port 8000 # live (needs UW_API_KEY)Endpoints (reuse the same analysis code as the CLI + MCP server):
GET /, GET /api/rank?tickers=..., GET /api/briefing?tickers=....
cp .env.example .env
# edit .env and set UW_API_KEY=<your token>
python -m whalesignal.cli NVDA
python -m whalesignal.cli NVDA AAPL TSLA --rank --top 3python -m whalesignal.server # live (needs UW_API_KEY)
WHALESIGNAL_DEMO=1 python -m whalesignal.server # demo data, no key neededAdd to your MCP client config (adjust the absolute paths):
{
"mcpServers": {
"whalesignal": {
"command": "/data/data/com.termux/files/home/uw-challenge/.venv/bin/python",
"args": ["-m", "whalesignal.server"],
"env": { "UW_API_KEY": "your-uw-api-token" }
}
}
}Then ask: "Use whalesignal to rank my watchlist: NVDA, AMD, TSLA, PLTR."
Tool | Description |
| Full fused 0–100 conviction with breakdown + rationale |
| Rank several tickers, highest conviction first |
| One-call written daily brief: market pulse + ranked watchlist + notable congress trades |
| Raw unusual options flow alerts |
| Recent dark pool prints |
| Overall market sentiment from Market Tide |
| Recent congressional trades |
whalesignal/
config.py # single source of truth: base URL, endpoints, weights
client.py # async UW API client (auth, retries, data unwrap) + client factory
demo.py # DemoClient: deterministic synthetic data, same interface as client
signals.py # PURE scoring math — no network, fully unit-tested
analysis.py # concurrent fetch + fuse (the I/O + logic seam)
briefing.py # market_briefing: pure summarizers + composer, async orchestrator
server.py # thin MCP adapter (works on mcp 1.x FastMCP and 2.x MCPServer)
cli.py # human-friendly terminal demo
web.py # stdlib-only dashboard server (heatmap + JSON endpoints)
dashboard.html# single-page heatmap front-end (no build step, no CDN)
tests/
test_signals.py # pure scoring math (no key, no network)
test_demo_pipeline.py # full fetch->fuse pipeline via DemoClient
test_briefing.py # briefing summarizers + composer
test_web.py # web ticker parsing + asset presence
test_fixtures.py # REAL API example payloads -> signals + UWClient (MockTransport)
fixtures/*.json # official UW example responses (real field names/envelopes)
scripts/
demo.sh # guided terminal tour (synthetic data)
render_heatmap.py # render the heatmap SVG from real /api/rank outputpython tests/test_signals.py # standalone, no deps, no key, no network
pytest -q # or, with pytest installed (34 tests)
ruff check whalesignal tests # lint (config in pyproject.toml)
./scripts/demo.sh # full guided demo tour on synthetic data34 tests, no API key and no network required:
Pure scoring math on hand-built cases.
Full demo pipeline (fetch -> fuse) via DemoClient.
Live-compatibility fixtures — the official UW example payloads (real field names
and envelopes) replayed through the pure signals and through the real UWClient
using httpx.MockTransport, verifying auth headers + data unwrap + correct field reads.
Briefing composer and web layer.
WhaleSignal is an analytics tool, not financial advice. Signals are heuristics over market data and can be wrong. Do your own research.
Recent congressional trades, optionally filtered to one ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key behaviors 'recent' and 'optionally filtered to one ticker' despite absent annotations. It does not define what 'recent' means, how results are ordered, or what happens when ticker is omitted, leaving room for stronger disclosure.
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?
One concise sentence with no filler. The key qualifiers 'recent' and 'optionally filtered to one ticker' are front-loaded and 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 two-parameter, non-nested read tool with an output schema, the description covers the core operation and ticker behavior. It remains slightly ambiguous on the recency window and limit semantics, but those are minor for tool selection and invocation.
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?
The description explains the ticker parameter's purpose, adding value beyond the raw schema. The limit parameter is not described at all, though its name and default of 50 make its purpose inferable; at 0% schema coverage the description could have done more.
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?
Clearly identifies the resource (congressional trades) and a scoping behavior (filter by ticker), which differentiates it from the sibling tools. Lacks an explicit verb such as 'get' or 'list', so it stops short of the strongest 5 rating.
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?
No when-to-use guidance or alternative tools are mentioned. The intended context is implied by the resource name and the optional ticker filter, but the description never says why an agent should choose this over sibling tools like flow_alerts or dark_pool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Composite 0-100 bullish/bearish conviction for a ticker.
Fuses options flow alerts, net premium, call/put volume, dark pool accumulation, dealer gamma regime and recent congressional trades into one explainable score with per-signal breakdown and a plain-English rationale.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does it well: it states that the tool fuses multiple signals, outputs an explainable score, and provides a per-signal breakdown plus plain-English rationale. It does not cover data freshness, limitations, or failure behavior, but the core behavior is clearly conveyed.
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 tight and front-loaded: the main output phrase appears first, followed by a compact list of signal inputs and deliverables. Every phrase adds information and there is no filler.
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?
The description conveys purpose, composition, and output shape, and an output schema exists to handle the return-structure burden. The main omissions are an explicit statement of score direction (whether high values mean bullish or bearish) and more direct routing among the sibling tools.
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?
The only parameter is ticker, and schema description coverage is 0%, so the description needed to add format, scope, or usage clarification. It only repeats the word 'ticker' and gives no guidance on ticker format, asset class, or how to specify symbols.
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 opening line defines a specific deliverable: a 0-100 bullish/bearish conviction score for a ticker. The description enumerates the fused signal sources, which clearly distinguishes it from the single-source siblings such as flow_alerts, dark_pool, and congress_trades.
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 description implies use when an aggregate conviction signal is needed by listing the underlying components, but it never explicitly states when to choose this tool over flow_alerts, dark_pool, congress_trades, or market_pulse. No exclusions or decision conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent dark pool prints for a ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Recent dark pool prints for a ticker' and gives no information about data source, ordering, delay, read-only guarantees, rate limits, or what the output represents. This is effectively no behavioral transparency.
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, front-loaded sentence with no filler. Every word ('Recent', 'dark pool prints', 'for a ticker') is relevant. It is appropriately concise for its content, even though that content is thin.
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 tool with no annotations and a minimal description, this is incomplete. Even though the output schema covers return values, the description lacks usage guidance, parameter semantics for 'limit', and any behavioral context. It would not fully prepare an agent to call this tool correctly in a multi-tool environment.
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 explain the parameters. It implicitly mentions 'ticker' but completely ignores the 'limit' parameter, leaving the agent to guess what it controls (likely max number of prints, but this is not stated). The description adds no meaningful semantics beyond the schema.
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 states a specific resource (dark pool prints) and scope (a ticker), and it is clearly distinct from siblings like flow_alerts or conviction_score. However, it is a noun phrase rather than an explicit action statement (e.g., 'get recent dark pool prints'), so it leaves the verb to inference.
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 description gives no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or how it differs from sibling tools like flow_alerts or market_pulse, so an agent cannot route to it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raw unusual options flow alerts for a ticker (whale trades).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| min_premium | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. The word 'raw' and parenthetical 'whale trades' hint at unprocessed, large-trade alerts, but the description does not state ordering, recency, threshold behavior, or how the result set is shaped. This is minimal, though not contradictory.
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 short, front-loaded, and free of filler, but it is more of a title than an operational description. Every word earns its place, yet the brevity crosses into under-specification, so it is adequate but not exemplary.
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?
Although an output schema exists and the domain phrase adds context, the tool has no annotations, 0% parameter coverage, and no usage guidance. For a 3-parameter data-retrieval tool, the description leaves an agent without critical operational details.
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 explain ticker, limit, and min_premium. It only mentions 'for a ticker' generically and never describes the limit's effect or the $50,000 min_premium default. An agent cannot infer parameter semantics from the description.
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 identifies the specific resource: raw unusual options flow alerts for a given ticker, and clarifies with 'whale trades.' It lacks an explicit verb like 'retrieves' or 'returns,' but the noun-phrase style is unambiguous and differentiates from siblings such as dark_pool and congress_trades by focusing on ticker-level options flow.
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?
No guidance is provided on when to use this tool rather than dark_pool, market_pulse, or conviction_score. The only hint is implicit: use it for ticker-specific unusual options flow, but there are no exclusions, prerequisites, or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call plain-English daily market brief.
Blends Market Tide sentiment, WhaleSignal conviction ranking over a watchlist,
and notable congressional trades into a written narrative plus structured data.
Pass your own tickers list or use the default liquid-name watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| tickers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output format (written narrative plus structured data), the default watchlist behavior, and the ability to pass custom tickers. It does not mention side effects, freshness, or cost, but those are less critical for a read-only aggregation tool.
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?
Three tight sentences: the first states the purpose, the second lists data sources and output type, the third handles the only meaningful parameter choice. Nothing is redundant.
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?
The tool has an output schema, so return values don't need elaboration. However, the description is still missing `top` semantics and explicit guidance on when to prefer the aggregated briefing over the individual sibling tools, leaving minor but real gaps.
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 coverage is 0%, so the description must explain parameters. It explains `tickers` (custom list or default watchlist) but not `top`, leaving the agent to guess what 'top' controls, likely a limit or count.
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?
Description states a clear deliverable: a single-call plain-English market brief that blends multiple signal sources into narrative plus structured data. This distinguishes it from sibling tools, which are focused individual signals rather than an aggregate briefing.
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 description implies this is the consolidated starting point ('One-call', 'Blends...') and mentions custom tickers, but it never explicitly says when to call this instead of conviction_score, rank_watchlist, congress_trades, etc., or when those specialized alternatives would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overall market sentiment from Unusual Whales Market Tide (net premium flow).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only states the data source and what it measures, but doesn't mention that it's a read-only operation, any output format, or limitations. Since it's a simple data retrieval, the risk is low, but the description still lacks explicit behavioral transparency.
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?
Single sentence, to the point, no filler. Front-loaded with the key purpose.
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 zero-parameter tool with an output schema, the description is sufficient to convey the essence. It doesn't need to explain return values since an output schema exists. It could mention that it's a snapshot of current sentiment, but it's adequate.
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?
The tool has no parameters, so schema coverage is trivially 100%. The description adds context by explaining the data source and meaning, which helps interpret the output. Baseline of 4 is appropriate.
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 provides overall market sentiment based on a specific source (Unusual Whales Market Tide, net premium flow). It distinguishes from siblings like conviction_score (likely per-stock) and market_briefing (broader briefing), though it doesn't explicitly name alternatives.
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?
No guidance on when to use this tool versus alternatives like market_briefing or flow_alerts. The description is purely informational and doesn't mention contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank a watchlist of tickers by WhaleSignal conviction score (highest first).
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| tickers | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the essential behavior: ranking and sorting by conviction score highest first. With no annotations, the description does not mention how invalid tickers are handled, whether 'top' affects the result set, or any other operational caveats, though the output schema covers the return shape.
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 sentence with no filler, and the key ordering behavior is front-loaded. It is concise without sacrificing clarity.
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?
The description is adequate for a simple two-parameter ranking tool, especially with an output schema present, but it leaves the agent to infer the meaning and impact of the optional 'top' parameter and to distinguish usage from conviction_score without explicit guidance.
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 carries the parameter semantics burden. 'tickers' is partially explained by the phrase 'watchlist of tickers,' but the 'top' parameter is not explained at all and its behavior is left entirely to the schema.
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 states a specific action and resource: rank a watchlist of tickers by WhaleSignal conviction score, with an explicit ordering (highest first). This clearly differentiates it from sibling tools like conviction_score, which implies a single-score lookup rather than batch ranking.
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?
No guidance is given for when to use this tool versus alternatives such as conviction_score, flow_alerts, or market_pulse. The agent must infer the intended use from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2congress_tradesconviction_scoredark_poolflow_alertsmarket_briefingmarket_pulserank_watchlistScored across 7 tools
Each tool has a distinct primary role: raw signal viewers (flow_alerts, dark_pool, market_pulse, congress_trades), composite scoring (conviction_score), ranking (rank_watchlist), and narrative output (market_briefing). The only mild overlap is that market_briefing includes ranking and congressional-trade data, but its output format and intent are clearly different.
The naming styles are mixed: rank_watchlist uses verb_noun, while most others use noun or noun_noun forms like flow_alerts, dark_pool, and market_briefing. Snake_case is consistent, but the lack of a uniform verb or part-of-speech pattern makes the set feel somewhat ad hoc.
Seven tools is a well-scoped size for a market-intelligence server. Each tool maps to a meaningful capability without redundancy or bloat.
The surface covers raw whale-flow data, market sentiment, congressional trades, composite conviction scores, watchlist ranking, and a briefing. Minor gaps exist around deeper drill-downs, such as standalone dealer-gamma or historical conviction breakdowns, but core workflows are not blocked.
Unified financial infrastructure connecting AI agents directly to trade live/demo brokerage accounts, Web3 non-custodial wallets, real-time market data across equities, ETFs, crypto, forex, options, DeFi swaps, and prediction markets, institutional research feeds, and algorithmic strategy backtesters.
Options analytics for AI assistants: chains, IV rank, VRP, Greeks, GEX, expected moves, screeners.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
