Skip to main content
Glama
Johnhyeon

StockLens

by Johnhyeon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_intraday_chart

Read-onlyIdempotent

Retrieve intraday OHLCV data for Korean and US stocks using intervals from 1 to 240 minutes. Analyze short-term price trends and trading patterns.

Instructions

분봉차트 — 국내·미국 분봉/시간봉 OHLCV (증권사 연결 필요 구간 있음).

증권사(한국투자증권·키움증권 중 하나) Open API 를 연결한 사용자는 주 사용 증권사에서 KR·US 분봉을 받는다. 미연결 사용자는 US 분봉만 Yahoo 에서 받는다 (KR 분봉은 증권사 연결 필요). 검증된 능력만 활성화된다. 일·주·월봉은 기존 get_chart / get_us_chart 를 사용.

Args: symbol: KR 종목코드 6자리 또는 US 티커 market: "KR" | "US" interval: 1m|3m|5m|10m|15m|30m|60m|120m|240m date: 기준 거래일 (YYYY-MM-DD, 기본 최근 거래일) row_limit: 최대 반환 봉 수 (기본 120, 최대 500) venue: KR 은 KRX 고정. US 는 증권사 사용 시 NYS|NAS|AMS 필요 session: "regular" (기타 세션은 능력 검증 후 지원) completed_only: 완성 봉만 반환 (기본 True) source: auto|kis|kiwoom|naver|yahoo. auto 는 주 사용 증권사 하나에 고정되고, 증권사 명시는 strict(실패해도 다른 공급원으로 대체하지 않음)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
venueNo
marketNo
sourceNo
symbolYes
sessionNo
intervalNo
row_limitNo
completed_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.1.3
    • removedInput schema / properties / completed_only / default
      Removed value: -true
    • removedInput schema / properties / date / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / date / default
      Removed value: -null
    • addedInput schema / properties / date / type
      Added value: +"string"
    • removedInput schema / properties / interval / default
      Removed value: -"5m"
    • removedInput schema / properties / market / default
      Removed value: -"KR"
    • removedInput schema / properties / row_limit / default
      Removed value: -120
    • removedInput schema / properties / session / default
      Removed value: -"regular"
    • removedInput schema / properties / source / default
      Removed value: -"auto"
    • removedInput schema / properties / venue / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / venue / default
      Removed value: -null
    • addedInput schema / properties / venue / type
      Added value: +"string"
  2. Addedv1.0.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavior beyond that: broker-vs-Yahoo data source variability, the KR-bar requirement of a broker connection, "검증된 능력만 활성화된다" (only capability-verified features are enabled) indicating feature gating, strict-mode semantics for source (no fallback on failure), and session limiting to "regular". These are the operational traits an agent needs to predict what will happen at call time.

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?

Well-structured and front-loaded: a one-line purpose title, a compact usage-context paragraph, then a scannable Args block with each parameter on its own line. Every sentence earns its place, though the title's parenthetical "증권사 연결 필요 구간 있음" slightly overlaps with the paragraph that elaborates the broker-connection condition, and the text is dense enough that it requires careful reading.

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 complex 9-parameter tool with zero schema-level parameter descriptions, the definition is nearly complete: it covers data source availability, per-parameter semantics with defaults and enums, session limitations, fallback/strict behavior, and sibling routing. Return structure is handled by the existing output schema, so nothing an agent needs to invoke this tool correctly is missing.

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 description coverage is 0%, so the description carries the full burden, and it fully delivers: all 9 parameters are documented with allowed values (interval set, market KR|US), constraints (venue: KRX fixed for KR, NYS|NAS|AMS for US via broker), defaults (row_limit 120, completed_only True, date = latest trading day), and behavior nuances (auto source fixes to one primary broker; explicit broker is strict). No parameter is left undocumented.

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 opens with a specific resource and scope: "분봉차트 — 국내·미국 분봉/시간봉 OHLCV" (intraday/hourly OHLCV for KR and US markets), which clearly identifies what the tool returns. It also names the sibling alternatives it is not — "일·주·월봉은 기존 get_chart / get_us_chart 를 사용" (daily/weekly/monthly should use get_chart/get_us_chart) — so an agent can distinguish it from the get_chart sibling without inspecting schemas.

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 gives explicit conditions for use: users connected to a broker (Korea Investment or Kiwoom) receive KR/US intraday bars; unconnected users get US-only bars from Yahoo, with KR bars requiring broker connection. It also states the exclusion explicitly — daily/weekly/monthly candles belong to get_chart/get_us_chart — providing both when-to-use and when-not-to-use guidance with named alternatives.

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

Deploy Server

Other Tools