kite-connect-mcp

Place a GTT (dry run by default)

place_gtt_order

Destructive

Places single or two-leg GTT (good-till-triggered) orders on Kite, previewing trigger prices, order details, and margin with a dry run before live submission.

Instructions

Place a GTT (good till triggered): Kite watches the price and places a LIMIT order when a trigger value is reached. DRY RUN BY DEFAULT: with dry_run=true (the default) nothing is sent; the answer shows the exact request, the value of each order, Kite's margin calculation, every safety check and, when live trading is enabled and the checks pass, a confirmation_token. To create it, repeat the identical call with dry_run=false and that token.

type=single: one trigger value (not equal to last_price) and one order. type=two-leg is an OCO (one cancels other): two trigger values, lower first, with last_price between them, and two orders; orders[i] is placed when trigger_values[i] is reached and the other is dropped (typically a stop-loss below and a target above). last_price is the current price in INR from get_ltp, get_quotes or get_holdings: never guess it. Only LIMIT orders are supported; prices must sit on the tick size.

Safety: a GTT uses one slot of the daily order count. Every order is checked against the per-order cap and the allow-lists; for an OCO only one order can execute, so the day's value grows by the larger order, not the sum. MCX, CDS and BCD GTTs cannot be valued and so cannot be sent live. 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": {
      "type": "<type>",
      "exchange": "<exchange>",
      "tradingsymbol": "<tradingsymbol>",
      "trigger_values": "<trigger_values>",
      "last_price": "<last_price>",
      "orders": "<orders>"
    },
    "name": "place_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
`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.6/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=true) by disclosing that a GTT consumes one slot of the daily order count, that every order is checked against the per-order cap and allow-lists, that OCO exposure counts only the larger leg, that MCX/CDS/BCD GTTs cannot be sent live, and that the token is single use. It also states the return value (trigger_id) and what a dry run previews.

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?

Front-loads the dry-run default, which is the single most important thing to know, then covers order types and safety in three tight paragraphs. Dense and mostly waste-free, though the safety paragraph packs several unrelated facts into one block and repeats some schema-declared constraints (LIMIT-only, tick size).

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 an 8-parameter, destructive, live-trading mutation with no output schema, the description covers the two-phase dry-run/live contract, per-type validation rules, risk-cap accounting, exchange restrictions, and the return value. Nothing material an agent needs before invoking it is 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 already 100%, so baseline is 3; the description earns extra by adding relational meaning the schema does not encode — 'trigger_values[i] fires orders[i]', lower trigger first with last_price between the two for OCO, and the constraint that last_price must be fresh and never guessed. It stops short of explaining only minor details such as tick-size validation behaviour.

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 ('Place a GTT (good till triggered)') and immediately defines the mechanism ('Kite watches the price and places a LIMIT order when a trigger value is reached'), which distinguishes it from the sibling place_order and modify_gtt_order. An agent can identify the tool's job without opening the schema.

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?

Explicit workflow guidance: dry_run=true by default, then repeat the identical call with dry_run=false plus the confirmation_token. It also explains when to pick type=single versus type=two-leg and where last_price must come from (get_ltp / get_quotes / get_holdings). The only gap is that it never names sibling alternatives such as place_order for non-triggered orders or modify_gtt_order for edits.

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