Skip to main content
Glama
tossinvest-mcp

tossinvest-mcp

by clauzewitz

get_sellable_quantity

Read-onlyIdempotent

Retrieve the sellable quantity of a Korean or US stock symbol for an account, so you can confirm how many shares are available to sell before placing an order.

Instructions

종목의 매도 가능 수량을 조회한다.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "get_sellable_quantity"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYes종목 심볼. 국내는 6자리 종목코드(예: 005930), 미국은 티커(예: AAPL)
account_seqNo계좌 accountSeq (list_accounts 로 확인). 생략하면 TOSSINVEST_ACCOUNT_SEQ 설정값

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — it does not explain what 'sellable quantity' accounts for (holdings minus pending sell orders, per-account vs. aggregate) or how openWorld behavior affects results.

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?

A single sentence with zero filler, front-loaded with the resource being queried. It is efficient, though the terseness borders on under-specification rather than deliberate structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should indicate what is returned (a numeric quantity, in what units, for which account). It also leaves unclear whether the sellable quantity is per-account, currency-specific, or net of pending sell orders — critical context for correct interpretation.

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?

Schema description coverage is 100%, with both symbol and account_seq documented in the schema including formats and the fallback to TOSSINVEST_ACCOUNT_SEQ. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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 description states a specific verb and resource ('종목의 매도 가능 수량을 조회한다' = look up a stock's sellable quantity), which is more precise than the bare tool name. It does not, however, distinguish this from related siblings such as get_holdings or get_buying_power, which an agent could easily confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus get_holdings or get_buying_power, no mention of prerequisites (e.g., that an account context is needed), and no exclusions. The agent must infer usage entirely from the name.

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