kite-connect-mcp

Delete a GTT (dry run by default)

delete_gtt_order

Destructive

Delete an active GTT so it can no longer fire; default dry run previews the stored GTT and requires confirmation to send.

Instructions

Delete an ACTIVE GTT so it can no longer fire. DRY RUN BY DEFAULT, confirmed like place_gtt_order (deleting a stop-loss GTT can increase risk, so it is not exempt). Caps do not apply to deletions; the allow-lists do, judged on the orders the GTT would have placed. The dry run shows the stored GTT. 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>"
    },
    "name": "delete_gtt_order"
  }
}

Input Schema

Name	Required	Description
`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
`trigger_id`	Yes	the GTT's trigger_id (see get_gtts)
`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.3/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing the dry-run default, the single-use confirmation token requirement for live sends, that allow-lists are evaluated against the orders the GTT would have placed, and the risk rationale for a stop-loss GTT. This is exactly the extra context annotations 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the dry-run default and the risk warning, which is the right ordering. The parenthetical about stop-loss risk is slightly run-on but earns its place; nothing is filler.

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?

Covers the safety-critical pieces an agent needs: default dry run, confirmation flow, allow-list enforcement, and that the dry run previews the stored GTT and a live send returns the trigger_id. With no output schema, the return description is minimal but adequate.

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 trigger_id, dry_run, and confirmation_token are already fully documented in the schema, including the single-use token and live-trading precondition. The description adds little parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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 ('Delete an ACTIVE GTT') plus the intent ('so it can no longer fire'), and the ACTIVE qualifier narrows scope. An agent can distinguish this from modify_gtt_order, get_gtts, and delete_alerts 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?

Explains that the call is dry-run by default, that live deletion requires the same confirmation flow as place_gtt_order, and that caps don't apply while allow-lists do. It does not explicitly say when to prefer modify_gtt_order over deletion, but the operational context is clear.

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