kite-connect-mcp

Modify a GTT (dry run by default)

modify_gtt_order

Destructive

Update an active GTT by sending its complete new trigger definition; validation runs as a dry run by default before sending live.

Instructions

Modify an ACTIVE GTT. Kite replaces the whole trigger, so send its complete new definition: call get_gtt first and change only what you mean to change. The fields are those of place_gtt_order, with the same rules. DRY RUN BY DEFAULT, confirmed like place_gtt_order.

Safety: the new orders are checked against the per-order cap and the allow-lists. A modification takes no new slot of the daily order count; only the increase over the stored trigger's value counts toward the day's value cap. Returns the trigger_id when sent.

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": {
      "trigger_id": "<trigger_id>",
      "type": "<type>",
      "exchange": "<exchange>",
      "tradingsymbol": "<tradingsymbol>",
      "trigger_values": "<trigger_values>",
      "last_price": "<last_price>",
      "orders": "<orders>"
    },
    "name": "modify_gtt_order"
  }
}

Input Schema

Name	Required	Description
`type`	Yes	single: one trigger, one order. two-leg: OCO, two triggers, two orders
`orders`	Yes	the order(s) to place: one for single, two for two-leg
`dry_run`	No	true (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
`exchange`	Yes	exchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX
`last_price`	Yes	the instrument's CURRENT price in INR (get_ltp / get_quotes / get_holdings). Kite uses it to decide which way each trigger fires, so it must be fresh
`trigger_id`	Yes	the GTT's trigger_id (see get_gtts)
`tradingsymbol`	Yes	tradingsymbol, e.g. INFY
`trigger_values`	Yes	trigger prices in INR, on the tick size: ONE value for single; TWO for two-leg, the lower first (trigger_values[i] fires orders[i])
`confirmation_token`	No	the confirmation_token returned by a dry run of this exact call (single use)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the critical replacement-not-patch behavior (Kite overwrites the whole trigger), the dry-run-by-default safety flow, that the new orders are checked against per-order caps and allow-lists, the daily order-count and value-cap accounting, and that trigger_id is returned. That is exactly the mutation and rate/limit context annotations alone cannot convey.

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?

Front-loads the action and the most consequential fact (whole-trigger replacement), then the dry-run default, then safety accounting, then the return value. No sentence is padding; each carries a distinct operational fact.

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 9-parameter destructive mutation with no output schema, the description covers prerequisites (get_gtt first), the confirmation flow, safety/limit interactions, and the return value. Nothing an agent needs before invoking it appears to be missing.

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 real meaning: it tells the agent the fields mirror place_gtt_order's rules and that the full definition must be supplied because the trigger is replaced wholesale, which changes how the orders and trigger_values parameters must be populated. Per-field details remain delegated to the schema.

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?

States a specific verb and resource ('Modify an ACTIVE GTT') plus the state constraint that only active GTTs can be modified. It also distinguishes itself from place_gtt_order and get_gtt by describing replacement semantics and the read-before-write workflow, so an agent can tell this apart from the sibling GTT tools.

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?

Gives clear operating context: dry run is the default, a live send needs the confirmation_token from a dry run of the exact call, and get_gtt should be called first to obtain the complete current definition. It does not explicitly route the agent between delete_gtt_order, place_gtt_order and this tool, so an explicit when-to-use-which sentence is the only gap.

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