Skip to main content
Glama

TickerDB

by com.tickerdb

get_watchlist_changes

Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeframeNoChange comparison period. daily = day-over-day, weekly = week-over-week. Default: daily

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark it read-only and non-destructive; the description adds valuable context: data is based on the last pipeline run, stability metadata requires a Plus/Pro plan, and it returns only changed items. No contradiction with annotations exists.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: core function, supported comparisons, plan limitation, and sibling comparison. Front-loaded with the action, no fluff or redundancy.

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?

The description is complete for a monitoring tool: it covers purpose, usage guidance, alternatives, plan restrictions, and temporal scope. An output schema exists, so lack of return-value detail is not a gap.

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

Parameters3/5

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

The only parameter, timeframe, is fully documented in the schema with enum values and default behavior. The description adds no additional parameter semantics beyond what the schema already provides; baseline 3 applies due to 100% schema coverage.

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?

Description clearly states it gets field-level state changes for watchlist tickers since the last pipeline run, supporting daily and weekly comparisons. It also distinguishes itself from the sibling get_watchlist by noting it returns only deltas, making its scope precise.

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?

Explicitly recommends preferring this tool over get_watchlist for monitoring questions and provides a clear alternative: use get_watchlist when the full current state is needed. Also notes it is the only source for week-over-week changes, giving concrete when-to-use guidance.

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

All TickerDB toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources