tossinvest-mcp

Get available buying power

tossinvest_get_buying_power

Read-onlyIdempotent

Check available cash buying power in KRW or USD before placing an order to prevent 422 insufficient-buying-power errors. Returns cash-settled funds only, excluding margin.

Instructions

Get how much cash is available to buy with, in KRW or USD.

Check this before placing a buy order — an order beyond it fails with 422 insufficient-buying-power.

Args:

currency ('KRW' | 'USD'): KRW for Korean stocks, USD for US stocks.
account_seq (number, optional): resolved automatically for single-account credentials.
response_format ('markdown' | 'json'): default 'markdown'.

Returns { accountSeq, currency, cashBuyingPower }. cashBuyingPower is cash-settled buying power only — margin (미수) is excluded, so this is the amount that can be spent without incurring a margin position.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`currency`	Yes	'KRW' for Korean stocks, 'USD' for US stocks.
`account_seq`	No	accountSeq of the account to act on (the `X-Tossinvest-Account` header). Optional: falls back to TOSSINVEST_ACCOUNT_SEQ, then to the sole account on the credentials. Get valid values from tossinvest_list_accounts.
`response_format`	No	Output format: 'markdown' for a compact human-readable summary, 'json' for the complete raw payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description
`currency`	No	KRW or USD
`accountSeq`	Yes
`cashBuyingPower`	No	Cash-only buying power, excluding margin

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations (readOnlyHint, idempotentHint, etc.) are consistent with the description. The description adds transparency about the return value (cash-only, excluding margin) and the account_seq fallback, with no contradictions.

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?

Concise and well-structured: brief opening line, bullet-pointed args, and a clear return statement. Every sentence adds essential information without redundancy.

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?

The description fully specifies what the tool returns (accountSeq, currency, cashBuyingPower) and the meaning of cashBuyingPower (cash-settled, excluding margin). It is self-sufficient for an agent to invoke correctly, despite the output schema not being shown.

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 covers 100% of parameters with detailed descriptions, including enum values and fallback logic for account_seq. The description reinforces each parameter's purpose, providing complete semantic clarity.

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?

Clearly states the tool's function: retrieving available cash buying power in KRW or USD. Unambiguously distinguishes it from sibling tools focused on orders, prices, and other account data.

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 instructs to check this before placing a buy order and explains the failure mode (422 insufficient-buying-power). Also provides guidance on account_seq fallback, covering when and how to use the tool.

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

Deploy Server