kite-connect-mcp

Convert a position's product (dry run by default)

convert_position

Destructive

Convert the margin product of an open position, such as MIS to NRML, with a dry-run preview by default before sending a live request.

Instructions

Convert the margin product of an open position, for example MIS to NRML or NRML to MIS. DRY RUN BY DEFAULT: with dry_run=true (the default) nothing is sent; the answer shows the exact request, the position found in get_positions, every safety check and, when live trading is enabled and the checks pass, a confirmation_token. To convert, repeat the identical call with dry_run=false and that token.

A conversion places no order and adds no exposure, so it does not count toward the daily order count or the daily value. It is still checked: the new product must be allowed, and the converted quantity's notional (quantity x multiplier x last_price from get_positions) must be within the per-order cap. If the position is not found, its value is unknown and the conversion cannot be sent live. Moving a position out of MIS keeps it open past the end of the day and needs the full margin of the new product. Returns true 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": {
      "exchange": "<exchange>",
      "tradingsymbol": "<tradingsymbol>",
      "transaction_type": "<transaction_type>",
      "position_type": "<position_type>",
      "quantity": "<quantity>",
      "old_product": "<old_product>",
      "new_product": "<new_product>"
    },
    "name": "convert_position"
  }
}

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
`exchange`	Yes	exchange of the position: NSE, BSE, NFO, BFO, CDS, BCD, MCX
`quantity`	Yes	quantity to convert (MCX/CDS/BCD: lots)
`new_product`	Yes	the margin product to convert to
`old_product`	Yes	the position's current margin product
`position_type`	Yes	overnight: carried over from a previous day. day: opened today
`tradingsymbol`	Yes	e.g. INFY, NIFTY25NOVFUT
`transaction_type`	Yes	the position's side: BUY for a long position, SELL for a short one
`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

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false, openWorldHint=true), it explains that no order is placed, no exposure is added, the daily order count and daily value are unaffected, and which checks run (allowed product, notional against the per-order cap). It also flags the real risk that moving out of MIS keeps the position open overnight and requires full margin of the new product. It is slightly less explicit about the failure/uniqueness semantics of confirmation_token beyond 'single use', which the schema covers.

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 critical dry-run-by-default warning is front-loaded and clearly delimited. Several sentences are dense and earn their place, but the daily-count/daily-value explanation and the restatement of what the dry run returns could be tightened slightly.

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 mutation with no output schema, the description covers the full lifecycle: preview mode, gating checks, token handoff, live-send requirements, and the 'returns true when sent' result. An agent has everything needed to call it correctly on the first attempt.

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 most parameter meaning is already supplied. The description still adds value by tying dry_run and confirmation_token together as a repeat-the-identical-call contract and by noting that the preview echoes the exact request and the position from get_positions. Nothing about exchange, quantity units, or product enums is added beyond the schema, which caps it below 5.

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 names a specific verb and resource ('Convert the margin product of an open position') and gives concrete examples (MIS to NRML, NRML to MIS). An agent can distinguish it immediately from place_order, modify_order, or get_positions because no order is placed.

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 states the exact two-step workflow: call with dry_run=true (the default) to preview, then repeat the identical call with dry_run=false plus the returned confirmation_token. It also names the prerequisite (live trading enabled on the server) and where position data comes from (get_positions).

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