tossinvest-mcp

Create a conditional order

tossinvest_create_conditional_order

Destructive

Watch a symbol and automatically place a buy or sell when the price hits your trigger. Create single orders, OCO take-profit/stop-loss brackets, or OTO buy-then-sell sequences.

Instructions

Register a REAL price-triggered order: watch a symbol and automatically place a buy or sell when the price reaches a trigger. Confirm every parameter with the user first.

Types:

SINGLE — watch one condition ('first'). Either side. LIMIT or MARKET. No per-symbol limit.
OCO (one-cancels-the-other) — watch two conditions at once; when one fires the other is cancelled. Both must be SELL, LIMIT only, and first.trigger_price > current price > second.trigger_price. This is the take-profit / stop-loss bracket on an existing position.
OTO (one-triggers-the-other) — 'second' only starts being watched after 'first' fills. first must be BUY, second must be SELL, LIMIT only. This is buy-then-auto-exit. OCO and OTO are limited to one per symbol; a second one fails with 422 duplicate-conditional-order.

Args:

symbol (string): the symbol to watch.
type ('SINGLE' | 'OCO' | 'OTO').
quantity (string): share count, shared by every leg in the group.
order_type ('LIMIT' | 'MARKET'): shared by every leg. LIMIT requires order_price on each condition; MARKET forbids it. OCO/OTO accept LIMIT only.
expire_date (string): YYYY-MM-DD. The conditional order auto-expires unfired on this date.
first (object): { order_side, trigger_price, order_price? } — the first watched condition.
second (object, optional): same shape. Omit for SINGLE, required for OCO and OTO.
client_order_id (string, optional): idempotency key.
confirm_high_value_order (boolean): default false. Required true at ₩100,000,000 or more.
account_seq (number, optional): resolved automatically for single-account credentials.
response_format ('markdown' | 'json'): default 'markdown'.

Returns { accountSeq, conditionalOrderId, clientOrderId, operation: 'created' }.

Errors: 422 condition-already-met when the trigger price has already been reached (pick another price), 422 duplicate-conditional-order, 400 invalid-request for a bad leg combination.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`type`	Yes	SINGLE = one condition; OCO = two SELL conditions, one cancels the other; OTO = BUY then auto-SELL.
`first`	Yes	First watched condition. For OTO this is the parent BUY leg.
`second`	No	Second condition. Omit for SINGLE; required for OCO and OTO.
`symbol`	Yes	Stock symbol. KRX: 6 digits (e.g. '005930' for Samsung Electronics). US: ticker (e.g. 'AAPL').
`quantity`	Yes	Share count, shared by every leg of the group.
`order_type`	Yes	Shared by every leg. OCO and OTO accept 'LIMIT' only.
`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.
`expire_date`	Yes	Expiry date (YYYY-MM-DD). The conditional order is dropped if it has not fired by then.
`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
`operation`	Yes	created, modified or canceled
`accountSeq`	Yes
`clientOrderId`	No
`conditionalOrderId`	Yes	Identifier to use from now on — a modify issues a NEW id and invalidates the old one

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already signal destructiveHint=true and readOnlyHint=false, but the description adds substantial context: 'REAL' (real-world financial impact), the requirement to 'Confirm every parameter with the user first,' the one-per-symbol limit for OCO/OTO (with specific 422 duplicate-conditional-order error), the trigger price ordering constraint, the confirm_high_value_order requirement at ₩100M, and the full error taxonomy. This exceeds what annotations provide and directly supports the destructive/openWorld profile.

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?

The description is longer than average but justified by the tool's complexity (11 params, 3 types, nested objects). It is well-structured with clear section headers (Types, Args, Returns, Errors) and front-loads the core purpose. The Args list is somewhat redundant with the schema since coverage is 100%, but it adds the constraint summaries that the schema lacks. A tighter format could merge redundant bits, but the structure earns its length.

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 conditional-order tool with 11 parameters, 3 enums, nested objects, and three behaviorally distinct types, the description covers everything an agent needs: the three types with their invariants, return shape ({accountSeq, conditionalOrderId, clientOrderId, operation: 'created'}), error conditions with codes, and safety requirements. The output schema exists and return format is described. Nothing essential is missing for correct invocation.

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?

With 100% schema coverage, baseline is 3, but the description adds cross-parameter constraints absent from the schema: the trigger price inequality 'first.trigger_price > current price > second.trigger_price' for OCO, leg-side restrictions (OCO both SELL, OTO first BUY then SELL), LIMIT/MARKET exclusivity rules, the idempotency behavior of client_order_id (10-minute window, returns original instead of duplicate), and the per-symbol limit. These relationships are critical for correct invocation and are not derivable from the individual property descriptions.

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 verb+resource statement: 'Register a REAL price-triggered order: watch a symbol and automatically place a buy or sell when the price reaches a trigger.' It clearly distinguishes this from the sibling tossinvest_create_order (immediate orders) by emphasizing the conditional trigger mechanism. The three order types are each defined with their specific behavior.

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?

The description gives detailed context on when each type is appropriate (OCO = take-profit/stop-loss bracket on existing position, OTO = buy-then-auto-exit) and warns the user to confirm every parameter first. It does not explicitly name alternatives (e.g., 'use tossinvest_create_order for immediate fills') but the behavioral guidance for when this tool is appropriate is clear and strong.

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

Deploy Server