에이전트를 사전 계산된 시장 컨텍스트에 연결하여 추론 능력을 향상하고 토큰 사용량을 줄이세요.
TickerDB를 모든 MCP 호환 클라이언트(Claude Desktop, Claude Code, Cursor, Windsurf, OpenClaw, LangChain, LlamaIndex, AutoGen, CrewAI 등)에 연결할 수 있습니다.
도구 | 설명 |
| 단일 티커에 대한 기술적 + 기본적 요약 (날짜 범위, 이벤트 필터링, MA 거리 룩백 지원) |
| 필터를 사용하여 범주별 상태로 자산 검색 |
| 사용 가능한 필드 및 필터 옵션 확인 (항상 무료, 0 크레딧) |
| 저장된 관심 종목 티커에 대한 실시간 데이터 |
| 마지막 파이프라인 실행 이후의 필드 수준 차이 |
| 관심 종목에 티커 추가 |
| 관심 종목에서 티커 제거 |
| 계정 세부 정보, 플랜 등급 및 사용량 |
| 관심 종목 변경에 대한 웹훅 등록 |
| 등록된 웹훅 목록 |
| 웹훅 제거 |
모든 도구는 모든 등급(Free, Plus, Pro)에서 사용할 수 있습니다. 등급은 속도 제한, 기록 깊이, 관심 종목 크기에 따라 다릅니다. 자세한 내용은 tickerdb.com/pricing을 참조하세요.
get_summary를 start/end 매개변수와 함께 사용하여 날짜 범위에 걸쳐 티커를 대량 동기화하거나, field/band 매개변수와 함께 사용하여 이벤트 발생을 쿼리하세요. 원시 행 대신 집계된 이벤트 밴드 및 여파 분포를 원할 경우 이벤트 모드에서 stats=true를 추가하세요.
get_watchlist는 시간 프레임을 사용하지 않습니다. 일일 또는 주간 차이를 보려면 get_watchlist_changes를 사용하세요.
현재 요약 스냅샷은 as_of_date를 통한 최상위 신선도, price_direction_on_volume과 같은 더 풍부한 volume 필드, support_level.status_meta와 같은 유료 등급 수준의 메타데이터, agreement 및 overbought_count와 같은 Pro sector_context 필드, 그리고 사용 가능한 경우 주식 전용 중첩 fundamentals.insider_activity를 노출합니다.
MA 거리 필드는 스택 전체에서 사용할 수 있습니다:
trend_distance_ma8, trend_distance_ma20, trend_distance_ma50, trend_distance_ma100, trend_distance_ma200과 같은 플랫 스키마/검색/이벤트 이름을 사용하세요.
요약 스냅샷은 trend.distance_from_ma_band.ma_8에서 ma_200까지 중첩된 MA 거리 밴드를 노출합니다.
MA 이벤트 쿼리는 slightly_above와 같은 세분화된 값 외에도 그룹화된 band=above 및 band=below 별칭을 지원합니다.
get_summary는 기본적으로 기본 밴드 레이블이 전면에 유지되도록 형제 _meta 객체를 제외합니다. 응답 전체에 전체 유료 등급 안정성 메타데이터를 포함하려면 meta: true를 전달하거나, 원하는 특정 *_meta 필드만 요청하세요. get_watchlist는 기본적으로 유료 등급 _meta 객체를 포함하며, get_watchlist_changes는 각 변경 객체에 안정성 필드를 인라인으로 반환합니다.
안정성 레이블은 fresh, holding, established, volatile 중 하나입니다. 전체 메타데이터에는 periods_in_current_state, flips_recent, flips_lookback이 포함되어 있어 에이전트가 새로 진입한 상태와 여러 기간 동안 지속된 상태를 구분하는 데 도움이 됩니다.
Related MCP server: FinanceKit MCP
mcp.tickerdb.com의 원격 서버는 Claude.ai 커넥터를 위한 OAuth 2.1을 지원합니다. API 키 관리가 필요하지 않습니다. TickerDB 계정으로 로그인하면 Claude.ai가 나머지를 처리합니다.
API 키를 Bearer 토큰으로 사용하여 모든 MCP 클라이언트를 https://mcp.tickerdb.com/mcp에 연결하세요.
Claude Desktop 구성(claude_desktop_config.json)에 추가하세요:
{
"mcpServers": {
"tickerdb": {
"command": "npx",
"args": ["tickerdb-mcp"],
"env": {
"TICKERDB_KEY": "tdb_your_api_key_here"
}
}
}
}tickerdb.com/dashboard에서 API 키를 받으세요.
이것은 3개의 패키지로 구성된 워크스페이스입니다:
shared/ — 공유 도구 정의, API 클라이언트 및 서버 팩토리 (내부용, 게시되지 않음)
remote/ — mcp.tickerdb.com에 배포된 Cloudflare Worker (스트리밍 가능한 HTTP 전송 + OAuth 2.1)
local/ — 게시된 npm 패키지 tickerdb-mcp (stdio 전송)
원격 서버와 npm 패키지 모두 shared/의 동일한 도구 정의를 사용합니다. MCP 서버는 씬 프록시이며, 모든 등급 기반 액세스 제어, 속도 제한 및 필드 필터링은 TickerDB HTTP API에 의해 처리됩니다.
원격 서버는 두 가지 인증 방법을 지원합니다:
Bearer 토큰 — tdb_* API 키를 Authorization: Bearer tdb_...로 직접 전달
OAuth 2.1 — Claude.ai 커넥터에서 사용. 서버는 동적 클라이언트 등록, PKCE, 토큰 교환 및 취소를 구현합니다. /authorize 엔드포인트는 동의를 위해 메인 TickerDB 사이트로 리디렉션합니다.
혼합 인증을 사용하는 OAuth 기반 MCP 클라이언트의 경우, 워커는 POST /mcp에서 인증되지 않은 initialize 및 tools/list 검색을 허용하지만 실제 도구 실행에는 인증이 필요합니다. 보호된 도구 호출은 /.well-known/oauth-protected-resource/mcp를 가리키는 resource_metadata와 함께 표준 401 Bearer 챌린지를 반환하여 클라이언트가 다시 인증하거나 깔끔하게 다시 마운트할 수 있도록 합니다.
원격 워커는 기본적으로 상태 비저장(stateless) MCP 전송을 사용합니다. 이는 의도적인 것입니다. 모든 TickerDB MCP 도구는 요청/응답 상태 비저장 방식인 반면, Cloudflare Worker 메모리는 격리된 로컬이며 요청 간에 드리프트될 수 있기 때문입니다. 상태 비저장 전송을 기본값으로 설정하면 커넥터가 발견한 link_... 네임스페이스를 무효화할 수 있는 에지 세션 손실을 방지합니다. 상태 비저장 모드에서 워커는 POST /mcp 요청만 수락하고, JSON 요청/응답 모드를 사용하며, 커넥터 런타임이 실수로 상태 저장이 의도되지 않은 네임스페이스를 삭제하거나 다시 바인딩하지 않도록 GET/DELETE 세션 수명 주기 요청을 거부합니다.
명시적인 MCP 세션 동작을 디버그해야 하는 경우 MCP_SESSION_MODE=stateful로 설정하세요. 해당 모드에서는 오래되었거나 누락된 Mcp-Session-Id 헤더가 새로운 전송으로 조용히 다운그레이드되는 대신 명시적인 오류를 반환합니다.
# Install dependencies
npm install
# Type-check the remote worker/shared sources
npm run build
# Dev server for remote worker
npx wrangler dev
# Build the npm package
cd local && npm install && npm run build원격 서버:
npx wrangler deploynpm 패키지 + MCP 레지스트리 (권장):
# From the monorepo root
export MCP_PUBLISHER_KEY="your_saved_tickerdb_registry_private_key_hex"
./release.sh mcp patch이 작업은 local/package.json 버전을 올리고, server.json을 동기화 상태로 유지하며, tickerdb-mcp를 npm에 게시하고, tickerdb.com에 대한 DNS 인증을 새로 고치며, MCP 서버 메타데이터를 공식 MCP 레지스트리에 게시합니다.
npm 패키지 전용 (수동):
cd local
npm version patch
npm run build
npm publishAdd 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, and ma200, 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 indicate read-only and non-destructive behavior, so the description doesn't need to repeat that. It adds valuable context about filter encoding, field naming conventions, and server-side sorting, which helps agents understand the tool's expected inputs and behavior. No contradictions 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 a single dense paragraph but front-loaded with the core purpose. Every sentence provides useful information about filter types, field naming, and usage. While somewhat long, it avoids fluff and structures the information logically.
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, annotations available), the description covers key aspects: search use cases, filter format, field discoverability, and column/sort control. It leaves mention of pagination and defaults to the schema, which is acceptable given the output schema exists.
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%, so the baseline is 3. The description adds extra meaning by explaining the JSON-encoded filter format, listing example semantic fields, and clarifying the distinction between raw and expanded field names, which goes beyond the schema's property 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 it searches for assets matching filter criteria, including categorical states and rankings by fields. It distinguishes itself from sibling tools like get_summary and get_ohlcv by focusing on filtered asset search, making 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?
The description gives clear context for when to use the tool (searching assets with filters) and provides a cross-reference to get_schema for field discovery. It does not explicitly state when not to use it versus alternatives, but the guidance on filters and fields implies its role as the primary search tool.
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 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.
| 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_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. | |
| 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?
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.
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.
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.
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.
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.
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.
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.
v0.1.0add_to_watchlistget_accountget_ohlcvget_schemaget_searchget_summaryget_watchlistget_watchlist_changesremove_from_watchlistScored across 9 tools
Each tool targets a distinct resource/action. get_summary is for single-ticker analytics, get_watchlist for full watchlist summaries, get_watchlist_changes for deltas, and get_ohlcv for raw candles. Descriptions explicitly clarify when to use which, even in overlapping areas.
All read operations use get_ prefix (get_summary, get_ohlcv, get_search, get_schema, get_account, get_watchlist, get_watchlist_changes) and write operations use add_to_/remove_from_ (add_to_watchlist, remove_from_watchlist). The pattern is consistent and predictable.
9 tools is well within the ideal 3-15 range. The toolset covers market data retrieval, search, schema discovery, account management, and watchlist CRUD + monitoring — each tool earns its place with a clear purpose.
The domain is well covered: field discovery (get_schema), asset search (get_search), single-ticker analytics (get_summary), price history (get_ohlcv), watchlist management (add/remove/list/changes), and account status. No obvious dead ends or missing core operations.
Market intelligence for AI agents. Real-time data, cross-market analysis, and regime detection.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
Prediction markets, on-chain flows, ETF flows, equities and macro intelligence for AI agents.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
