Free, no-key MCP connector for market data in Claude, Cursor and any Streamable HTTP client. Six tools: a pre-market and after-hours gapper scanner (get_premarket_gappers: top 10 names up 10% or more, $1-$100, float under 100M, with premarket relative volume, ATR, RSI and a news-catalyst flag), plus the Market Health desk: S&P 500 valuation verdict (get_market_valuation), Fed liquidity and yield-curve series (get_macro_liquidity), cross-asset regime (get_cross_asset_regime), market breadth (get_market_breadth) and risk-score history (get_market_health_history). Ships with a ready-made prompt, premarket_gappers_brief. Nothing to sign up for. Built by TraderMatrix. The full TraderMatrix connector has 51 tools, adding options flow, dealer gamma and Apex levels, unusual activity, sector flow, wheel screeners and your own watchlists.
Scored across 6 tools
Each tool covers a distinct analytical lens: cross-asset correlations, macro/liquidity series, index breadth, health history, valuation, and gapper scanning. The boundaries between get_market_breadth, get_market_health_history and get_cross_asset_regime are conceptually adjacent (all 'market condition' reads), but the descriptions make each output set explicit enough to prevent misselection.
All six tools follow an identical get_<snake_case_noun_phrase> pattern (get_cross_asset_regime, get_macro_liquidity, get_premarket_gappers). No mixing of camelCase, verbs, or stylistic variants.
Six tools is a compact, well-scoped set with no redundant entries, appropriate for a free preview endpoint. It is somewhat thin relative to the full market-analysis domain (the server itself advertises a 51-tool paid connector), which keeps it just below a 5.
Coverage of the stated free-tier purpose (gappers + macro/breadth/valuation health) is coherent, but every tool is parameterless, so an agent cannot filter, force a session, target a specific symbol, or retrieve more than the top 10 gappers. There is no per-ticker lookup or drill-down path, leaving agents at a dead end once a gapper symbol is identified.
Cross-asset regime read, derived values only: 60-session stock-bond and dollar-stock return correlations (-1..1), 20-session percent changes of the gold/S&P ratio, copper/gold ratio and WTI crude, the VIX/VIX3M ratio with a contango / backwardation word (above 1.0 = backwardation), and the MOVE/VIX ratio (rate vol vs equity vol). Raw index and commodity levels are not published; a leg that cannot be computed is null and named in unavailable[]. Self-caching (15 min). No parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: outputs are derived values only with raw index/commodity levels withheld, uncomputable legs are returned as null and named in unavailable[], results are self-cached for 15 minutes, and the contango/backwardation threshold is spelled out (above 1.0 = backwardation). These are exactly the details an agent needs to interpret results correctly.
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?
Every clause carries information — metric list, interpretation threshold, null handling, caching — with nothing redundant. The opening sentence is long and densely packed, but the critical scoping fact (derived values only, no raw levels) is front-loaded.
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 no output schema and no parameters, the description carries the full burden and discharges it: it defines each returned quantity, the sign range for correlations, null/unavailable semantics, and caching behavior. An agent can interpret the response without any further documentation.
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?
Zero parameters, so the baseline is 4. The description explicitly confirms 'No parameters,' matching the empty schema, and no additional parameter meaning is needed.
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?
Names a specific resource (cross-asset regime) and enumerates the exact derived signals returned: 60-session stock-bond and dollar-stock correlations, gold/S&P and copper/gold ratio changes, WTI, VIX/VIX3M, MOVE/VIX. That enumeration makes it unmistakable against siblings like get_market_valuation or get_market_breadth, which cover different analytical territory.
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 explicit when-to-use, when-not-to-use, or named alternative among the sibling tools is given. Usage is implied by the content (a cross-asset regime snapshot), which is adequate but leaves the agent to infer when this beats get_macro_liquidity or get_market_valuation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US-government macro and liquidity series: Fed net liquidity (balance sheet minus Treasury General Account minus reverse repo, USD trillions, weekly, with the 4-week percent change), 10-year real yield, 10-year breakeven inflation, 5y5y forward inflation and the effective fed funds rate (percent, each with its prior value and date), the Treasury yield curve (1M-30Y) with the 10Y-2Y spread history (percentage points, negative = inverted), private nonresidential fixed investment (CAPEX, USD billions SAAR) and CFTC E-mini S&P 500 positioning by trader class (net contracts). Federal Reserve, NY Fed, Treasury, BEA, CFTC and Chicago Fed sources only; third-party-licensed credit-spread series are not included. Self-caching (6 h). No parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already covering readOnly/idempotent/non-destructive/closed-world, the description adds real value beyond them: 'Self-caching (6 h)' tells the agent data may be up to six hours stale, and the source restriction (Fed, NY Fed, Treasury, BEA, CFTC, Chicago Fed only; no third-party credit-spread series) bounds what will never appear. It stops short of describing response shape or freshness guarantees beyond the cache window.
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?
Front-loaded with the resource name, then a dense enumeration where each clause carries a unit, frequency, or coverage constraint that earns its place. It is long and reads as one packed run-on, but little is genuinely wasteful.
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?
No output schema exists, so the description must convey what comes back, and it does: series list, units, frequency, prior-value fields, and the 10Y-2Y spread sign convention. The remaining gap is the response envelope (whether all series return in one object or separately), which an agent would want before parsing.
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?
There are zero parameters and the description states 'No parameters', consistent with the empty schema. Baseline is 4 for a no-param tool; nothing further is needed or missing here.
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?
Names a specific resource and then enumerates exactly what it contains (Fed net liquidity, real yield, breakevens, yield curve, CAPEX, CFTC positioning) with units and frequencies. That content list makes it obvious this is a macro/liquidity feed rather than a breadth, valuation or gapper tool, though it never explicitly names a sibling.
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 usage by declaring the data domain and 'No parameters', so an agent knows it can be called unconditionally. It gives no explicit when-to-use/when-not-to-use guidance or pointer to an alternative tool among the five siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
S&P 500 breadth, derived aggregates only: the percent of index members above their 20-, 50- and 200-day moving averages (0-100), a breadth zone for the 50- and 200-day readings (washed_out / weak / mixed / healthy / extended), advancers and decliners, new 52-week highs and lows with the net count, the member count, and a one-sentence read. The index level and its change are not published. stale is true when the live read failed and the last stored close is served. Self-caching. No parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavioral details: only derived aggregates are published, index level and change are excluded, stale data behavior is defined, and the tool is self-caching. These details materially improve the agent's ability to interpret results and understand fallback behavior.
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 front-loaded with the resource and returned metrics, then adds only necessary behavioral caveats about index-level omission, stale data, caching, and parameter count. There is no filler or repetition.
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?
Given that there is no output schema and the tool has no parameters, the description provides a complete list of returned metrics plus stale and caching behavior. An agent has enough context to invoke and interpret the tool correctly.
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 takes zero parameters, and the description explicitly states 'No parameters,' matching the empty schema. With no parameters to document, the baseline for this dimension is satisfied.
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 identifies a specific resource: S&P 500 market breadth and its exact derived aggregates, including moving-average percentages, zones, advancers/decliners, and highs/lows. It does not explicitly differentiate this tool from the sibling tools such as get_market_health_history or get_market_valuation, so it falls short of a 5.
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 explains what the tool returns but gives no guidance on when to use it instead of alternatives. It does not mention sibling tools, use cases, or conditions for selecting this breadth read over related market-health tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market Health history: the composite risk-score snapshots for the last 30 days (hourly, with flips7d = label changes in the last 7 days), a ~30-session derived line series per detector (percent vs moving average, ratios vs their MAs, N-day percent changes and spreads — never raw prices), and signalChanges: which scored detectors changed status since the previous trading day's last snapshot. Every line carries a unit string. The junk-credit-spread detector has no lines (its source series is third-party licensed) and economic-calendar events are not included. Self-caching (15 min). No parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read profile, and the description layers on real operational context: self-caching for 15 minutes, no parameters (so no server-side filtering is possible), all values normalized rather than raw prices, every line carrying a unit string, and explicit data gaps (junk-credit-spread has no lines, economic-calendar events excluded). These caveats materially change how an agent should interpret the response and are not derivable from annotations.
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?
Front-loaded with the resource name followed by the payload breakdown, and every clause carries information. It is dense — nested parentheses and internal jargon like 'flips7d' and 'ratios vs their MAs' — but not padded.
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?
There is no output schema, so the description carries the full burden of describing return values, and it does: three named components, units on lines, normalization rules, caching, and known omissions. An agent can predict the response shape and limitations without inspecting anything else.
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?
Zero parameters, so the baseline is 4, and the description usefully confirms 'No parameters' — telling the agent there is no date-range, detector, or granularity control and the full 30-day payload is always returned. Nothing further is needed.
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?
States the specific resource (Market Health history) and enumerates the three payload components: composite risk-score snapshots, per-detector derived line series, and signalChanges. The dataset is clearly distinct from the sibling tools by content, though the description never names a sibling to disambiguate against get_market_breadth or get_cross_asset_regime.
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?
An agent can infer this is the historical/trend view (30-day window, hourly, 7-day flip counts) versus presumably current-state siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is implied by the data contents rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
S&P 500 valuation verdict from a discounted-earnings (equity-risk-premium) model: verdict (Very cheap / Cheap / Fair value / Rich / Very rich), the equity risk premium the market currently implies (impliedErpPct, in percent — lower means richer), the zone on the ladder, how far the market sits above (+) or below (-) the Fair value band in percent, and five ERP bands each with its erpPct, its fair value relative to the Fair value band, and the market's percent distance from it. All values are percentages; index-point fair values, the index level and the earnings inputs are intentionally not published. A model, not a forecast. Self-caching (30 min). No parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), and the description adds real context beyond them: 30-minute self-caching, all values are percentages, and index-point fair values, index level, and earnings inputs are deliberately withheld. That last disclosure usefully prevents an agent from asking for data that will never be returned.
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?
Front-loaded with the verdict and the model, then the return fields — appropriate ordering. It is one very long compound sentence, though, and the five-band enumeration makes it dense to parse; splitting into two or three sentences would cost nothing and read faster.
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 no output schema and no parameters, the description carries the full burden of describing return values and does so thoroughly: named fields, units, directional semantics ('lower means richer', '+'/'-' distance), and what is intentionally excluded. An agent knows exactly what it will receive and how to interpret it.
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?
Zero parameters, so the baseline of 4 applies; the description explicitly confirms 'No parameters,' removing any doubt about needing inputs. Nothing further is required.
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?
States a specific resource (S&P 500 valuation verdict) and the exact model behind it (discounted-earnings / equity-risk-premium), then enumerates the concrete outputs: ladder verdict, implied ERP, zone, distance from fair value, and five ERP bands. An agent can tell immediately this is a market-level valuation read, distinct from the macro/liquidity/breadth/gappers siblings.
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?
There is no statement of when to call this versus get_cross_asset_regime, get_macro_liquidity, or get_market_breadth, and no prerequisites or exclusions. The only interpretive cue is 'A model, not a forecast,' which frames how to read the output rather than when to select the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gapper Scanner (FREE preview) — 5-pillar low-float momentum gap scan (gap >=10%, price $1-$100, float <=100M, premarket volume >=50k; relative volume ranks the board and news is flagged; independent implementation, defaults differ from any educator's published criteria). Finds cheap small-cap stocks gapping up hard, flagging which have a news catalyst.
This free, no-key endpoint auto-picks the live session — pre-market gappers during 04:00-09:30 ET, after-hours gainers during 16:00-20:00 ET — and returns the top 10 on the default filters (up >=10% vs the session's reference close, price $1-$100, float <=100M shares, extended-hours volume >=50k).
Each gapper: symbol, name, sector, last (extended-hours price), changePct (TRUE gap vs the reference close), atr, rvol (DERIVED premarket relative volume = premarketVolume / avgVolume, i.e. what fraction of a normal FULL day's volume has already traded — NOT TradingView's regular-session relative volume, which is meaningless before the bell), premarketVolume (extended-hours volume), avgVolume, float, rsi, and hasNews (a boolean catalyst flag — headline text and article links are not served here). Ranked by cleared pillars first, then premarket relative volume descending. The result echoes 'session'.
Want to force a session, tune the filters, pull up to 50 names, and unlock the full 51-tool connector (live options flow, GEX magnet levels, unusual activity, wheel screeners)? Get a TraderMatrix API key — see the '_upgrade' field.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the read-only annotations: it discloses that the endpoint is a free preview, auto-selects the session, returns only the top 10 under default filters, and clarifies that hasNews is a boolean without headline text or links. It also explains that rvol is a derived premarket metric and warns that it differs from regular-session relative volume, which is valuable behavioral detail.
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 front-loaded with the core purpose and filter criteria, and the key limitations are stated early. It is somewhat long and repeats the default filter thresholds across two paragraphs, but most of the additional detail earns its place by clarifying session behavior, field meanings, and ranking logic.
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?
Given the absence of an output schema, the description compensates by enumerating the returned fields and explaining their meanings, including changePct, rvol, premarketVolume, and hasNews. It also describes ranking order and the echoed session field, so an agent has enough information to interpret results without a formal output schema.
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?
This tool has zero parameters, so there are no parameter semantics to document. The baseline score of 4 is appropriate because the description does not need to compensate for any schema gaps.
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 names a specific scanner and scope: a low-float momentum gap scan returning top premarket or after-hours gappers. It clearly distinguishes this from the sibling macro tools by focusing on individual small-cap gappers with explicit filtering criteria, and it explains the auto-session behavior.
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 clearly states when the endpoint applies (pre-market 04:00-09:30 ET vs after-hours 16:00-20:00 ET) and what default filters are used, which gives an agent enough context to invoke it correctly. It does not explicitly compare against a named alternative tool, but the sibling tools are macro-level and clearly different in scope.
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.
get_cross_asset_regimeget_macro_liquidityget_market_breadthget_market_health_historyget_market_valuationget_premarket_gappersThe full TraderMatrix market-data connector for Claude, Cursor and any MCP client. 51 tools: scored and tiered unusual options activity, dealer gamma (GEX), Apex levels and gamma pockets, IV rank, sector flow, dark-pool net-notional rollups, market health and macro regime, gap-continuation and breakout signals, wheel and CSP screeners, a one-call ticker snapshot, and your own watchlists. Needs a TraderMatrix API key (OAuth sign-in works for Claude web and mobile). A free, no-key connector with the gapper scanner and Market Health tools is listed separately as TraderMatrix Free.
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
> TradingMCP puts a market analyst inside your AI assistant. Paste one URL into Claude, ChatGPT, Cursor, VS Code or any MCP client and ask in plain language: screen for breakouts, run a multi-timeframe analysis, backtest a strategy with walk-forward validation, scan for smart-money and volume signals, or get a one-prompt morning market brief. In clients that support MCP Apps, price charts and the Markets panel are drawn right in the chat. > 40+ tools covering crypto (real-time), stocks, ETFs, FX, futures and commodities across major global exchanges. > Hosted, nothing to install: Pro $9/month (2,500 tool calls) or Pro+ $29/month (10,000). Paid upfront with a 14-day money-back guarantee; your API key arrives right after checkout. > Built on the open-source tradingview-mcp core (MIT, ~5k GitHub stars): self-host it free, or use the hosted version with zero ops. > For research and education, not financial advice. Not affiliated with TradingView
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Add one secure layer between your agents and this server.
