tossinvest-mcp

Modify a conditional order

tossinvest_modify_conditional_order

Destructive

Revise an existing conditional order by updating its type, quantity, expiry, and trigger conditions. The order is cancelled and recreated, so use the returned new conditional order ID afterwards.

Instructions

Replace an existing conditional order's settings. This changes a REAL standing order — confirm with the user first.

IMPORTANT: modification works by cancelling and recreating, so a NEW conditionalOrderId is issued and the old one stops working. Use the id from this response for every later read, modify or cancel.

The whole conditional order is re-specified, so pass every leg you want to keep — anything omitted is dropped. The symbol cannot change (it is fixed by the id), and switching type (e.g. SINGLE to OCO) is allowed.

Args:

conditional_order_id (string): the conditional order to replace.
type ('SINGLE' | 'OCO' | 'OTO'): the resulting type.
quantity (string): share count, shared by every leg.
order_type ('LIMIT' | 'MARKET'): shared by every leg. OCO/OTO accept LIMIT only.
expire_date (string): YYYY-MM-DD. Required here even though it is optional in some clients.
first (object): { order_side, trigger_price, order_price? }.
second (object, optional): omit for SINGLE, required for OCO and OTO.
confirm_high_value_order (boolean): default false.
account_seq (number, optional): resolved automatically for single-account credentials.
response_format ('markdown' | 'json'): default 'markdown'.

Returns { accountSeq, conditionalOrderId, operation: 'modified' } — with the NEW id.

Errors: 404 conditional-order-not-found, 422 condition-already-met.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`type`	Yes	Resulting type. Switching type is allowed.
`first`	Yes	First watched condition.
`second`	No	Second condition. Omit for SINGLE; required for OCO and OTO.
`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). Required when modifying.
`response_format`	No	Output format: 'markdown' for a compact human-readable summary, 'json' for the complete raw payload.	markdown
`conditional_order_id`	Yes	Identifier of the conditional order to replace.
`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.6/5.0

Behavior5/5

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

The description goes well beyond the annotations: it warns the order is real, requires user confirmation, explains that modification works by cancel-and-recreate, that a new conditionalOrderId is issued, and that the old one stops working. It also discloses that omitted legs are dropped. This matches and enriches destructiveHint=true and idempotentHint=false.

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 typical but front-loads the critical warning and the cancel-and-recreate behavior before the parameter list. The Args and error sections are dense and actionable, though the parameter list partly repeats schema information. For a destructive, high-value tool, the length is justified.

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 10-parameter mutation with nested objects and an output schema, the description covers the new ID in the return, required vs optional legs, type switching rules, expiry requirement, error cases, and the high-value confirmation flag. Nothing an agent needs to safely call this tool is left to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds actionable cross-parameter guidance: omitted legs are dropped, expire_date is required here even if optional in clients, account_seq resolves automatically for single-account credentials, and OCO/OTO accept LIMIT only. These details materially improve correct invocation beyond the schema alone.

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 'Replace an existing conditional order's settings,' naming a specific verb and resource, and the body clearly distinguishes this from create/cancel operations by explaining that modification re-specifies an existing order and issues a new ID. This is unambiguous in the context of siblings like tossinvest_create_conditional_order and tossinvest_cancel_conditional_order.

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 clearly tells the agent when to use the tool: on an existing conditional order, after user confirmation, with all desired legs re-specified. It also explains the high-stakes consequences of use, such as cancel-and-recreate behavior and the old ID stopping working. It does not explicitly list sibling alternatives or when-not-to-use, but the context is strong enough to avoid confusion.

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

Deploy Server