Pre-computed market data that improves agent reasoning, reduces token usage, and replaces pipelines.
Scored across 9 tools
Each tool targets a distinct resource/action: watchlist mutations, account info, raw candles, schema metadata, filtered searches, per-ticker summaries, and watchlist-wide summaries/deltas. The descriptions explicitly call out when to prefer one tool over another, especially get_watchlist vs get_summary vs get_watchlist_changes.
Tool names follow a consistent get_* pattern for retrieval operations, with add_to_watchlist and remove_from_watchlist as clear mutating counterparts. snake_case verb_noun naming is uniform across all 9 tools.
Nine tools is well within the ideal range and each tool earns its place. The set covers data discovery, analytics, raw data access, account management, and watchlist lifecycle without redundant or bloated surface area.
The domain of market intelligence and watchlist management is well covered: search/screen, per-ticker summaries, OHLCV data, watchlist add/remove/list, change tracking, schema discovery, and account limits. No obvious dead ends or missing core operations for the stated purpose.
Add tickers to the user's saved watchlist. Duplicates are skipped. Only call this when the user explicitly asks to track, save, or watch a ticker; do not add tickers just because they came up in conversation. The watchlist is capped by the plan's watchlist_limit (see get_account), so the request can be rejected or accepted only in part. Report back which tickers the response actually confirms rather than assuming every requested ticker was added.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Array of ticker symbols to add, e.g. ["AAPL", "MSFT", "BTCUSD"] |
| 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 annotations (idempotentHint, readOnlyHint false), the description discloses that duplicates are skipped, that the watchlist has a plan-dependent cap that can cause partial acceptance, and that the agent should report confirmed tickers rather than assuming all were added. This adds meaningful behavioral transparency that annotations alone do not provide.
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 four sentences, each serving a distinct purpose: purpose, idempotency, usage condition, and limit/reporting. It is front-loaded with the primary action and contains no redundant or filler content.
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 an add-to-watchlist tool with an output schema present, the description covers when to call, duplicate handling, plan limits, partial acceptance, and reporting requirements. The sibling tools and annotations complement this, making the description complete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'tickers' parameter with an example array (['AAPL', 'MSFT', 'BTCUSD']), achieving 100% schema description coverage. The description does not add additional parameter-level detail beyond referencing tickers in context, so the baseline 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Add tickers to the user's saved watchlist', a specific verb+resource statement that clearly distinguishes the tool from the sibling get_watchlist and remove_from_watchlist. The duplicate-skipping behavior further clarifies the operation's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Only call this when the user explicitly asks to track, save, or watch a ticker; do not add tickers just because they came up in conversation.' It also points to get_account for the plan's watchlist_limit, providing a cross-reference for capacity constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your account details including current plan tier, monthly credit limits, and current usage. Response includes tier, limits (monthly_requests, overage_enabled, watchlist_limit, search_results, webhook_urls, 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 and destructiveHint=false. The description adds useful context about response fields, pending plan changes, and pay-per-use credit balances, exceeding the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the main purpose, then structured enumeration of response fields. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with strong annotations and an existing output schema, the description fully covers response details and special cases (pay-per-use, pending plan changes). It leaves no material gaps for an agent to misuse the 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?
The input schema has zero parameters, so schema coverage is trivially 100%. With no parameters to explain, the baseline of 4 applies, and the description appropriately focuses on response semantics rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account details including plan tier, limits, and usage, distinguishing it from sibling tools that handle market data or watchlist operations. The verb 'get' plus specific resource delineation makes the purpose unambiguous.
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?
Though it doesn't explicitly name alternatives, the scope 'your account' contrasts sharply with sibling tools focused on market data or watchlists, making the intended use clear. It lacks explicit when/when-not guidance, but the context is strong enough to infer.
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. Equity and ETF bars are split-and-dividend adjusted; crypto bars are unadjusted. 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. |
| 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 annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses crucial behaviors: pagination via next_cursor, split/dividend adjustments for equities vs. unadjusted crypto, and a specific credit cost formula. This adds significant context for expected behavior and side effects.
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 compact yet information-dense, using five sentences to cover purpose, use case, pagination, adjustment policy, and cost. Every sentence contributes unique value without redundancy or fluff.
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 tool's complexity (7 parameters, output schema present, multiple asset types), the description covers all essential aspects: what it does, when to use it, pagination, adjustment nuances, and cost implications. It references siblings appropriately and works well with the rich 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?
With 100% schema coverage, the schema already documents all parameters. The description adds value by clarifying pagination usage ('pass next_cursor back as cursor') and the credit cost tied to the limit parameter, which enhances understanding of cursor and limit beyond their schema 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?
The description clearly states the tool retrieves stored end-of-day OHLCV candles for stocks, ETFs, or crypto, with daily or weekly timeframes. It uses a specific verb ('Get') and resource ('OHLCV candles'), and distinguishes itself from siblings like get_summary by its focus on historical candle data.
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 specifies when to use: 'Use this for exact-return calculations, charts, and backtests after get_summary identifies a setup.' This provides clear context and references the sibling get_summary as a precursor, making the workflow obvious.
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. Use this when the user asks 'what fields are available?', 'what bands does momentum_rsi_zone have?', 'what sectors exist?', or when you need to validate field/band names before calling get_summary with event parameters or get_search with filters.
| 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 and destructiveHint=false, so the safety profile is covered. The description adds context about the tool's role in validation and references downstream tools (get_summary, get_search), which enriches behavioral understanding without contradicting 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?
Two compact sentences. The first sentence is a clear, direct statement of purpose; the second provides quick usage contexts and integration points. No wasted words.
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 no-parameter, read-only schema tool with an output schema present, the description fully covers what it does, when to use it, and how it relates to sibling tools. Nothing critical 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?
With zero parameters, the baseline is 4. The description adds meaning by explaining what the returned schema contains (fields and valid band values), which is useful even though no parameters need explaining.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the schema of all available fields and their valid band values.' It names the specific resource (schema) and provides concrete example user queries, distinguishing it from sibling tools like get_summary or get_search by positioning it as a validation/preparatory step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use scenarios: user questions about fields, bands, sectors, and validating names before get_summary/get_search. It does not state when-not-to-use or alternative tools, but the guidance is clear enough to be more than merely implied.
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) or rankings by a field such as market_cap on a historical date. Pass filters as a JSON-encoded array of {field, op, value} objects. Use get_schema to discover valid field names; fields use clean flat names for raw values such as pe_ratio, ma8, ma200, momentum_rsi, momentum_stochastic_k, and momentum_stochastic_d (aliases rsi, stochastic_k, stochastic_d accepted; all three are 0-100, null while lookbacks form, filterable and sortable, available for stocks, ETFs, and crypto), and full expanded names for semantic fields such as momentum_rsi_zone, pattern_bull_flag, pattern_bull_flag_breakout, pattern_bear_flag_breakdown, pattern_ascending_triangle, pattern_rising_wedge, trend_ma_crossover_event, trend_distance_ma40, trend_stage, fundamentals_free_cash_flow, insider_zone, sector_agreement, volatility_squeeze_active, volume_climax_detected, fundamentals_analyst_consensus, and fundamentals_earnings_proximity, fundamentals_earnings_proximity_basis. Use fields to control returned columns and sort_by to rank results server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Historical snapshot date (YYYY-MM-DD). Omit for latest per asset class. | |
| limit | No | Max results to return. Tier-gated: Starter 25, Plus 100, Pro 500. Default: 20 | |
| fields | No | 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. | |
| 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"}] | |
| sort_by | No | 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. | |
| 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 mark the tool as readOnly and non-destructive, and the description adds meaningful behavioral context beyond that: server-side sorting, default field subsets, tier-gated limits, weekly-only fields, paid-tier restrictions, and null-while-lookbacks behavior for momentum indicators. There is no contradiction with 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?
The description is long but front-loaded with the core purpose and filter syntax. The extensive field-name enumerations are justified by the tool's complexity, and most sentences carry operational guidance. It could be tightened slightly by condensing repeated examples, but it remains focused and useful.
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 tool's complexity, the description covers filter construction, field discovery, sorting behavior, default outputs, timeframe handling, tier limits, and specialty fields. An output schema exists, so return-value documentation is not required. Nothing essential for correct invocation 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?
Although schema coverage is 100%, the description substantially enriches parameter understanding with naming conventions (flat raw names vs expanded semantic names), aliases, explicit examples of filter objects, default field lists, and caveats like stock-only free cash flow. This goes well beyond the schema's individual 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?
The description opens with 'Search for assets matching filter criteria', which states a specific verb and resource, and goes on to enumerate categorical states and ranking modes. This clearly distinguishes get_search from siblings like get_watchlist, get_summary, and get_schema. The scope is unambiguous.
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 explicitly says to use get_schema to discover valid field names, and provides concrete conditional guidance such as requesting fundamentals_free_cash_flow explicitly when needed, using timeframe=weekly for trend_stage, and specifying fields to reduce token usage. It also notes tier gating and paid-tier field availability, which helps the agent decide acceptable calls.
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, including aftermath fields on paid tiers, weekly trend_stage analysis, pattern setup states such as pattern_bull_flag and pattern_ascending_triangle, MA signal fields, trend_ma_crossover_event, MA distance lookbacks such as trend_distance_ma40, and stock-only fundamentals_free_cash_flow events. Add stats=true in event mode to return aggregate event-band and aftermath distributions instead of raw rows. Results can include freshness via as_of_date, same-candle OHLCV, market_cap, market_cap_tier, trend, momentum (including raw rsi, stochastic_k, stochastic_d alongside their zones, divergence_detected, divergence_type, stochastic_zone), volatility (including squeeze_active, squeeze_days), volume (including climax_detected, climax_type), patterns, support/resistance, levels (paid tiers), sector_context (rsi_zone, trend, agreement, asset_vs_sector_rsi), and stock-only fundamentals such as raw pe_ratio (latest ratio on or before the snapshot date; negative values preserved and unavailable values null), free_cash_flow, growth_zone, earnings_proximity, earnings_proximity_basis, analyst_consensus, valuation_percentile, and nested insider_activity when available. Raw momentum values (momentum.rsi 0-100, momentum.stochastic_k, momentum.stochastic_d) are the exact numbers behind their zones for all asset classes and both timeframes, null while lookbacks form; query zone transitions via momentum_rsi_zone / momentum_stochastic_zone, not the raw values. 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). For MA distance event fields such as trend_distance_ma40, 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, 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. | |
| 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 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. | |
| 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 | |
| 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). 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?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses many important behaviors: paid-tier limitations, raw momentum values being 'null while lookbacks form', default exclusion of _meta objects, and the instruction to query zone transitions via momentum_rsi_zone instead of raw values. It does not contradict the 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?
The description is front-loaded with purpose and mode definitions, but it is a long, dense block that repeats many field names also present in the schema, such as trend, momentum, volatility, patterns, and support/resistance. The length is partly justified by the tool's complexity, but structured bullets would have made it far more scannable.
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 17 parameters, multi-mode behavior, and an output schema, this description is exceptionally complete: it covers mode selection, parameter combinations, paid-tier constraints, field semantics, and default meta behavior. Nothing needed to invoke the tool correctly appears to be 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?
While schema coverage is 100%, the description adds substantial semantic value by grouping parameters into modes and explaining interdependencies, such as band being 'Only used with field' and context_ticker requiring context_field and context_band. It also clarifies field-level semantics like raw pe_ratio preserving negative values and returning null when unavailable.
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 'Get pre-computed market intelligence for a specific stock, crypto, or ETF ticker,' providing a clear verb, resource, and asset scope. It goes on to name four distinct modes, which clarifies exactly what the tool does and aligns with the analytical summary role implied by its sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context for each mode: 'Snapshot (default)', 'Historical snapshot by date', 'Historical series with start and end dates', and 'Events by field and optional band'. It also specifies when to use stats=true and meta=true, but it does not explicitly mention sibling tools or when NOT to use this tool in favor of an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytical summaries for every ticker on the user's saved watchlist. This supports requests about the user's watchlist, tracked stocks, portfolio tickers, or an overview of tracked assets. Each item includes trend, momentum, volatility, volume, extremes, support/resistance prices, and a notable_changes array of human-readable day-over-day change alerts (e.g. 'entered deep_oversold', 'volume spike', 'trend reversed to downtrend', 'earnings within days', 'squeeze activated', 'MA crossover: golden cross'). Additional per-item fields include squeeze_active, squeeze_days, climax_detected, climax_type, divergence_detected, divergence_type. Plus/Pro plans also return analyst_consensus, earnings_proximity, growth_zone, free_cash_flow. Pro plans also return insider_activity and insider_net_direction. Band fields include _meta stability objects on Plus and Pro plans. Use this only for questions that span the whole tracked set; for a question about one specific ticker use get_summary instead, even if that ticker is on the watchlist. When the question is only whether anything changed, prefer get_watchlist_changes: it returns just the deltas, whereas this returns a full summary per ticker and grows large on a watchlist of many assets. Use add_to_watchlist to save tickers first; an empty watchlist means the user has not saved any tickers yet, not that the lookup failed.
| 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 and destructiveHint=false, and the description adds valuable behavioral context beyond that: it enumerates the analytical fields returned, notes plan-dependent fields (Plus/Pro and Pro-only), warns that the response grows large on many assets, and clarifies that an empty watchlist is not a failure. This fully discloses the tool's 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 long but front-loaded with the core purpose, follows with a detailed field enumeration, and ends with usage guidance. Every sentence adds value, though the 'supports requests about...' sentence is somewhat redundant with the first sentence. It is dense but efficient for such a rich output.
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 focuses on high-level semantics and usage decisions. It fully explains the tool's scope, the meaning of an empty watchlist, plan-dependent field availability, and alternatives for narrower queries. This is complete for an analyst agent to select and invoke 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 has zero parameters and the input schema is empty, so there are no parameter semantics to elaborate. The description fully covers the invocation context by describing what the tool operates on (the user's saved watchlist) and what it returns. Baseline for 0 params is 4, and the description exceeds any need by clarifying plan-dependent outputs.
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+resource: 'Get analytical summaries for every ticker on the user's saved watchlist.' It clearly differentiates from siblings by naming get_summary for single tickers and get_watchlist_changes for change-only queries, making the purpose distinct and unambiguous.
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 explicitly states when to use this tool ('only for questions that span the whole tracked set') and when not to ('for a question about one specific ticker use get_summary instead', 'prefer get_watchlist_changes' for change detection). It also advises using add_to_watchlist first and clarifies that an empty watchlist is a valid state, not an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get field-level state changes for all tickers on the user's saved watchlist since the last pipeline run. Supports daily day-over-day and weekly week-over-week comparisons. Each change object includes stability metadata such as stability, periods_in_current_state, flips_recent, and flips_lookback when available. Stability metadata requires a Plus or Pro plan. Prefer this over get_watchlist for monitoring questions such as whether anything moved, turned bearish, or became overbought, and for tracking a watchlist over time: it returns only what changed, while get_watchlist returns full summaries for every tracked ticker and is far larger on a big watchlist. Use get_watchlist when the current state of the whole list is needed rather than just the deltas. This is the only way to get week-over-week changes; the notable_changes array on get_watchlist is day-over-day only.
| Name | Required | Description | Default |
|---|---|---|---|
| timeframe | No | Change comparison period. daily = day-over-day, 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?
Annotations already declare readOnlyHint and destructiveHint false. The description adds valuable behavioral context: it returns only changed records, requires a Plus or Pro plan for stability metadata, and works relative to the last pipeline run. This goes beyond annotation coverage.
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 longer but every sentence contributes: core function, supported comparisons, metadata plan requirement, and guidance versus sibling tools. It is front-loaded and well-structured, though slightly verbose.
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 tool's complexity and existing output schema, the description covers the data scope, use cases, and plan limitations. It explains why this tool should be chosen over get_watchlist and mentions the day-over-day only limitation of the sibling's notable_changes array.
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% with the enum described. The description adds meaning by explaining 'daily' as day-over-day and 'weekly' as week-over-week, and notes the default. This supplements the schema without repeating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets field-level state changes for watchlist tickers since the last pipeline run, with a specific verb and resource. It also distinguishes itself from get_watchlist by emphasizing it returns only deltas, not full summaries.
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 provides when-to-use and when-not-to-use guidance: prefer it over get_watchlist for monitoring changes, use get_watchlist for current full state, and notes it is the only way to get week-over-week changes. Names the alternative tool directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove tickers from the user's saved watchlist. Only call this when the user explicitly asks to stop tracking, remove, or drop a ticker; never prune the watchlist on your own initiative. Removal only stops tracking and can be undone with add_to_watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Array of ticker symbols to remove, e.g. ["MSFT"] |
| 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?
The annotations already indicate write/destructive/idempotent traits, but the description adds that removal 'only stops tracking and can be undone with add_to_watchlist,' clarifying scope and reversibility beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, usage guidance, and behavioral context without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter removal tool with detailed annotations and an output schema, the description fully covers purpose, constraints, and consequences, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'tickers' is fully described in the schema with an example. The tool description does not add additional parameter-specific details, so the baseline 3 applies given 100% schema coverage.
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 leads with a specific verb+resource statement: 'Remove tickers from the user's saved watchlist.' It clearly distinguishes from siblings like add_to_watchlist and get_watchlist by stating the removal action and its reversibility.
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 explicitly states when to use ('when the user explicitly asks to stop tracking, remove, or drop a ticker') and when not to ('never prune the watchlist on your own initiative'), and names add_to_watchlist as the undo alternative.
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_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_summaryEvidence-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.
Cross-asset market data and LLM inference for AI agents. Pay-per-call in USDC via x402.
Add one secure layer between your agents and this server.
