Pre-computed market data that improves agent reasoning, reduces token usage, and replaces pipelines.
Scored across 8 tools
Each tool targets a distinct resource or action (account, schema, search, summary, changes, OHLCV, market, universe), and descriptions explicitly route between overlapping tools such as get_search vs get_universe vs get_summary and get_changes vs get_summary. Some boundary overlap remains around per-ticker changes, historical summaries, and filtered universes, but the guidance substantially mitigates misselection.
All eight tools follow the same get_<noun> pattern: get_account, get_changes, get_market, get_ohlcv, get_schema, get_search, get_summary, get_universe. The convention is fully predictable.
Eight tools is well-scoped for a read-only market-data intelligence server, and each tool earns its place across account, schema, screening, per-ticker, historical, market, OHLCV, and bulk-data needs. There is no obvious redundancy or missing operational axis.
The surface covers schema discovery, account limits, asset screening, per-ticker summary/history/events, OHLCV, market/macro regimes, bulk universe extraction, and multi-ticker changes, which is strong lifecycle coverage for a read-only data API. Minor gaps include no direct batch full-summary tool for an arbitrary selected ticker list (get_changes only returns changes and get_universe returns all assets) and no intraday data, but these are workaroundable.
Get your account details including current plan tier, monthly credit limits, and current usage. Response includes tier, limits (monthly_requests, overage_enabled, search_results, history_days), and usage (monthly_requests_used, monthly_requests_remaining, credit_balance for pay-per-use accounts). Also returns scheduled_tier and scheduled_change_at if a plan change is pending.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — no auth/permission requirements and no note that data is account-scoped to the caller's own credentials — and its second sentence describes return shape rather than 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?
Two sentences, front-loaded with the purpose and followed by concrete field names. Slight waste: the parenthetical field list (monthly_requests, search_results, history_days, etc.) largely restates what the output schema already declares, so it earns less than its length suggests.
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?
A zero-parameter read tool with an output schema and full annotation coverage needs only a clear statement of what it returns and when it's relevant; the description supplies both, including the conditional scheduled_tier/scheduled_change_at fields. Nothing needed to invoke it correctly is missing.
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, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a parameterless call by never referencing any inputs.
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 opens with a specific verb and resource ("Get your account details") and immediately enumerates the scope: plan tier, credit limits, usage. That scope is distinct from every sibling (get_changes, get_market, get_ohlcv, get_schema, get_search, get_summary, get_universe), none of which touch account/billing state.
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?
Usage is implied rather than stated — the agent can infer "call this when you need plan or quota information," but there is no explicit when-to-call trigger (e.g., before hitting rate limits) and no exclusions. This is partly excusable because no sibling overlaps in purpose, so there is no real alternative to route between.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get field-level band changes of the newest published date for up to 50 tickers: day-over-day for daily, week-over-week for weekly. Each change is {field, from, to}; Plus and Pro also get stability, periods_in_current_state and recent flips. ticker_context gives each ticker's last_changed_date. Use it for 'what changed for AAPL, MSFT and NVDA today?' instead of pulling full summaries; use get_summary for one ticker's full state.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Ticker symbols, e.g. ["AAPL", "MSFT"]. At most 50. | |
| timeframe | No | daily (day-over-day) or weekly (week-over-week). Default: daily |
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavior annotations don't cover: the day-over-day vs week-over-week comparison basis, the 50-ticker cap, the per-change shape {field, from, to}, tier-gated extras (Plus and Pro get stability, periods_in_current_state, recent flips), and that ticker_context carries last_changed_date. Since an output schema already exists, describing return fields is partly redundant, which keeps this from a 5.
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-loads the core operation, then moves to response shape, tier differences, and the sibling routing rule. Dense but nearly every clause carries information; the response-shape sentence is the only part that overlaps with the output schema.
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 read tool with full schema coverage, annotations, and an output schema, the description covers purpose, alternatives, response structure, tier gating, and the companion ticker_context payload. Nothing needed to invoke it correctly is missing.
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 100% and already documents both parameters, including the daily/weekly enum and the 50-item cap. The description restates the same semantics ('day-over-day for daily, week-over-week for weekly') without adding syntax or edge-case guidance, so this sits at the baseline.
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 verb and resource ('get field-level band changes'), scopes it ('newest published date, up to 50 tickers'), and immediately contrasts with get_summary. An agent can distinguish it from every sibling without opening a schema.
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?
Gives an explicit example utterance ('what changed for AAPL, MSFT and NVDA today?') plus a negative instruction ('instead of pulling full summaries') and names the alternative tool with the condition that selects it ('use get_summary for one ticker's full state').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the market level: regime bands for the whole US equity market (market_*) and the US economy (macro_*), one row per date, point in time. Use it for 'what regime is the market in?', 'is breadth washed out?', 'is the yield curve inverted?', 'is the economy in stagflation?', 'what is the recession risk?', 'when did the yield curve last un-invert?', 'list every market regime change in 2024'. Key bands: market_regime_zone (bull_broad, bull_narrow, correction, bear, recovery), market_breadth_ma200_zone (washed_out .. overextended), market_fear_greed_zone, market_valuation_zone, market_volatility_zone, market_risk_appetite_zone, market_earnings_season_zone, macro_regime_zone (goldilocks, reflation, stagflation, deflationary_slowdown), macro_recession_risk_zone, macro_yield_curve_zone (deeply_inverted, inverted, flat, normal, steep), macro_fed_policy_zone, macro_inflation_zone, macro_inflation_trend, macro_labor_market_zone, macro_sahm_rule_zone, macro_gdp_zone. Headline numbers: market_fear_greed_score, market_stocks_below_ma200_pct, market_aggregate_pe_ratio, macro_treasury_yield_2y_pct, macro_treasury_yield_10y_pct, macro_yield_curve_10y_minus_2y_pct, macro_fed_funds_rate_pct, macro_cpi_inflation_yoy_pct, macro_unemployment_rate_pct, macro_gdp_growth_annualized_pct. Every band carries change markers (_prev = label left on the row it changed, periods = rows in the current label, 1 = changed today, flips_recent_count, stability); set changes=true to get only dates where a band changed, with from/to. macro values are as first published (never revised later) and low-frequency releases carry until the next one (null once stale). To find tickers under a market condition, put market/macro filters into get_search instead (they match each ticker row's own date). get_schema lists every market field with level=market.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Range end (YYYY-MM-DD), with start. | |
| date | No | One date (YYYY-MM-DD). Omit date, start and end for the newest row. | |
| limit | No | Range rows to return. Default 100, max 2000. | |
| order | No | Range order by date. Default: desc (newest first). | |
| start | No | Range start (YYYY-MM-DD), with end. | |
| fields | No | JSON-encoded array of market fields to return, e.g. ["market_regime_zone","macro_regime_zone","macro_yield_curve_zone","macro_yield_curve_10y_minus_2y_pct"]. Omit for every band and raw value; ["*"] adds the change markers. | |
| changes | No | true = only dates where at least one selected band changed (each row gets changes: [{field, from, to}]); or a JSON array of bands to watch, e.g. ["market_regime_zone","macro_regime_zone"]. Plus and Pro. | |
| filters | No | JSON-encoded filter array on market fields, markers included. Example (yield curve just un-inverted): [{"field":"macro_yield_curve_zone_prev","op":"in","value":["inverted","deeply_inverted"]},{"field":"macro_yield_curve_zone","op":"in","value":["flat","normal","steep"]}]. Ops: eq, neq, in, gt, gte, lt, lte. | |
| timeframe | No | daily (every US equity session) or weekly (Sunday-dated). Default: daily |
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it discloses point-in-time semantics, that macro_ values are as first published and never revised, that low-frequency releases carry forward until the next one and go null once stale, and that the changes parameter is gated to Plus and Pro. It also explains the _prev/_periods/_flips_recent_count/_stability marker system, which is behavior an agent could not infer from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, routing to siblings, and the band taxonomy are front-loaded, and nearly every clause earns its place. The exhaustive band name dump is dense and long, but it substitutes for an absent enum on the fields parameter, so it is informative rather than padding.
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 an output schema present, the description need not explain return formatting, and it still covers revision policy, staleness, marker semantics, plan gating, and the handoff to get_search. For a 9-parameter read tool with optional everything, an agent has enough to call it correctly on the first try.
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 already 100%, so the baseline is 3, but the description adds real value: it enumerates the market_/macro_ band families available to fields, explains that ['*'] adds change markers, and clarifies that filters operate on market fields including markers, with a worked un-inversion example. It stops short of covering date/limit/order/timeframe interplay, which the schema already handles.
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 sentence names a specific verb (Get) and resource (the market level), then defines the exact shape of the output: regime bands for the US equity market (market_*) and US economy (macro_*), one row per date, point in time. It also implicitly separates itself from get_search and get_schema by naming them for different jobs.
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 lists concrete natural-language questions the tool answers ('what regime is the market in?', 'when did the yield curve last un-invert?') and gives an explicit exclusion with a redirect: to find tickers under a market condition, put market_/macro_ filters into get_search instead. That is a clear when-to-use / when-not-to-use pairing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stored end-of-day OHLCV candles for a stock, ETF, or crypto ticker, daily or weekly. Use this for exact-return calculations, charts, and backtests after get_summary identifies a setup. Results are paginated; pass next_cursor back as cursor to continue. Prices are stored as traded; adjustment picks the basis: split (default), split_dividend (total return) or raw. Credit cost is 1 credit per 100 bars returned, rounded up, with a 1 credit minimum.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Inclusive end date (YYYY-MM-DD). Compared against the candle date. | |
| limit | No | Maximum candles to return (1-1000). Default: 100. | |
| order | No | Sort by candle date. Default: desc. | |
| start | No | Inclusive start date (YYYY-MM-DD). Compared against the candle date, so for weekly this is the Sunday week end. Lookback is limited by plan. | |
| cursor | No | Exclusive date cursor from next_cursor for pagination (YYYY-MM-DD). | |
| ticker | Yes | Ticker symbol, e.g. AAPL, BTCUSD, SPY | |
| timeframe | No | Candle timeframe. Default: daily. Weekly candles cover Monday-Sunday and are dated by the Sunday week end, matching get_summary with timeframe=weekly. The in-progress week is not returned. | |
| adjustment | No | Price basis. split (default): today's share basis, every split applied. split_dividend: splits plus cash dividends (a total-return series). raw: as traded on each date (daily only for ohlcv). |
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds substantial context on top: pagination via next_cursor, credit cost of 1 per 100 bars rounded up with a 1-credit minimum, and the fact that the in-progress week is not returned. These are cost and completeness details an agent cannot infer from structured fields.
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 purpose, then usage, then operational details, with no filler sentences. There is some duplication between the description's adjustment explanation and the schema's identical enum documentation, which is the only inefficiency.
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?
An output schema exists so return values need not be described, and the description covers the operational gaps agents actually hit: pagination, credit cost, lookback limited by plan, and weekly candle dating by Sunday. Only edge cases like invalid ticker behavior are unaddressed, which is minor for a read tool.
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?
With 100% schema coverage the baseline is 3, and the description earns above that by explaining the substantive semantics: adjustment picks the price basis with split as default, split_dividend as a total-return series, and raw restricted to daily. It also clarifies the cursor round-trip. Most of this reinforces rather than expands on the schema's own text.
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?
Opens with a specific verb+resource+scope: 'stored end-of-day OHLCV candles' for stock, ETF, or crypto tickers, daily or weekly. An agent can distinguish this from get_summary (which it references as a prior step) and from sibling market tools without opening the schema.
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?
Explicitly states use cases ('exact-return calculations, charts, and backtests') and positions itself after get_summary identifies a setup, which is real sequencing guidance. It stops short of naming a when-not-to-use case or a competing alternative, so it lands just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the schema of all available fields and their valid band values, with a plain-words description, unit and minimum plan for each. Every field has level: ticker (per-asset snapshot columns for get_search, get_summary) or market (market_* and macro_* regime bands, one row per date, for get_market and as get_search filters matched on the same date). Use this when the user asks 'what fields are available?', 'what bands does momentum_rsi_zone have?', 'what macro bands exist?', or when you need to validate field/band names before calling get_summary with event parameters, get_search with filters, or get_market. Field names follow []; bands end in a category word (_zone, _trend, _state ...). The response also lists the naming rules and notes that pre-2026-10-31 names are still accepted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context about the response contents (plain-words descriptions, units, minimum plans, naming rules, and pre‑2026‑10‑31 name acceptance) and the field-level structure. It doesn't explain openWorld implications, but for a zero‑param schema lookup that is a minor gap.
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 and mostly informative, but it runs five sentences and includes some redundancy—e.g., the naming-rule summary in sentence four is partly repeated in sentence five about the response listing naming rules. It is well structured but slightly longer than strictly necessary for a zero‑param schema tool.
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 zero parameters, an existing output schema, and rich annotations, the description is complete enough: it explains what the tool returns, how fields are structured (ticker vs market), when to call it, and backward-compatibility notes. Nothing an agent needs in order to call it correctly is missing.
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, so the baseline is 4. The description focuses on the returned schema's naming conventions and band categories, which is useful but does not and need not add parameter semantics.
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 verb and resource: 'Get the schema of all available fields and their valid band values, with a plain-words description, unit and minimum plan for each.' It also distinguishes field levels (ticker vs market) and explicitly names the sibling tools those fields feed into (get_search, get_summary, get_market), so an agent can tell it apart from data-fetching 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?
Usage is explicit: 'Use this when the user asks...' with concrete sample questions, and 'when you need to validate field/band names before calling get_summary with event parameters, get_search with filters, or get_market.' This gives clear when-to-use guidance tied to specific sibling tools, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for assets matching filter criteria, including categorical states (e.g. oversold assets, strong uptrends, bull/bear flag setups, triangle or wedge setups, free-cash-flow surplus or burn, recent golden crosses, weekly stage 2 assets near the 40w MA with high volume, volatility squeeze active, volume climax detected, insider buying zone, sector-aligned breakouts, extreme fear, cheap PEG) or rankings by a field such as market_cap_usd on a historical date. Pass filters as a JSON-encoded array of {field, op, value} objects. Use get_schema to discover valid field names (prefer it over guessing). Bands end in a category word (_zone, _state, _direction, _trend, _tier), raw numbers in their unit (_pct, _ratio, _price, _usd, _count, periods, score). Examples: momentum_rsi_zone, momentum_rsi (0-100), trend_direction, trend_stage, trend_ma50_slope_zone, trend_distance_ma40_zone (raw trend_distance_ma40_pct), trend_ma_compression_zone, trend_ma_crossover_event, pattern_bull_flag_state, pattern_bull_flag_breakout, pattern_ascending_triangle_state, volume_ratio_zone, volatility_squeeze_active, range_position_zone, fundamentals_free_cash_flow_zone, fundamentals_revenue_zone, fundamentals_peg_ratio / fundamentals_peg_zone, fundamentals_earnings_proximity_zone, forward_outlook_earnings_zone, insider_zone, sector_stocks_oversold_count, fear_greed_score / fear_greed_zone (per asset), and the GARP family garp_score, garp_score_tier, garp_core_score, potential_upside_pct (available once company-guidance coverage is complete; null until then). Names from before the 2026-10-31 renames (volume_ratio_band, trend_distance_ma50, pattern_bull_flag, fundamentals_revenue, range_position, sector_total_count) are still accepted; responses use the new names. MARKET CONDITIONS: market-wide market* and economy-wide macro* bands (e.g. market_regime_zone, market_breadth_ma200_zone, market_fear_greed_zone, macro_regime_zone, macro_yield_curve_zone, macro_yield_curve_zone_prev, macro_recession_risk_zone) can be mixed into filters: a market filter keeps only the dates where the condition held, matched on each ticker row's own date; putting a market field in fields attaches that date's value to every row. With start and end plus at least one market filter, every matching date in the range is screened (rows carry date), e.g. stocks oversold on the days breadth was washed out. Use get_market for the market rows themselves. Use fields to control returned columns and sort_by to rank results server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Date-range screen end (YYYY-MM-DD), with start. | |
| date | No | Historical snapshot date (YYYY-MM-DD). Omit for latest per asset class. Do not combine with start/end. | |
| limit | No | Max results to return. Tier-gated: Starter 25, Plus 100, Pro 500. Default: 20 | |
| start | No | Date-range screen start (YYYY-MM-DD), with end. Requires at least one market_* or macro_* filter, which selects the dates; rows then carry date, newest first. | |
| fields | No | JSON-encoded array of column names to return. Example: ["ticker", "sector", "market_cap_usd", "fundamentals_pe_ratio", "trend_stage", "trend_ma40_price", "trend_ma50_slope_zone", "trend_ma_crossover_event", "trend_distance_ma40_zone", "pattern_bull_flag_state", "pattern_bull_flag_breakout", "fundamentals_free_cash_flow_zone", "volume_ratio_zone", "fear_greed_zone", "insider_zone", "sector_agreement", "fundamentals_earnings_proximity_zone", "market_regime_zone", "macro_regime_zone"]. market_* / macro_* fields attach the market value of each row's date. Omit to get a default core subset: ticker, asset_class, sector, market_cap_usd, market_cap_tier, momentum_performance_zone, trend_direction, trend_ma20_slope_zone, trend_ma_compression_zone, trend_ma_crossover_event, momentum_rsi_zone, extremes_condition, extremes_condition_rarity, volatility_regime, volume_ratio_zone, pattern_*_state for the seven patterns plus pattern_bull_flag_breakout / pattern_bear_flag_breakdown, fundamentals_valuation_zone, range_position_zone. Use ["*"] for all ticker fields. Specify fields to reduce token usage. trend_stage is weekly-only and should be requested with timeframe=weekly. Fundamentals, forward_outlook, insider, sector context, GARP and potential fields are Pro; support/resistance/range/breakout fields need Plus; change markers (_periods, _prev, _stability, _flips_recent_count) need Plus. | |
| filters | Yes | JSON-encoded filter array. Each filter: {"field": "column_name", "op": "eq|neq|in|gt|gte|lt|lte", "value": "..."}. Example: [{"field": "momentum_rsi_zone", "op": "in", "value": ["oversold", "deep_oversold"]}, {"field": "sector", "op": "eq", "value": "Technology"}]. Market conditions mix in: [{"field": "market_breadth_ma200_zone", "op": "eq", "value": "washed_out"}] or the yield curve just un-inverting: [{"field": "macro_yield_curve_zone_prev", "op": "eq", "value": "inverted"}]. Change markers work as filters too: <band>_periods = 1 means the band changed on that row, <band>_prev is the label it left. | |
| sort_by | No | Ticker field to sort results by (e.g. "market_cap_usd", "fundamentals_pe_ratio", "fundamentals_peg_ratio", "fear_greed_score", "garp_score", "extremes_condition_rarity_percentile", "fundamentals_valuation_percentile", "volume_percentile", "sector_stocks_oversold_count"). Market-level fields cannot be sorted on (one value per date). Server-side sorting avoids pulling extra fields for client-side ranking. | |
| timeframe | No | Analysis timeframe. Default: daily | |
| sort_direction | No | Sort direction. Default: desc. Use 'asc' for lowest-first (e.g. cheapest valuation percentile). |
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), but the description adds far more: legacy field names are still accepted while responses use new names, GARP/potential fields are null until guidance coverage completes, market filters restrict dates vs. fields attaching per-date values, and range screens return one row per matching date. Those are non-obvious behaviors an agent cannot infer from annotations or schema alone.
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 purpose is front-loaded, but the body is a dense wall of roughly forty example field names plus a long parenthetical about GARP availability, and the date-range/market-filter semantics are restated from the schema's start parameter. The information density is high, but a meaningful share of the text is redundant with structured fields rather than additive.
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 9-parameter, tier-gated screening tool with an output schema, the description covers the query model, field naming, default columns, legacy-name compatibility, and the market-filter/date interaction that is the tool's most subtle behavior. Nothing an agent needs to construct a correct call is missing.
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 100%, so the baseline is 3, and the description earns above that by supplying the field-naming taxonomy ('bands end in _zone/_state/_direction...', raw numbers carry units like _pct/_usd) that governs the values of filters/fields/sort_by. It stops short of 5 because much of the tier-gating and example detail is duplicated in the schema's own parameter descriptions.
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?
Opens with a specific verb+resource ('Search for assets matching filter criteria') and immediately enumerates the kinds of queries supported (categorical state screens vs. field rankings on a historical date). It also positions itself against siblings by naming get_schema and get_market, so an agent can distinguish it from get_market/get_universe without opening any schema.
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?
Explicit routing rules are given: 'Use get_schema to discover valid field names (prefer it over guessing)' and 'Use get_market for the market rows themselves.' It also states how to control output with fields and sort_by, and when start/end is valid ('with at least one market_* or macro_* filter'), which is exactly the when/when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pre-computed market intelligence for a specific stock, crypto, or ETF ticker. Supports 4 modes: (1) Snapshot (default) for the latest categorical state; (2) Historical snapshot by date; (3) Historical series with start and end dates; (4) Events by field and optional band (when a band was entered, what it left, how long the prior state lasted), for any tracked band: momentum_rsi_zone, trend_direction, trend_stage, trend_ma8_slope_zone through trend_ma200_slope_zone, trend_distance_ma40_zone, trend_ma_crossover_event, pattern_bull_flag_state, pattern_ascending_triangle_state, volume_ratio_zone, fear_greed_zone, fundamentals_free_cash_flow_zone, fundamentals_peg_zone, forward_outlook_earnings_zone, garp_score_tier and more (old names such as pattern_bull_flag or volume_ratio_band are still accepted). Add stats=true in event mode for aggregate counts by band. Results include as_of_date, same-candle OHLCV, market_cap_usd, market_cap_tier, performance_zone, trend (ma_slopes, distance_from_ma_zone, ma_compression_zone, volume_confirmation_state), momentum (raw rsi, stochastic_k, stochastic_d beside their zones), extremes (condition_rarity_percentile), volatility, volume (ratio_zone, price_on_volume_direction), patterns (_state), support/resistance (distance_zone, volume_at_tests_zone), range_position_zone, breakout_type, fear_greed (score 0-100 and zone), levels (paid tiers), sector_context (stocks_oversold_count, stocks_count, asset_vs_sector_rsi_zone ...), and stock-only fundamentals (pe_ratio, pb_ratio, peg_ratio, peg_zone, reporting_currency, revenue_zone, profitability_zone, cash_flow_zone, balance_sheet_zone, free_cash_flow_zone, earnings_proximity_zone, analyst_consensus_zone, forward_outlook._zone, insider_activity) plus garp (with garp.core) and potential blocks (Pro; available once company-guidance coverage is complete, null until then). Market-wide and macro regimes are not part of a ticker summary: use get_market. Summary keeps sibling _meta objects off by default; set meta=true or request explicit *_meta fields when paid-tier stability metadata is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Range end date (YYYY-MM-DD). Use with start for historical series. | |
| band | No | Filter events to a specific band value (e.g. deep_oversold, strong_uptrend, stage_2_growth, extreme_fear). For MA distance event fields such as trend_distance_ma40_zone, grouped aliases above and below are also supported. Only used with field. | |
| date | No | Historical date (YYYY-MM-DD) for a point-in-time snapshot. Requires Plus or Pro plan. Omit for latest. | |
| meta | No | Snapshot and history modes only. Add true to include sibling _meta / status_meta stability objects across the response. Explicit *_meta field paths in fields still work without this flag. | |
| after | No | Return events after this date (YYYY-MM-DD). Only used with field. | |
| field | No | Band field name for event queries (e.g. momentum_rsi_zone, extremes_condition, trend_direction, trend_stage, pattern_bull_flag_state, pattern_ascending_triangle_state, pattern_rising_wedge_state, trend_ma8_slope_zone through trend_ma200_slope_zone, trend_ma_crossover_event, trend_distance_ma40_zone, volume_ratio_zone, fear_greed_zone, fundamentals_valuation_zone, fundamentals_free_cash_flow_zone, fundamentals_peg_zone, fundamentals_analyst_consensus_zone, forward_outlook_earnings_zone, garp_score_tier, insider_zone). Old names are accepted. When provided, returns band transition history instead of a snapshot. | |
| limit | No | For event mode: max results (1-50), returned newest-first by default. For sample=even date ranges: requested sampled rows, capped by plan (Free 3, Plus 10, Pro 50). | |
| start | No | Range start date (YYYY-MM-DD). Use with end for historical series. | |
| stats | No | Event mode only. Add true to return aggregate stats instead of raw event rows. | |
| before | No | Return events before this date (YYYY-MM-DD). Only used with field. | |
| fields | No | Optional summary fields to return. Identity fields such as market_cap_usd and market_cap_tier are always kept. Pass sections like ohlcv, trend, momentum, volatility, volume, patterns, extremes, support_level, resistance_level, fear_greed, fundamentals, sector_context, garp, potential, or levels (paid tiers). Or pass dotted paths like ohlcv.close, trend.direction, trend.stage, trend.ma_slopes.ma_50, trend.moving_average_values.ma_50_price, trend.ma_crossover_event, trend.direction_meta, trend.distance_from_ma_zone.ma_40, trend.distance_from_ma_pct.ma_40, trend.ma_compression_zone, trend.volume_confirmation_state, momentum.rsi, momentum.rsi_zone, momentum.stochastic_k, momentum.stochastic_zone, momentum.macd_state, patterns.bull_flag_state, patterns.bull_flag_breakout, patterns.ascending_triangle_state, volatility.squeeze_active, volatility.squeeze_periods, volume.ratio_zone, volume.climax_detected, volume.price_on_volume_direction, support_level.level_price, support_level.distance_zone, support_level.status_meta, range_position_zone, breakout_type, fear_greed.score, fear_greed.zone, sector_context.rsi_zone, sector_context.asset_vs_sector_rsi_zone, sector_context.stocks_oversold_count, fundamentals.pe_ratio, fundamentals.peg_ratio, fundamentals.peg_zone, fundamentals.reporting_currency, fundamentals.valuation_zone, fundamentals.free_cash_flow_zone, fundamentals.revenue_zone, fundamentals.earnings_proximity_zone, fundamentals.analyst_consensus_zone, fundamentals.forward_outlook.earnings_zone, fundamentals.insider_activity, garp.score, garp.score_tier, garp.core.score, potential.upside_pct, levels.support_levels. Flat search names (e.g. volume_ratio_zone, fundamentals_peg_ratio, garp_score) and pre-2026-10-31 paths (volume.ratio_band, patterns.bull_flag, fundamentals.revenue) are accepted too; responses use the new keys. trend.stage is populated on weekly snapshots when stage evidence is sufficient. | |
| sample | No | Date range mode only. Use 'even' to evenly distribute snapshots across the full start/end range. | |
| ticker | Yes | Ticker symbol, e.g. AAPL, BTCUSD, SPY | |
| timeframe | No | Analysis timeframe. Default: daily | |
| adjustment | No | Price basis. split (default): today's share basis, every split applied. split_dividend: splits plus cash dividends (a total-return series). raw: as traded on each date (prices in the ohlcv block). | |
| context_band | No | Only return events where the context ticker was in this band (e.g. downtrend). For MA distance context fields, grouped aliases above and below are also supported. Must be provided with context_ticker and context_field. | |
| context_field | No | Band field to check on the context ticker (e.g. trend_direction, trend_stage, or trend_distance_ma40_zone). Must be provided with context_ticker and context_band. | |
| context_ticker | No | Cross-asset correlation: a second ticker to filter against (e.g. SPY). Requires context_field and context_band. Plus/Pro only. |
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations by disclosing plan gating (historical date and context_ticker require Plus/Pro), the paid-tier-only levels block, the potential block returning null until guidance coverage is complete, and that _meta objects are omitted by default. Missing only pagination/row-limit behavior and typical response size for event mode.
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 correctly with purpose, modes, and the get_market exclusion, but the long mid-section enumerating dozens of return fields and band names largely duplicates the fields parameter schema and the output schema. Roughly half the text could be cut without losing callable information.
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 18 parameters and an output schema present, the description covers mode selection, plan restrictions, and defaults adequately. Its remaining gap is behavioral rather than informational: it over-explains return keys (already in the output schema) while saying little about result volume or ordering in non-event modes.
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 already 100%, so baseline is 3; the description adds real semantic value by grouping parameters into the four calling modes and noting that band/after/before/context_* are only meaningful alongside field. It does not add syntax or plan-cap details beyond what the schema states for limit and sample.
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?
Opens with a specific verb+resource ('Get pre-computed market intelligence for a specific stock, crypto, or ETF ticker') and enumerates four distinct modes. It also explicitly excludes market-wide/macro regimes and names get_market as the sibling for those, so an agent can route correctly without opening a schema.
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?
Each of the four modes is paired with the parameter pattern that selects it (snapshot default, date for point-in-time, start/end for series, field for events), stats=true is called out for aggregates, and get_market is given as the explicit alternative for market-wide data. Modes and alternatives are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get selected fields for EVERY asset on one date in a single call (about 11,000 rows), ordered by ticker: the input of a daily or weekly trading model run. Fields use the same names as get_search and are tier-gated the same way; at most 60 per call. Costs 5 credits. A row dated D reflects everything known by 04:00 UTC on D+1, so a backtest acts at the next session's open. For filtered or ranked subsets use get_search; for one ticker use get_summary.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date (YYYY-MM-DD). Omit for each asset class's newest published date. History depth depends on plan. | |
| fields | Yes | Fields to return, e.g. ["trend_direction", "momentum_rsi_zone", "market_cap_usd"]. Same names and aliases as get_search; at most 60. | |
| timeframe | No | daily, or weekly (Sunday-dated). Default: daily | |
| asset_class | No | Only this asset class. Omit for all. |
| Name | Required | Description |
|---|---|---|
| data | No | The TickerDB API response payload for this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it discloses cost (5 credits), result volume (~11,000 rows), ordering, the 60-field cap, tier-gating behavior, and point-in-time semantics (a row dated D reflects data known by 04:00 UTC D+1, so a backtest acts at next session's open). That is behavioral context an agent cannot get from the annotations or schema.
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-loads the core action and scope, then costs/semantics, then sibling routing. Every sentence carries distinct information with no repetition of the schema.
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 an output schema exists, the description need not explain returns; it still covers cost, volume, ordering, tier gating, point-in-time correctness, and alternatives. Nothing an agent needs to call this correctly is missing.
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 100%, so the baseline is 3, but the description adds real value: fields share names and aliases with get_search and are tier-gated the same way, and the 60-per-call cap is stated in prose. The date parameter's point-in-time meaning is also explained in the description, though the timeframe enum semantics are mostly left 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?
States a specific verb and resource plus exact scope: selected fields for EVERY asset on one date, ~11,000 rows, ordered by ticker. The parenthetical row count and 'input of a daily or weekly trading model run' make the use case unmistakable and separate it from filtered 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?
Explicitly routes alternatives: 'For filtered or ranked subsets use get_search; for one ticker use get_summary,' and states the intended context (daily/weekly trading model run). Both when-to-use and when-not-to-use are covered with named siblings.
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.
add_to_watchlistget_changesget_marketget_ohlcv1 field changedInput schema / properties / adjustmentAdded value: +{
+ "description": "Price basis. split (default): today's share basis, every split applied. split_dividend: splits plus cash dividends (a total-return series). raw: as traded on each date (daily only for ohlcv).",
+ "enum": [
+ "split",
+ "split_dividend",
+ "raw"
+ ],
+ "type": "string"
+}get_search6 fields changedInput schema / properties / date / descriptionPrevious value: -"Historical snapshot date (YYYY-MM-DD). Omit for latest per asset class."New value: +"Historical snapshot date (YYYY-MM-DD). Omit for latest per asset class. Do not combine with start/end."Input schema / properties / endAdded value: +{
+ "description": "Date-range screen end (YYYY-MM-DD), with start.",
+ "type": "string"
+}Input schema / properties / fields / descriptionPrevious value: -"JSON-encoded array of column names to return. Example: [\"ticker\", \"sector\", \"market_cap\", \"pe_ratio\", \"trend_stage\", \"ma40\", \"trend_ma50_slope\", \"trend_ma_crossover_event\", \"trend_distance_ma40\", \"pattern_bull_flag\", \"pattern_bull_flag_breakout\", \"pattern_bear_flag_breakdown\", \"pattern_ascending_triangle\", \"fundamentals_free_cash_flow\", \"volume_ratio_band\", \"insider_zone\", \"sector_agreement\", \"volatility_squeeze_active\", \"volume_climax_detected\", \"fundamentals_analyst_consensus\", \"fundamentals_earnings_proximity\", \"fundamentals_earnings_proximity_basis\"]. Omit to get a default core subset: ticker, asset_class, sector, market_cap, market_cap_tier, performance, trend_direction, trend_ma20_slope, trend_ma_compression_band, trend_ma_crossover_event, momentum_rsi_zone, extremes_condition, extremes_condition_rarity, volatility_regime, volume_ratio_band, pattern_bull_flag, pattern_bull_flag_breakout, pattern_bear_flag, pattern_bear_flag_breakdown, pattern_ascending_triangle, pattern_descending_triangle, pattern_symmetrical_triangle, pattern_rising_wedge, pattern_falling_wedge, fundamentals_valuation_zone, range_position. Request fundamentals_free_cash_flow explicitly when you need the stock-only free cash flow burn/surplus band. Request ma8 through ma200 for raw MA values and trend_ma8_slope through trend_ma200_slope for the full MA slope set. Use [\"*\"] for all fields. Specify fields to reduce token usage. trend_stage is weekly-only and should be requested with timeframe=weekly. Insider fields (insider_zone, insider_net_direction) and sector context fields (sector_rsi_zone, sector_trend, sector_agreement) are available on paid tiers."New value: +"JSON-encoded array of column names to return. Example: [\"ticker\", \"sector\", \"market_cap_usd\", \"fundamentals_pe_ratio\", \"trend_stage\", \"trend_ma40_price\", \"trend_ma50_slope_zone\", \"trend_ma_crossover_event\", \"trend_distance_ma40_zone\", \"pattern_bull_flag_state\", \"pattern_bull_flag_breakout\", \"fundamentals_free_cash_flow_zone\", \"volume_ratio_zone\", \"fear_greed_zone\", \"insider_zone\", \"sector_agreement\", \"fundamentals_earnings_proximity_zone\", \"market_regime_zone\", \"macro_regime_zone\"]. market_* / macro_* fields attach the market value of each row's date. Omit to get a default core subset: ticker, asset_class, sector, market_cap_usd, market_cap_tier, momentum_performance_zone, trend_direction, trend_ma20_slope_zone, trend_ma_compression_zone, trend_ma_crossover_event, momentum_rsi_zone, extremes_condition, extremes_condition_rarity, volatility_regime, volume_ratio_zone, pattern_*_state for the seven patterns plus pattern_bull_flag_breakout / pattern_bear_flag_breakdown, fundamentals_valuation_zone, range_position_zone. Use [\"*\"] for all ticker fields. Specify fields to reduce token usage. trend_stage is weekly-only and should be requested with timeframe=weekly. Fundamentals, forward_outlook, insider, sector context, GARP and potential fields are Pro; support/resistance/range/breakout fields need Plus; change markers (_periods, _prev, _stability, _flips_recent_count) need Plus."Input schema / properties / filters / descriptionPrevious value: -"JSON-encoded filter array. Each filter: {\"field\": \"column_name\", \"op\": \"eq|neq|in|gt|gte|lt|lte\", \"value\": \"...\"}. Example: [{\"field\": \"momentum_rsi_zone\", \"op\": \"in\", \"value\": [\"oversold\", \"deep_oversold\"]}, {\"field\": \"sector\", \"op\": \"eq\", \"value\": \"Technology\"}]"New value: +"JSON-encoded filter array. Each filter: {\"field\": \"column_name\", \"op\": \"eq|neq|in|gt|gte|lt|lte\", \"value\": \"...\"}. Example: [{\"field\": \"momentum_rsi_zone\", \"op\": \"in\", \"value\": [\"oversold\", \"deep_oversold\"]}, {\"field\": \"sector\", \"op\": \"eq\", \"value\": \"Technology\"}]. Market conditions mix in: [{\"field\": \"market_breadth_ma200_zone\", \"op\": \"eq\", \"value\": \"washed_out\"}] or the yield curve just un-inverting: [{\"field\": \"macro_yield_curve_zone_prev\", \"op\": \"eq\", \"value\": \"inverted\"}]. Change markers work as filters too: <band>_periods = 1 means the band changed on that row, <band>_prev is the label it left."Input schema / properties / sort_by / descriptionPrevious value: -"Column name to sort results by (e.g. \"market_cap\", \"pe_ratio\", \"extremes_condition_percentile\", \"fundamentals_valuation_percentile\", \"volume_percentile\", \"sector_oversold_count\", \"sector_breakout_count\"). Must be a valid field name from the schema. Server-side sorting avoids pulling extra fields for client-side ranking."New value: +"Ticker field to sort results by (e.g. \"market_cap_usd\", \"fundamentals_pe_ratio\", \"fundamentals_peg_ratio\", \"fear_greed_score\", \"garp_score\", \"extremes_condition_rarity_percentile\", \"fundamentals_valuation_percentile\", \"volume_percentile\", \"sector_stocks_oversold_count\"). Market-level fields cannot be sorted on (one value per date). Server-side sorting avoids pulling extra fields for client-side ranking."Input schema / properties / startAdded value: +{
+ "description": "Date-range screen start (YYYY-MM-DD), with end. Requires at least one market_* or macro_* filter, which selects the dates; rows then carry date, newest first.",
+ "type": "string"
+}get_summary5 fields changedInput schema / properties / adjustmentAdded value: +{
+ "description": "Price basis. split (default): today's share basis, every split applied. split_dividend: splits plus cash dividends (a total-return series). raw: as traded on each date (prices in the ohlcv block).",
+ "enum": [
+ "split",
+ "split_dividend",
+ "raw"
+ ],
+ "type": "string"
+}Input schema / properties / band / descriptionPrevious value: -"Filter events to a specific band value (e.g. deep_oversold, strong_uptrend, stage_2_growth). For MA distance event fields such as trend_distance_ma40, grouped aliases above and below are also supported. Only used with field."New value: +"Filter events to a specific band value (e.g. deep_oversold, strong_uptrend, stage_2_growth, extreme_fear). For MA distance event fields such as trend_distance_ma40_zone, grouped aliases above and below are also supported. Only used with field."Input schema / properties / context_field / descriptionPrevious value: -"Band field to check on the context ticker (e.g. trend_direction, trend_stage, or trend_distance_ma40). Must be provided with context_ticker and context_band."New value: +"Band field to check on the context ticker (e.g. trend_direction, trend_stage, or trend_distance_ma40_zone). Must be provided with context_ticker and context_band."Input schema / properties / field / descriptionPrevious value: -"Band field name for event queries (e.g. momentum_rsi_zone, extremes_condition, trend_direction, trend_stage, pattern_bull_flag, pattern_ascending_triangle, pattern_rising_wedge, trend_ma8_slope through trend_ma200_slope, trend_ma_crossover_event, trend_distance_ma40, fundamentals_valuation_zone, fundamentals_free_cash_flow, insider_zone, sector_rsi_zone, momentum_divergence_detected, fundamentals_analyst_consensus). When provided, returns band transition history instead of a snapshot."New value: +"Band field name for event queries (e.g. momentum_rsi_zone, extremes_condition, trend_direction, trend_stage, pattern_bull_flag_state, pattern_ascending_triangle_state, pattern_rising_wedge_state, trend_ma8_slope_zone through trend_ma200_slope_zone, trend_ma_crossover_event, trend_distance_ma40_zone, volume_ratio_zone, fear_greed_zone, fundamentals_valuation_zone, fundamentals_free_cash_flow_zone, fundamentals_peg_zone, fundamentals_analyst_consensus_zone, forward_outlook_earnings_zone, garp_score_tier, insider_zone). Old names are accepted. When provided, returns band transition history instead of a snapshot."Input schema / properties / fields / descriptionPrevious value: -"Optional summary fields to return. Identity fields such as market_cap and market_cap_tier are always kept. Pass sections like ohlcv, trend, momentum, volatility, volume, patterns, extremes, support_level, resistance_level, fundamentals, sector_context, or levels (paid tiers). Or pass dotted paths like ohlcv.close, trend.direction, trend.stage, trend.ma_slopes.ma_8, trend.ma_slopes.ma_20, trend.ma_slopes.ma_40, trend.ma_slopes.ma_50, trend.ma_slopes.ma_100, trend.ma_slopes.ma_200, trend.moving_average_values.ma_8, trend.ma_crossover_event, trend.direction_meta, trend.distance_from_ma_band.ma_40, trend.volume_confirmation, momentum.rsi, momentum.rsi_zone, momentum.stochastic_k, momentum.stochastic_d, momentum.stochastic_zone, momentum.xtrm_score, momentum.divergence_detected, momentum.divergence_type, momentum.macd_state, patterns.bull_flag, patterns.bull_flag_breakout, patterns.bear_flag, patterns.bear_flag_breakdown, patterns.ascending_triangle, patterns.rising_wedge, volatility.squeeze_active, volatility.squeeze_days, volatility.regime_trend, volume.climax_detected, volume.climax_type, volume.accumulation_state, volume.price_direction_on_volume, support_level.level_price, support_level.status_meta, resistance_level.level_price, sector_context.rsi_zone, sector_context.trend, sector_context.agreement, sector_context.asset_vs_sector_rsi, sector_context.asset_vs_sector_trend, sector_context.oversold_count, sector_context.valuation_zone, fundamentals.pe_ratio, fundamentals.valuation_zone, fundamentals.growth_zone, fundamentals.free_cash_flow, fundamentals.earnings_proximity, fundamentals.earnings_proximity_basis, fundamentals.last_earnings_surprise, fundamentals.analyst_consensus, fundamentals.analyst_consensus_direction, fundamentals.valuation_percentile, fundamentals.pe_vs_historical_zone, fundamentals.pe_vs_sector_zone, fundamentals.insider_activity, fundamentals.insider_activity.zone, fundamentals.insider_activity.net_direction, levels, levels.support_levels, levels.resistance_levels. trend.stage is populated on weekly snapshots when stage evidence is sufficient. Event field names should prefer full schema names such as momentum_rsi_zone, extremes_condition, trend_stage, pattern_bull_flag, pattern_ascending_triangle, pattern_rising_wedge, trend_ma8_slope through trend_ma200_slope, trend_ma_crossover_event, trend_distance_ma40, fundamentals_valuation_zone, fundamentals_free_cash_flow, insider_zone, sector_rsi_zone, momentum_divergence_detected, and fundamentals_analyst_consensus."New value: +"Optional summary fields to return. Identity fields such as market_cap_usd and market_cap_tier are always kept. Pass sections like ohlcv, trend, momentum, volatility, volume, patterns, extremes, support_level, resistance_level, fear_greed, fundamentals, sector_context, garp, potential, or levels (paid tiers). Or pass dotted paths like ohlcv.close, trend.direction, trend.stage, trend.ma_slopes.ma_50, trend.moving_average_values.ma_50_price, trend.ma_crossover_event, trend.direction_meta, trend.distance_from_ma_zone.ma_40, trend.distance_from_ma_pct.ma_40, trend.ma_compression_zone, trend.volume_confirmation_state, momentum.rsi, momentum.rsi_zone, momentum.stochastic_k, momentum.stochastic_zone, momentum.macd_state, patterns.bull_flag_state, patterns.bull_flag_breakout, patterns.ascending_triangle_state, volatility.squeeze_active, volatility.squeeze_periods, volume.ratio_zone, volume.climax_detected, volume.price_on_volume_direction, support_level.level_price, support_level.distance_zone, support_level.status_meta, range_position_zone, breakout_type, fear_greed.score, fear_greed.zone, sector_context.rsi_zone, sector_context.asset_vs_sector_rsi_zone, sector_context.stocks_oversold_count, fundamentals.pe_ratio, fundamentals.peg_ratio, fundamentals.peg_zone, fundamentals.reporting_currency, fundamentals.valuation_zone, fundamentals.free_cash_flow_zone, fundamentals.revenue_zone, fundamentals.earnings_proximity_zone, fundamentals.analyst_consensus_zone, fundamentals.forward_outlook.earnings_zone, fundamentals.insider_activity, garp.score, garp.score_tier, garp.core.score, potential.upside_pct, levels.support_levels. Flat search names (e.g. volume_ratio_zone, fundamentals_peg_ratio, garp_score) and pre-2026-10-31 paths (volume.ratio_band, patterns.bull_flag, fundamentals.revenue) are accepted too; responses use the new keys. trend.stage is populated on weekly snapshots when stage evidence is sufficient."get_universeget_watchlistget_watchlist_changesremove_from_watchlistget_summary1 field changedInput schema / properties / fields / descriptionPrevious value: -"Optional summary fields to return. Identity fields such as market_cap and market_cap_tier are always kept. Pass sections like ohlcv, trend, momentum, volatility, volume, patterns, extremes, support_level, resistance_level, fundamentals, sector_context, or levels (paid tiers). Or pass dotted paths like ohlcv.close, trend.direction, trend.stage, trend.ma_slopes.ma_8, trend.ma_slopes.ma_20, trend.ma_slopes.ma_40, trend.ma_slopes.ma_50, trend.ma_slopes.ma_100, trend.ma_slopes.ma_200, trend.moving_average_values.ma_8, trend.ma_crossover_event, trend.direction_meta, trend.distance_from_ma_band.ma_40, trend.volume_confirmation, momentum.rsi_zone, momentum.stochastic_zone, momentum.xtrm_score, momentum.divergence_detected, momentum.divergence_type, momentum.macd_state, patterns.bull_flag, patterns.bull_flag_breakout, patterns.bear_flag, patterns.bear_flag_breakdown, patterns.ascending_triangle, patterns.rising_wedge, volatility.squeeze_active, volatility.squeeze_days, volatility.regime_trend, volume.climax_detected, volume.climax_type, volume.accumulation_state, volume.price_direction_on_volume, support_level.level_price, support_level.status_meta, resistance_level.level_price, sector_context.rsi_zone, sector_context.trend, sector_context.agreement, sector_context.asset_vs_sector_rsi, sector_context.asset_vs_sector_trend, sector_context.oversold_count, sector_context.valuation_zone, fundamentals.pe_ratio, fundamentals.valuation_zone, fundamentals.growth_zone, fundamentals.free_cash_flow, fundamentals.earnings_proximity, fundamentals.earnings_proximity_basis, fundamentals.last_earnings_surprise, fundamentals.analyst_consensus, fundamentals.analyst_consensus_direction, fundamentals.valuation_percentile, fundamentals.pe_vs_historical_zone, fundamentals.pe_vs_sector_zone, fundamentals.insider_activity, fundamentals.insider_activity.zone, fundamentals.insider_activity.net_direction, levels, levels.support_levels, levels.resistance_levels. trend.stage is populated on weekly snapshots when stage evidence is sufficient. Event field names should prefer full schema names such as momentum_rsi_zone, extremes_condition, trend_stage, pattern_bull_flag, pattern_ascending_triangle, pattern_rising_wedge, trend_ma8_slope through trend_ma200_slope, trend_ma_crossover_event, trend_distance_ma40, fundamentals_valuation_zone, fundamentals_free_cash_flow, insider_zone, sector_rsi_zone, momentum_divergence_detected, and fundamentals_analyst_consensus."New value: +"Optional summary fields to return. Identity fields such as market_cap and market_cap_tier are always kept. Pass sections like ohlcv, trend, momentum, volatility, volume, patterns, extremes, support_level, resistance_level, fundamentals, sector_context, or levels (paid tiers). Or pass dotted paths like ohlcv.close, trend.direction, trend.stage, trend.ma_slopes.ma_8, trend.ma_slopes.ma_20, trend.ma_slopes.ma_40, trend.ma_slopes.ma_50, trend.ma_slopes.ma_100, trend.ma_slopes.ma_200, trend.moving_average_values.ma_8, trend.ma_crossover_event, trend.direction_meta, trend.distance_from_ma_band.ma_40, trend.volume_confirmation, momentum.rsi, momentum.rsi_zone, momentum.stochastic_k, momentum.stochastic_d, momentum.stochastic_zone, momentum.xtrm_score, momentum.divergence_detected, momentum.divergence_type, momentum.macd_state, patterns.bull_flag, patterns.bull_flag_breakout, patterns.bear_flag, patterns.bear_flag_breakdown, patterns.ascending_triangle, patterns.rising_wedge, volatility.squeeze_active, volatility.squeeze_days, volatility.regime_trend, volume.climax_detected, volume.climax_type, volume.accumulation_state, volume.price_direction_on_volume, support_level.level_price, support_level.status_meta, resistance_level.level_price, sector_context.rsi_zone, sector_context.trend, sector_context.agreement, sector_context.asset_vs_sector_rsi, sector_context.asset_vs_sector_trend, sector_context.oversold_count, sector_context.valuation_zone, fundamentals.pe_ratio, fundamentals.valuation_zone, fundamentals.growth_zone, fundamentals.free_cash_flow, fundamentals.earnings_proximity, fundamentals.earnings_proximity_basis, fundamentals.last_earnings_surprise, fundamentals.analyst_consensus, fundamentals.analyst_consensus_direction, fundamentals.valuation_percentile, fundamentals.pe_vs_historical_zone, fundamentals.pe_vs_sector_zone, fundamentals.insider_activity, fundamentals.insider_activity.zone, fundamentals.insider_activity.net_direction, levels, levels.support_levels, levels.resistance_levels. trend.stage is populated on weekly snapshots when stage evidence is sufficient. Event field names should prefer full schema names such as momentum_rsi_zone, extremes_condition, trend_stage, pattern_bull_flag, pattern_ascending_triangle, pattern_rising_wedge, trend_ma8_slope through trend_ma200_slope, trend_ma_crossover_event, trend_distance_ma40, fundamentals_valuation_zone, fundamentals_free_cash_flow, insider_zone, sector_rsi_zone, momentum_divergence_detected, and fundamentals_analyst_consensus."get_ohlcv3 fields changedInput schema / properties / end / descriptionPrevious value: -"Inclusive end date (YYYY-MM-DD)."New value: +"Inclusive end date (YYYY-MM-DD). Compared against the candle date."Input schema / properties / start / descriptionPrevious value: -"Inclusive start date (YYYY-MM-DD). Lookback is limited by plan."New value: +"Inclusive start date (YYYY-MM-DD). Compared against the candle date, so for weekly this is the Sunday week end. Lookback is limited by plan."Input schema / properties / timeframeAdded value: +{
+ "description": "Candle timeframe. Default: daily. Weekly candles cover Monday-Sunday and are dated by the Sunday week end, matching get_summary with timeframe=weekly. The in-progress week is not returned.",
+ "enum": [
+ "daily",
+ "weekly"
+ ],
+ "type": "string"
+}get_watchlist_changesadd_to_watchlistget_watchlistremove_from_watchlistget_accountget_ohlcvget_schemaget_searchget_summaryFree market data with provenance and paid decision intelligence for AI agents.
Evidence-based market data for AI agents deploying capital in DeFi. Empirical, not advertised.
Market intelligence for AI agents. Real-time data, cross-market analysis, and regime detection.
Parsed public-domain market data for AI agents, priced below DIY inference cost, paid via x402.
Add one secure layer between your agents and this server.
