tossinvest-mcp

Cancel a conditional order

tossinvest_cancel_conditional_order

DestructiveIdempotent

Cancel a standing conditional order so it stops watching the price. The watcher is removed only; any real order already placed stays untouched.

Instructions

Cancel a standing conditional order so it stops watching the price. This cancels a REAL standing order — confirm with the user first.

Args:

conditional_order_id (string): the conditional order to cancel.
account_seq (number, optional): resolved automatically for single-account credentials.
response_format ('markdown' | 'json'): default 'markdown'.

Returns { accountSeq, conditionalOrderId, operation: 'canceled' }.

This only removes the watcher. Any real order already placed by a fired condition is untouched — cancel that separately with tossinvest_cancel_order.

Errors: 404 conditional-order-not-found.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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
`conditional_order_id`	Yes	Identifier of the conditional order to cancel.

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?

The description adds meaningful behavior beyond annotations: it warns that this cancels a REAL standing order, clarifies that only the watcher is removed, and states that already-placed real orders are unaffected. It also documents the return object and the 404 error, giving the agent a full behavioral picture.

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 concise and front-loaded: purpose and warning come first, followed by parameters, return shape, scope clarification, and errors. Every sentence adds value, and the important distinction from tossinvest_cancel_order is placed prominently.

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?

Given the annotations, full schema coverage, and sibling context, the description is complete. It covers purpose, parameters, return shape, error case, destructive warning, and the critical distinction from canceling a real order. An agent has everything needed to invoke it correctly.

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%, so the schema already documents all parameters thoroughly. The description's Args section mostly repeats the schema, adding only a small note that account_seq is resolved automatically for single-account credentials. This meets the baseline but does not substantially exceed it.

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 states a specific verb ('Cancel') and resource ('standing conditional order') and explains the effect ('stops watching the price'). It clearly distinguishes itself from tossinvest_cancel_order by noting that real orders already placed by a fired condition are untouched and must be canceled separately.

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?

It explicitly tells the agent when to use this tool versus the alternative tossinvest_cancel_order: this removes the watcher, while real orders from fired conditions need separate cancellation. It also provides a user-confirmation guideline: 'confirm with the user first.'

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

Deploy Server