Skip to main content
Glama
kite-connect-mcp

kite-connect-mcp

Modify an open order (dry run by default)

modify_order
Destructive

Update an open or pending order's quantity, price, order type, trigger price, validity, or disclosed quantity with dry-run validation and cap checks before sending live.

Instructions

Modify an open or pending order: quantity, price, order_type, trigger_price, validity, disclosed_quantity (cover orders: price / trigger_price only). DRY RUN BY DEFAULT, confirmed like place_order. The new value is checked against the per-order cap and any increase against the daily cap. Kite allows 25 modifications per order.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "order_id": "<order_id>"
    },
    "name": "modify_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
priceNo
dry_runNotrue (default): validate and preview only, nothing is sent. false: send it live, which needs live trading enabled on the server and the confirmation_token from a dry run
varietyNothe order's variety (it is part of the URL)regular
order_idYes
quantityNo
validityNo
order_typeNo
trigger_priceNo
parent_order_idNoco second leg: the parent
market_protectionNoMARKET / SL-M: -1 or (0, 100]
confirmation_tokenNothe confirmation_token returned by a dry run of this exact call (single use)
disclosed_quantityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

This is very strong. It explicitly states that the tool is 'DRY RUN BY DEFAULT,' which mitigates the inherent danger of the 'destructiveHint'. Furthermore, it details operational limits, mentioning checks against per-order and daily caps, and specifies the modification limit (25 modifications).

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 definition is dense, but highly efficient. It front-loads the critical default behavior and behavioral constraints (dry run, caps) without unnecessary filler. The structure is a concise list of functional capabilities and limitations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters) and destructive nature, the description is highly complete regarding its operational envelope. By detailing the dry run default and the modification caps, it provides the agent with essential safety and constraint knowledge beyond the structured fields.

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?

Due to the low schema description coverage (42%), the description adds essential context by listing the modifiable parameters (quantity, price, validity, etc.) and defining the specific handling for 'cover orders' (price/trigger_price only). This semantic detail compensates significantly for the structural gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the primary purpose: to modify an open or pending order. It identifies the resource and the main parameters changed (quantity, price, validity). It successfully distinguishes the function from simple order placement by focusing on modification.

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

Usage Guidelines3/5

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

It implies usage for open or pending orders, and contrasts its confirmation style with `place_order`. However, it does not explicitly list prerequisites for certain parameters or define clear exclusions for when to use this tool versus a general search/modify tool.

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