Skip to main content
Glama
Johnhyeon

StockLens

by Johnhyeon

get_supply_pressure

Read-onlyIdempotent

Retrieve Korean stock supply pressure indicators including program trading, short selling, credit, securities lending, foreign holding, and CFD to assess market imbalance.

Instructions

수급압력 - 프로그램매매·공매도·신용·대차·외국인보유 (JSON).

종류를 여러 개 물어도 응답은 종류별 블록으로 나뉜다. 각 블록이 자기 status·provider·granularity·data_as_of·경고를 따로 갖는다. 서로 다른 종류를 하나의 점수나 숫자로 합치지 않는다. 합쳐서 만든 지표는 어느 원본에서 왔는지 되짚을 수 없다.

읽을 때 반드시 지킬 것:

  • statusok 가 아닌 블록은 데이터가 없는 것이 아니라 받지 못한 것이다. unavailable_reason 을 함께 읽는다. 0 으로 읽거나 '해당 없음'으로 요약하지 않는다.

  • granularity 를 확인한다. 프로그램매매는 한국투자증권이 장중 시계열, 키움증권이 일별이다. 모양이 다른 두 숫자를 같은 기준으로 비교하지 않는다.

  • 각 값의 단위는 measure_units 를 따른다. 확인된 가격과 금액은 KRW, 수량은 shares, 비율은 percent 로 정규화된다. unknown 은 공급자 단위를 확인하지 못해 원값을 유지한 것이므로 환산을 추측하지 않는다.

  • 장중 시계열의 실제 관측 시각은 행의 observed_at 을 읽는다. date 만 보고 서로 다른 장중 시점을 같은 값으로 합치지 않는다.

  • 대차잔고는 공매도 실행이 아니다. 대차는 빌린 주식의 잔고이고, 공매도는 실제 매도 체결이다. 대차잔고 증가를 공매도로 옮겨 적지 않는다.

  • securities_lending 은 키움증권만 종목 단위로 준다. 한국투자증권은 시장 전체 값만 있어 종목별 답으로 쓰지 않는다(market_level_only).

  • 국내(KR) 전용이다.

Args: code: KR 종목코드 6자리 (단건) codes: 종목코드 목록 (최대 30개) kind: 종류 하나 kinds: 종류 목록. program_trading | short_selling | credit | securities_lending | foreign_holding | cfd days: 조회 기간(일, 기본 30) source: auto|kis|kiwoom (auto 는 주 사용 증권사 하나에 고정)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo
daysNo
kindNo
codesNo
kindsNo
sourceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv1.1.3
    • removedInput schema / properties / code / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / code / default
      Removed value: -null
    • addedInput schema / properties / code / type
      Added value: +"string"
    • removedInput schema / properties / codes / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "type": "string"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / codes / default
      Removed value: -null
    • addedInput schema / properties / codes / items
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / codes / type
      Added value: +"array"
    • removedInput schema / properties / days / default
      Removed value: -30
    • removedInput schema / properties / kind / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / kind / default
      Removed value: -null
    • addedInput schema / properties / kind / type
      Added value: +"string"
    • removedInput schema / properties / kinds / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "type": "string"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / kinds / default
      Removed value: -null
    • addedInput schema / properties / kinds / items
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / kinds / type
      Added value: +"array"
    • removedInput schema / properties / source / default
      Removed value: -"auto"
  2. Addedv1.0.1

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses substantial behavioral detail: responses are split into per-kind blocks with independent status/provider/granularity/data_as_of, non-ok status means data was not received rather than missing, granularity differs by provider, units follow measure_units, and observed_at must be used for intraday timing. It also clarifies the lending-vs-short-selling distinction. No contradiction with the read-only/idempotent annotations.

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?

Though long, the description is tightly organized: a brief opening, a set of high-value 'must-read' bullets, and a compact Args list. Every sentence contributes operational meaning, and the most critical interpretation warnings are front-loaded. There is no filler or repetition.

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 tool with 6 parameters, 0% schema coverage, and an output schema, the description is remarkably complete: it explains response structure, status semantics, granularity, units, timing, provider limitations, and domain pitfalls. It gives an agent everything needed to both request and correctly interpret the data.

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 must carry the full parameter burden, and it does: all six parameters are explained with types, constraints, defaults, and enums (e.g., code is a 6-digit KR code, codes max 30, days defaults to 30, source is auto|kis|kiwoom, kinds includes program_trading|short_selling|credit|securities_lending|foreign_holding|cfd). This fully compensates for the bare input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line clearly names the resource ('수급압력' / supply pressure) and enumerates the exact data categories: program trading, short selling, credit, securities lending, and foreign holdings. The scope is explicitly limited to KR equities. However, the description lacks an explicit verb and never differentiates itself from sibling tools like get_flow or get_detailed_investor_flow, so it stops short of a 5.

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 when-not-to-use guidance, such as '대차잔고는 공매도 실행이 아니다' and the warning that KIS securities lending is market-level only and must not be used for per-stock answers. It also states source-selection behavior ('auto 는 주 사용 증권사 하나에 고정') and the KR-only boundary. This is strong, actionable usage guidance despite not naming sibling tools.

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