Skip to main content
Glama

get_search

Read-only

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.

Input Schema

NameRequiredDescriptionDefault
endNoDate-range screen end (YYYY-MM-DD), with start.
dateNoHistorical snapshot date (YYYY-MM-DD). Omit for latest per asset class. Do not combine with start/end.
limitNoMax results to return. Tier-gated: Starter 25, Plus 100, Pro 500. Default: 20
startNoDate-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.
fieldsNoJSON-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.
filtersYesJSON-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_byNoTicker 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.
timeframeNoAnalysis timeframe. Default: daily
sort_directionNoSort direction. Default: desc. Use 'asc' for lowest-first (e.g. cheapest valuation percentile).

Output Schema

NameRequiredDescriptionDefault
dataNoThe TickerDB API response payload for this tool call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / date / description
      Previous 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."
    • addedInput schema / properties / end
      Added value: +{
      +  "description": "Date-range screen end (YYYY-MM-DD), with start.",
      +  "type": "string"
      +}
    • changedInput schema / properties / fields / description
      Previous 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."
    • changedInput schema / properties / filters / description
      Previous 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."
    • changedInput schema / properties / sort_by / description
      Previous 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."
    • addedInput schema / properties / start
      Added 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"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.