tossinvest-mcp

Place a stock order

tossinvest_create_order

Destructive

Place real buy or sell orders for Korean or US stocks by specifying symbol, side, order type, and quantity or dollar amount, with idempotency keys to prevent duplicate orders.

Instructions

Place a REAL buy or sell order for a Korean or US stock. This spends or liquidates actual money — confirm the symbol, side, quantity and price with the user before calling.

Args:

symbol (string): KRX 6 digits or US ticker.
side ('BUY' | 'SELL').
order_type ('LIMIT' | 'MARKET').
quantity (string, optional): number of shares as a decimal string. Whole numbers only, except US market sells, which allow up to 6 decimal places.
order_amount (string, optional): US MARKET orders only — spend this many dollars and let the filled quantity float. Regular US session hours only.
price (string, optional): REQUIRED for LIMIT, forbidden for MARKET. KR: whole won, and it must land on the tick size for the price band. US: up to 4 decimals below $1, 2 decimals at or above $1.
time_in_force ('DAY' | 'CLS'): default DAY. CLS (at-the-close, i.e. LOC when combined with LIMIT) currently works only for US LIMIT orders.
client_order_id (string, optional): idempotency key, max 36 chars of [A-Za-z0-9_-]. Re-sending the same value within 10 minutes returns the original order rather than creating a second one. Strongly recommended.
confirm_high_value_order (boolean): default false. Required true for orders of ₩100,000,000 or more.
account_seq (number, optional): resolved automatically for single-account credentials.
response_format ('markdown' | 'json'): default 'markdown'.

Supply exactly one of quantity or order_amount.

Returns { accountSeq, orderId, operation: 'created' }. The response confirms acceptance, NOT execution — call tossinvest_get_order with the returned orderId to see the fill.

Before ordering it is worth checking tossinvest_get_buying_power (buys), tossinvest_get_sellable_quantity (sells) and tossinvest_get_price_limits (limit prices).

Errors: 422 insufficient-buying-power, 422 order-hours-closed, 422 price-out-of-range, 422 opposite-pending-order-exists, 400 confirm-high-value-required, 400 invalid-request with the correct tick size in 'data'.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`side`	Yes	Order direction.
`price`	No	Limit price. Required for LIMIT, forbidden for MARKET. KR must match the band's tick size; US allows 4 decimals under $1, 2 decimals at or above.
`symbol`	Yes	Stock symbol. KRX: 6 digits (e.g. '005930' for Samsung Electronics). US: ticker (e.g. 'AAPL').
`quantity`	No	Share count as a decimal string. Whole numbers only, except US market sells (up to 6 decimals). Mutually exclusive with order_amount.
`order_type`	Yes	'LIMIT' needs `price`; 'MARKET' must omit it.
`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.
`order_amount`	No	US MARKET orders only: dollar amount to trade, with quantity floating. Regular session hours only. Mutually exclusive with quantity.
`time_in_force`	No	'DAY' expires at the close. 'CLS' is at-the-close, US LIMIT orders only.	DAY
`client_order_id`	No	Idempotency key, max 36 chars. Re-sending the same value within 10 minutes returns the original order instead of creating a second one. Strongly recommended so a retry never double-fills.
`response_format`	No	Output format: 'markdown' for a compact human-readable summary, 'json' for the complete raw payload.	markdown
`confirm_high_value_order`	No	Set true to acknowledge an order of ₩100,000,000 or more; such orders are rejected with `confirm-high-value-required` otherwise. Only set this after the user has confirmed the amount.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`orderId`	Yes	Identifier of the resulting order
`operation`	Yes	created, modified or canceled
`accountSeq`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true, and the description goes well beyond that by stating 'This spends or liquidates actual money' and requiring user confirmation. It also discloses that the response confirms acceptance, not execution, lists concrete error codes, and explains the 10-minute idempotency window and order-type restrictions. No contradiction 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average, but every sentence earns its place: the money-spending warning is front-loaded, parameters are grouped and scannable, and the return semantics, pre-checks, and error codes are clearly separated. There is no filler, tautology, or redundant explanation of the tool's name.

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 destructive order tool with 11 parameters, the description covers all necessary context: required user confirmation, parameter constraints, mutual exclusivity, idempotency, return shape, follow-up tool, and error conditions. The output schema exists and the description still adds the critical caveat that acceptance is not execution. Nothing essential is missing.

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%, and the schema already documents every parameter in detail, including tick sizes, mutual exclusivity, the idempotency window, and session restrictions. The description's Args section largely restates this schema content, adding emphasis but little new semantic information. Baseline 3 is appropriate because the schema carries the semantic load.

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?

Opens with 'Place a REAL buy or sell order for a Korean or US stock' — a specific verb and resource with an explicit warning that actual money is involved. This clearly distinguishes the tool from the get/modify/cancel and conditional-order siblings. The title is fully expanded by the first sentence, leaving no ambiguity about what the tool does.

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

Usage Guidelines4/5

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

Provides explicit pre-call guidance: confirm symbol/side/quantity/price with the user, check buying power for buys, sellable quantity for sells, and price limits before ordering. Also directs the agent to tossinvest_get_order to check the eventual fill. It does not explicitly contrast with tossinvest_create_conditional_order or state when not to use this tool, so it falls just short of a 5.

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

Deploy Server