kite-connect-mcp

Margin required for orders

get_order_margins

Read-onlyIdempotent

Calculates the margin required for each of up to 50 orders without placing them, using existing positions and open orders; returns totals and charges.

Instructions

Margin Kite would block for each of 1 to 50 orders, without placing anything (works in read-only mode too).

Every order is priced on its own, taking your existing positions and open orders into account; to price orders as one package (hedge or spread benefit) use get_basket_margins. All amounts are INR. Each entry has type (equity or commodity), span, exposure, option_premium, additional, bo, cash, var, pnl, leverage, charges and total, the margin to block. mode=compact returns the totals only. Leave price at 0 for MARKET and SL-M orders. summary adds up the totals and the charges.

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": {
      "orders": "<orders>"
    },
    "name": "get_order_margins"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No	compact: only the totals; omit for the full breakdown
`orders`	Yes	1 to 50 orders

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds that no order is placed, that existing positions and open orders are factored into pricing, that all amounts are INR, and enumerates the returned margin components. It does not mention rate limits or auth, but the behavior surface is well covered.

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-loaded with the core action and scope, then the sibling disambiguation, then output shape. Dense but every sentence carries information; the field enumeration is long but earns its place given no output schema.

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?

With no output schema, the description compensates by listing the breakdown fields and the 'summary' totals, and it explains mode=compact. Error or validation behavior is not covered, which is a minor remaining gap.

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 coverage is 100%, so the schema already documents every order field, the enum values and the 1-50 order bound. The description only reinforces a couple of points (leave price at 0 for MARKET/SL-M, mode=compact returns totals only), so the schema does the heavy lifting.

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 concrete verb and resource ('Margin Kite would block for each of 1 to 50 orders') plus the crucial scope constraint that nothing is placed. It explicitly distinguishes itself from the sibling get_basket_margins by naming it.

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?

Gives explicit routing: use this for per-order pricing, use get_basket_margins when orders should be priced as one package for hedge/spread benefit. It also notes it works in read-only mode, which is a real usage precondition.

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