Skip to main content
Glama

get_technical_indicators

Read-onlyIdempotent

Compute daily RSI, MACD, Bollinger Bands, ATR and moving averages for a US or Korean stock, ETF or index to assess momentum and volatility without calculating from raw candles.

Instructions

Daily technical indicators for one US or Korean stock, ETF or index (RSI/MACD/볼린저 밴드, 이동평균). For RSI/MACD/볼린저 of holdings, get symbols from investmcp get_holdings, then call this per symbol instead of computing indicators from raw candles. indicators: up to 6 of {name, params}: rsi {n:14}, macd {fast:12, slow:26, signal:9}, bb {n:20, k:2}, sma/ema/rma {n}, atr {n:14}, stdev, highest, lowest, roc {n}, volume; default rsi, macd and bb. Lengths 2-400; recursive ones (ema, rma, rsi, atr, macd) at most 252, as they need 10 x n warm-up bars. For SMA 20/50/200 pass three sma items. period 1mo | 3mo | 6mo (default) | ytd | 1y | d, at most 260 daily points; history before the window is fetched for warm-up, never reseeded. Returns the close series, one series per indicator output (unit, price or separate panel), a latest table and warnings, including possible split discontinuities. Yahoo daily closes, price return. By default a provisional last bar from today's trades (regular session, or pre-market before the open; never after-hours) ends every series: latest rows give the provisional value with session and time plus confirmed_value for the last confirmed bar (data_quality.bar_status partial). plan_entry and compare_tickers use the same bars and calculation, so their RSI/MACD/ATR match. confirmed_only=true: completed bars only; recursive indicators (RSI/MACD/EMA/ATR) can differ from earlier releases by about 0.001, as all three tools now share one warm-up window. Text: a one-line summary, then the full result as compact JSON (the same object as structuredContent). Show source_line and warnings under the chart. Read-only calculation; no account access or orders.

Input Schema

NameRequiredDescriptionDefault
periodNo1mo | 3mo | 6mo (default) | ytd | 1y | <N>d6mo
symbolYese.g. AVGO, 005930, ^GSPC
indicatorsNodefault rsi, macd, bb
confirmed_onlyNofalse (default): include the latest trade as a provisional value; true: completed daily closes only

Output Schema

NameRequiredDescriptionDefault
okYes
feedNo
nameNo
as_ofNolast completed (confirmed) daily bar date used, exchange-local; provisional values are dated after it
errorNo
latestNo
seriesNo
symbolYes
currencyNo
providerYes
warningsNoshow under the chart or table
freshnessNoper symbol: last confirmed close, latest trade (session, time, source, delay) and status
indicatorsNo
price_modeNolatest (default): the newest trade is included as a provisional value, labelled with its session and time; confirmed_only: completed daily closes onlylatest
price_basisYes
source_lineYesshow under the chart or table
data_qualityYes
latest_as_ofNoUTC time of the newest latest-price trade used; null under confirmed_only or when none is available
retrieved_atYesUTC time of this calculation
resolved_symbolNo
requested_periodYes
effective_end_dateNo
effective_start_dateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations declare read-only and idempotent, but the description adds critical behavior: data source (Yahoo daily closes, price return), provisional last bar handling with session details, confirmed_only effects, warm-up bar requirements, possible split discontinuities, and numerical differences in recursive indicators.

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?

Despite its length, the description is front-loaded with purpose and every sentence adds necessary detail about parameters, behavior, or edge cases. No wasted information; the density 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?

An output schema exists, but the description still provides enough context about returned series, tables, and warnings to set expectations. Combined with annotations and schema, it is fully complete for an agent to call the tool correctly.

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?

Schema coverage is 100%, but the description adds substantial practical constraints not in the schema: max 6 indicators, length limits 2-400 with recursive limit 252, warm-up need of 10x n, how to request multiple SMAs, max 260 daily points, and the meaning of confirmed_only.

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?

States a specific verb and resource: daily technical indicators for a single stock, ETF, or index. Distinguishes from siblings by naming get_holdings for symbol lookup and warning against computing from raw candles, and notes consistency with plan_entry and compare_tickers.

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 says when to use this tool instead of computing indicators manually and how to get symbols for holdings. Also explains the tradeoff of confirmed_only and the consistency guarantee with sibling tools, leaving no ambiguity.

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