Skip to main content
Glama
tickerdb

TickerAPI

Official

get_summary

Read-only

Get a pre-computed summary of market intelligence for any stock, crypto, or ETF. Supports snapshots, historical trends, and event analyses to inform trading decisions.

Instructions

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 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. Summary keeps sibling _meta objects off by default; set meta=true or request explicit *_meta fields when paid-tier stability metadata is needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoRange end date (YYYY-MM-DD). Use with start for historical series.
bandNoFilter 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.
dateNoHistorical date (YYYY-MM-DD) for a point-in-time snapshot. Requires Plus or Pro plan. Omit for latest.
metaNoSnapshot 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.
afterNoReturn events after this date (YYYY-MM-DD). Only used with field.
fieldNoBand 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.
limitNoFor 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).
startNoRange start date (YYYY-MM-DD). Use with end for historical series.
statsNoEvent mode only. Add true to return aggregate stats instead of raw event rows.
beforeNoReturn events before this date (YYYY-MM-DD). Only used with field.
fieldsNoOptional 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.
sampleNoDate range mode only. Use 'even' to evenly distribute snapshots across the full start/end range.
tickerYesTicker symbol, e.g. AAPL, BTCUSD, SPY
timeframeNoAnalysis timeframe. Default: daily
context_bandNoOnly 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_fieldNoBand 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_tickerNoCross-asset correlation: a second ticker to filter against (e.g. SPY). Requires context_field and context_band. Plus/Pro only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoThe TickerDB API response payload for this tool call.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false, and the description goes far beyond by disclosing behavioral nuances: it explains that _meta objects are off by default, that certain fields require paid tiers, that identity fields are always returned, and that event mode returns band transition history. It also explains the semantics of 'stats' and 'sample' modes, adding substantial context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long but information-dense, systematically covering modes, fields, and special behaviors. It could be slightly more scannable with bullet points, but every section adds value, and it avoids fluff. The length is justified by the tool's complexity.

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?

Given the tool's 17 parameters and rich output schema, the description is exceptionally complete. It explains all four modes, parameter combinations, output field categories, tier restrictions, and special result behaviors. Even without seeing the output schema, the description gives enough detail to understand the response shape and key fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema provides 100% parameter descriptions, the tool description enriches them by explaining how parameters combine into modes, e.g., 'field' triggers event queries, 'start'+'end' define series, and 'meta' only affects snapshot/history modes. It also clarifies edge cases like negative PE ratio preservation and the distinction between event field names and dotted paths, going well beyond the schema's per-parameter definitions.

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?

The description explicitly states the tool's purpose: 'Get pre-computed market intelligence for a specific stock, crypto, or ETF ticker.' It further differentiates from siblings by describing four distinct modes (snapshot, historical snapshot, historical series, events) and the breadth of intelligence fields, clearly distinguishing it from raw price data tools like get_ohlcv.

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?

The description provides detailed usage guidance by enumerating four modes and their parameters, such as using 'date' for historical snapshot, 'start'/'end' for series, 'field' for events, and 'stats=true' for aggregates. It also clarifies when meta is available and notes paid-tier restrictions, effectively telling the agent how to select the right mode for the task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tickerdb/tickerdb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server