Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Kite Connect MCP

PYPI · KITE-CONNECT-MCP

Zerodha Kite Connect v3 for AI agents: orders (dry-run by default), GTT, alerts, portfolio, quotes

Available components

65 Trust /100

Last scanned (11 hours ago)

Scores higher than 62% of PyPI servers

Category Finance and Payments

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security50
  • Malware scan not yet available for this package.Unverified
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
  • 1 of 29 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Cryptographically verified build provenance (signed, bound to techfreakworm/kite-connect-mcp). View diagnostics → Pass
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 1 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability62
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 10916 tokens (~205/item across 53 items; 53 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management7
  • Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage96
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 89% of tool parameters carry a description.Partial
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 54 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
What we tested

Checks we ran (15)

  • Known CVEs
  • Install scripts
  • Dependency health
  • Source repository
  • Provenance
  • License
  • Maintenance
  • Security disclosure
  • Schema quality
  • Stability
  • Tool coverage
  • Injection markers
  • Destructive annotations
  • Judged manipulation
  • MCP protocol

Checks we could not complete (1)

These are gaps on our side, not findings about this package. We only credit what we can confirm, so a category made up entirely of them scores 0.

  • Malware scan in Supply Chain SecurityMalware scan not yet available for this package.

Does not apply to this package (2)

  • Endpoint SecurityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.
  • Transport & ReachabilityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.

The score does not measure everything. What the score does not measure →

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 5 Nov 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

  • 4 Nov 26 0
    • Stability: unverified → 0.03 ▲ functional
    • Package version: 0.1.0 → 0.1.1 functional
  • 3 Nov 26 64

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Analysed pypi/kite-connect-mcp@0.1.1

Provenance Verified

A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.

Result Verified
Ecosystem pypi
Reason Verified
Discovered via Registry attestation endpoint
Source repo techfreakworm/kite-connect-mcp
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/techfreakworm/kite-connect-mcp/.github/workflows/release.yml@refs/heads/main
Rekor log index 3685174336
Predicate type PyPI publish attestation https://docs.pypi.org/attestations/publish/v1
Subject digest sha256:b076b5be269f87cd2e7f87f98766077fe15c2f36cba90827c696d3bc666c1f3d

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend Known build tool hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 29 packages
Packages resolved 29
No linked repository 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 53 exposed · ~10,725 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
authorise_holdings ~315

Start a CDSL authorisation so that shares can be sold from the demat account. Call this when a SELL fails with HTTP 428 ('N quantity needs authorisation at depository'). DRY RUN BY DEFAULT: with dry_run=true (the default) nothing is sent; the answer shows the request and the checks. Repeat the identical call with dry_run=false and the confirmation_token to send it: Kite answers with a request_id, and this tool's live answer then contains `authorise_url`, the link YOU open in a browser to key in your demat PIN (TPIN) at CDSL. The PIN never passes through this server. Nothing is authorised until you finish that page. With `holdings` (isin and quantity pairs) only those shares are authorised; without it the page offers the entire holdings. An authorisation is valid for one trading session (until 5:30 PM IST, then it counts for the next trading day) and is used up as you sell. This is not an order: no caps apply.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
holdings––the holdings (isin, quantity) to authorise; omit to authorise the entire holdings

No output schema declared.

No examples provided.

cancel_order ~153

Cancel an open or pending order. DRY RUN BY DEFAULT, confirmed like place_order (cancelling a stop-loss can increase risk, so it is not exempt). Caps do not apply to cancellations.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
order_idstringyes–
parent_order_id––co second leg: the parent
varietystring–the order's variety (it is part of the URL)

No output schema declared.

No examples provided.

complete_login ~149

Finish a Kite login with a request_token the person copied from the browser's address bar after logging in (use it when the redirect page could not be reached). Exchanges the token with Kite and stores the access token for every client of this server. Request tokens are single use and last only a few minutes. If KITE_MCP_ALLOWED_USER_ID is set, a login by any other Kite account is ended and refused.

NameTypeReqDescription
request_tokenstringyesthe request_token from the address bar after logging in at Kite; the whole redirected URL (which also carries the state) is accepted too
state––the state from the same URL (optional; if given it must be valid)

No output schema declared.

No examples provided.

convert_position ~420

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.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
exchangestringyesexchange of the position: NSE, BSE, NFO, BFO, CDS, BCD, MCX
new_productstringyesthe margin product to convert to
old_productstringyesthe position's current margin product
position_typestringyesovernight: carried over from a previous day. day: opened today
quantityintegeryesquantity to convert (MCX/CDS/BCD: lots)
tradingsymbolstringyese.g. INFY, NIFTY25NOVFUT
transaction_typestringyesthe position's side: BUY for a long position, SELL for a short one

No output schema declared.

No examples provided.

create_alert ~654

Create a price alert. DRY RUN BY DEFAULT: with dry_run=true (the default) nothing is sent; the answer shows the exact request, 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. Kite allows at most 500 active alerts per user. The alert watches lhs_attribute (LastTradedPrice) of lhs_exchange:lhs_tradingsymbol and triggers when "value operator right-hand side" becomes true (operators: <=, >=, <, >, ==). The right-hand side is a constant (rhs_type=constant with rhs_constant, in INR for prices) or another instrument's attribute (rhs_type=instrument with rhs_exchange and rhs_tradingsymbol). Indices live on the exchange INDICES (INDICES:NIFTY 50). type=simple only notifies. type=ato (alert triggers order) also places the basket `orders` by itself when the condition becomes true, with no confirmation at that moment: the confirmation you give now covers them. Each basket order is checked like place_order (per-order cap, allow-lists, tick and lot size) and counts toward the daily order count and value caps; MARKET orders are valued at the live price plus a buffer (paid market data needed), MCX/CDS/BCD orders cannot be valued and so cannot be sent live. A simple alert has no orders and no caps. Returns the created alert (with its uuid) when sent.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
lhs_attributestring–what to monitor; LastTradedPrice is the only attribute Kite documents
lhs_exchangestringyesexchange of the monitored instrument: NSE, BSE, NFO, CDS, BCD, MCX, or INDICES for indices
lhs_tradingsymbolstringyestradingsymbol of the monitored instrument: INFY, 'NIFTY 50'
namestringyesa label for the alert
operatorstringyescomparison of the monitored value with the right-hand side
orders––the basket of orders: required for type=ato (up to 20), not allowed for simple
rhs_attribute––only for rhs_type=instrument; defaults to LastTradedPrice
rhs_constant––the number to compare with (INR for prices); only for rhs_type=constant
rhs_exchange––only for rhs_type=instrument
rhs_tradingsymbol––only for rhs_type=instrument
rhs_typestringyesconstant: compare with rhs_constant. instrument: compare with another instrument (rhs_*)
typestringyessimple: only notify. ato: also place the basket `orders` by itself when the condition is true

No output schema declared.

No examples provided.

delete_alerts ~176

Delete one or more alerts in a single call (a deleted alert shows status 'deleted'). Deleting an ato alert also removes the orders it would have placed. DRY RUN BY DEFAULT, confirmed like create_alert. No caps or allow-lists apply to a deletion. The dry run lists the alerts that will be deleted. Kite answers with no data when it is sent.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
uuidsarrayyesuuids of the alerts to delete (see get_alerts), up to 50

No output schema declared.

No examples provided.

delete_gtt_order ~179

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.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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_idintegeryesthe GTT's trigger_id (see get_gtts)

No output schema declared.

No examples provided.

engage_kill_switch ~68

Stop every write at once: creates the kill-switch file, after which all write tools are refused (dry runs still work and say so). Only a person can switch it off again, by deleting the file on the server.

NameTypeReqDescription
reasonstringyeswhy writes are being stopped

No output schema declared.

No examples provided.

get_alert ~50

One alert by its uuid: type, name, status, condition, alert_count and, for an ato alert, its basket.

NameTypeReqDescription
uuidstringyesthe alert's uuid (see get_alerts)

No output schema declared.

No examples provided.

get_alert_history ~97

Every time the alert triggered, newest first: the condition as evaluated, created_at (IST), the market data of the instrument at that moment (last_price, ohlc, volume, oi, ...) and, for an ato alert, the orders it placed (order_meta).

NameTypeReqDescription
limitinteger––
offsetinteger––
uuidstringyesthe alert's uuid (see get_alerts)

No output schema declared.

No examples provided.

get_alerts ~154

Your alerts, newest first. Kite allows at most 500 active alerts per user. Each has uuid, type (simple or ato), name, status (enabled = being evaluated, disabled, deleted = soft-deleted), disabled_reason, the condition (lhs_exchange, lhs_tradingsymbol, lhs_attribute, operator, rhs_type, rhs_constant or the rhs_* instrument), alert_count (how many times it triggered), created_at / updated_at (IST) and, for an ato alert, the basket of orders it places.

NameTypeReqDescription
limitinteger––
offsetinteger––
status––only alerts in this state (enabled, disabled, deleted); omit for the default list

No output schema declared.

No examples provided.

get_auctions ~74

The auctions being held right now for stocks you hold in your demat account (only those). Each entry is the holding (tradingsymbol, exchange, isin, quantity, average_price, last_price, pnl, ...) plus its auction_number: pass that to place_order with variety=auction to take part.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

get_audit_log ~99

The audit log: every dry run, refusal, confirmation, live send and its result, oldest first (newest `limit`). Each event has a call_id tying a live_intent to its live_result / live_error / live_unknown.

NameTypeReqDescription
date––IST date YYYY-MM-DD; omit for today
limitinteger–newest N events
tool––only events of this tool, e.g. place_order

No output schema declared.

No examples provided.

get_basket_margins ~202

Margin for 1 to 50 orders taken together as one basket, without placing anything (also in read-only mode). `initial` is the total margin required to execute the orders, `final` the total margin with the spread (hedge) benefit, `orders` the per-order margins, and `charges` Kite's overall charges block, which can leave out the transaction tax when MCX and equity orders are mixed: use the per-order charges instead. All amounts are INR. mode=compact returns the totals only. `summary` gives the initial and final margin, the spread benefit (initial minus final) and the summed per-order charges.

NameTypeReqDescription
consider_positionsboolean–true (default): net the basket against your open positions; false: price it alone
mode––compact: only the totals; omit for the full breakdown
ordersarrayyes1 to 50 orders

No output schema declared.

No examples provided.

get_gtt ~64

One GTT by its trigger_id, whatever its age or status: type, status, condition, the orders it places and the result of the order if the trigger fired.

NameTypeReqDescription
trigger_idintegeryesthe GTT's trigger_id (see get_gtts)

No output schema declared.

No examples provided.

get_gtts ~145

The GTT book, newest first: every active GTT and those in other states from the previous 7 days. Each has id (the trigger_id), type (single or two-leg), status, created_at / updated_at / expires_at (IST), condition (exchange, tradingsymbol, trigger_values, last_price at placement), orders (with `result` once an order was placed by the trigger, including the rejection reason if the order failed) and meta.

NameTypeReqDescription
limitinteger––
offsetinteger––
status––only GTTs in this state; omit for all (active, triggered, disabled, expired, ...)

No output schema declared.

No examples provided.

get_historical_data ~543

OHLCV candles for one instrument between two IST times, oldest first, in INR. Returns {instrument, instrument_token, interval, from, to, columns, candles, count}; each candle is a list in `columns` order (date, open, high, low, close, volume, and oi when requested), `date` being the candle's start as Kite sends it (e.g. 2026-11-03T09:15:00+0530; day candles are at 00:00). Kite limits the date range of one request by interval (minute 60 days, 3/5/10minute 100, 15/30minute 200, 60minute 400, day 2000). Longer ranges are split into several requests automatically, newest first, and the tool stops as soon as it holds `limit` candles (at most 2000, always the newest). When older candles may exist in the range, `truncated` is true and `note` explains: to read further back, call again with to_date just before the first candle returned. continuous=true gives a future's day candles across its expired contracts (interval must be day). oi=true adds open interest (zero or null for plain equities). Needs the paid Kite Connect plan; historical requests are limited to 3 per second. Output is large (a candle is about 25 tokens, so 2000 candles are about 50k): ask for the range you need, or set `limit`.

NameTypeReqDescription
continuousboolean–futures only, interval day: stitch the expired contracts of a future together
from_datestringyesstart (IST): "YYYY-MM-DD" (from 00:00:00) or "YYYY-MM-DD HH:MM:SS"
instrument–yesEXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") or a numeric instrument_token (e.g. 408065)
intervalstringyescandle size: minute, 3minute ... 60minute, or day
limit––keep only the newest N candles (default and maximum 2000)
oiboolean–add the open interest column (futures and options)
to_datestringyesend (IST, inclusive): "YYYY-MM-DD" (up to 23:59:59 of that day) or "YYYY-MM-DD HH:MM:SS"; a time in the future means now

No output schema declared.

No examples provided.

get_holdings ~207

Long-term equity holdings in the demat account, by tradingsymbol, with a `summary` over ALL the holdings that match (not just the page), in INR: invested (average_price x shares), current_value (last_price x shares), pnl (the sum of Kite's pnl) and its percentage, day_change (against the previous close) and its percentage. The shares of a holding are quantity (settled, T+2) plus t1_quantity (bought, not yet delivered). Each holding has tradingsymbol, exchange, isin, product, quantity, t1_quantity, used_quantity, authorised_quantity (for sale at the depository), collateral_quantity, average_price, last_price, close_price, pnl, day_change (per share) and day_change_percentage.

NameTypeReqDescription
limitinteger––
offsetinteger––
tradingsymbol––only holdings of this tradingsymbol, e.g. INFY

No output schema declared.

No examples provided.

get_instrument ~142

One instrument from Kite's daily instrument list: key, instrument_token, exchange_token, tradingsymbol, name, exchange, segment, instrument_type (EQ, FUT, CE, PE), expiry, strike, lot_size, tick_size (INR) and last_price (from the daily dump, not live). Use it to check the lot size and tick size before an order.

NameTypeReqDescription
instrument–yesEXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") or a numeric instrument_token (e.g. 408065)

No output schema declared.

No examples provided.

get_instruments_status ~89

What the local instrument cache holds: for the instrument list and the mutual fund list, whether it is loaded, row counts (per exchange for the instrument list), when it was loaded, whether it is stale (Kite publishes a new dump every day around 08:30 IST), when it will next be refreshed and the last refresh error, if any. Never contacts Kite.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

get_ltp ~123

Last traded price (INR) for up to 1000 instruments in one call. Returns {"quotes": {instrument: {instrument_token, last_price}}, "missing": [...]} (`missing`: instruments Kite has no data for). The cheapest price check. Needs the paid Kite Connect plan.

NameTypeReqDescription
instrumentsarrayyes1 to 1000 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT")

No output schema declared.

No examples provided.

get_margins ~88

Funds and margins: `available` (cash, opening balance, live balance, collateral, intraday payin) and `utilised` (debits, exposure, span, option premium, holding sales, turnover, ...) per segment, plus `net` (what is left to trade with). Amounts in INR.

NameTypeReqDescription
segment––equity or commodity; omit for both

No output schema declared.

No examples provided.

get_mf_holdings ~126

Mutual fund units in your demat account, largest first. Each holding has tradingsymbol (the fund's ISIN), fund (name), folio, quantity (units), average_price (INR per unit paid), last_price (the last available NAV, INR per unit), last_price_date, pnl and pledged_quantity. `summary` covers ALL holdings, not just the page: invested and current value in INR, the profit or loss and its percentage.

NameTypeReqDescription
limitinteger–items per page
offsetinteger–items to skip

No output schema declared.

No examples provided.

get_mf_orders ~207

Mutual fund orders. With order_id: that one order, however old. Without: every order of the last 7 days (open and executed, lump sums and SIP instalments), newest first, optionally filtered by status, with `status_counts` over the whole window. Each order has order_id, status, status_message, tradingsymbol (ISIN), fund, transaction_type, amount (INR), quantity (units allotted or sold), average_price (the NAV used), last_price (latest NAV), variety (regular, sip, amc_sip), folio and tag.

NameTypeReqDescription
limitinteger–items per page
offsetinteger–items to skip
order_id––one order, whatever its age (the list only goes back 7 days)
status––list only: keep orders in this status, case-insensitive (COMPLETE, REJECTED, CANCELLED, OPEN...; status_counts shows which exist)

No output schema declared.

No examples provided.

get_mf_sips ~159

Mutual fund SIPs (recurring purchases): with sip_id one SIP, else all active and paused ones with `status_counts`. Each has sip_id, tradingsymbol (ISIN), fund, status (ACTIVE, PAUSED, CANCELLED), instalment_amount (INR), frequency (weekly, monthly, quarterly), instalment_day (monthly only, else 0), instalments (the number planned; -1 means until cancelled), completed_instalments, pending_instalments, next_instalment, last_instalment and tag.

NameTypeReqDescription
limitinteger–items per page
offsetinteger–items to skip
sip_id––one SIP; omit to list them all

No output schema declared.

No examples provided.

get_ohlc ~156

Last price and the day's open / high / low / close (close is the previous session's close) for up to 1000 instruments in one call, in INR. Returns {"quotes": {instrument: {instrument_token, last_price, ohlc}}, "missing": [...]} (`missing`: instruments Kite has no data for). Lighter than get_quotes: no depth, volume or open interest. Needs the paid Kite Connect plan.

NameTypeReqDescription
instrumentsarrayyes1 to 1000 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT")

No output schema declared.

No examples provided.

get_order_charges ~169

Charges Kite would levy on 1 to 50 executed or imaginary orders (a virtual contract note), without placing anything (works in read-only mode too): brokerage, transaction tax (STT, or CTT on commodities), exchange and SEBI turnover charges, stamp duty and GST, all INR. Give each order's average_price (the price it was or would be executed at; must be above 0); order_id can be any string. Each entry in `orders` is Kite's answer for one order: the order's fields, the price used and a `charges` block (total plus the breakdown). `summary` has the grand total, the total per component and a line per order.

NameTypeReqDescription
ordersarrayyes1 to 50 orders

No output schema declared.

No examples provided.

get_order_history ~53

Every state an order went through (put order req received, validation pending, open, complete, rejected...), oldest first, with the status_message of each step.

NameTypeReqDescription
order_idstringyesthe order_id

No output schema declared.

No examples provided.

get_order_margins ~183

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.

NameTypeReqDescription
mode––compact: only the totals; omit for the full breakdown
ordersarrayyes1 to 50 orders

No output schema declared.

No examples provided.

get_order_trades ~32

The fills that one order produced.

NameTypeReqDescription
order_idstringyesthe order_id (see get_orders)

No output schema declared.

No examples provided.

get_orders ~124

The day's order book (open and executed orders), newest first. Each order has order_id, status, status_message, variety, exchange, tradingsymbol, transaction_type, order_type, product, quantity, filled/pending/cancelled quantities, price, trigger_price, average_price, timestamps and tag.

NameTypeReqDescription
limitinteger––
offsetinteger––
statusstring–open = still working (OPEN, TRIGGER PENDING, AMO...), or a final state
tradingsymbol––only orders for this tradingsymbol

No output schema declared.

No examples provided.

get_positions ~197

Short-term positions (derivatives and intraday equity). `net` is the actual current position book; `day` is a snapshot of today's buying and selling, useful for intraday P&L. Each position has tradingsymbol, exchange, product, quantity, overnight_quantity, multiplier (lot-size multiplier for P&L: 1 for equity and F&O, the lot size for MCX), average_price, last_price, value, pnl, m2m, unrealised, realised and the buy / sell / day_buy / day_sell quantity, price and value. A `summary` per book totals pnl, m2m, unrealised and realised (INR) and counts the open positions (quantity not 0). Equity positions carried overnight move to the holdings the next day.

NameTypeReqDescription
kindstring–net: the actual current positions. day: today's buying and selling. both (default)

No output schema declared.

No examples provided.

get_profile ~57

The logged-in user's Kite profile: user id, name, email, broker, the exchanges, products and order types enabled for the account, and whether it is a demat consent / POA account (`meta.demat_consent`).

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

get_quotes ~232

Full market snapshot for up to 500 instruments in one call: last_price, last_quantity, volume, average_price, buy_quantity / sell_quantity, ohlc (close is the previous session's close), net_change, oi / oi_day_high / oi_day_low (F&O), lower / upper circuit limits and the 5-level market depth (buy / sell price, quantity, orders). Prices are in INR, timestamps in IST. Returns {"quotes": {instrument: snapshot}, "missing": [...]}: `missing` lists requested instruments Kite has no data for (misspelt, expired or not traded). Needs the paid Kite Connect plan; quote calls are limited to 1 per second. A full quote with depth is about 1.5 KB: for many instruments use get_ltp or get_ohlc.

NameTypeReqDescription
instrumentsarrayyes1 to 500 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT")

No output schema declared.

No examples provided.

get_safety_status ~79

How this server guards writes: trading mode (dry_run or live), read-only, how live writes are confirmed, the per-order / daily value caps and order count, the allow-lists, whether the kill switch is on, and what has been sent live today (counted from the audit log). Call this before planning any order.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

get_trades ~58

The day's executed trades (fills), newest first: trade_id, order_id, exchange, tradingsymbol, product, average_price, quantity, transaction_type, fill_timestamp.

NameTypeReqDescription
limitinteger––
offsetinteger––

No output schema declared.

No examples provided.

login ~200

Start the daily Kite login (managed auth mode): returns a one-time login link for the person to open. Show them the `warning` and the link. They log in at Kite themselves (user id, password, 2FA); never ask for their credentials and never try to log in for them. Kite then redirects to the app's registered redirect URL (`redirect_url`). This server completes the login when that redirect reaches it; if the redirect page cannot be reached, the person can copy the request_token from the browser's address bar (or the whole URL) and you call complete_login with it. If a valid token already exists nothing is issued, unless force=true; a new login ends the old token at Kite. In external auth mode another program owns the login: this only explains and shows the status.

NameTypeReqDescription
forceboolean–issue a new link even though a valid token exists (the new login ends the old token)

No output schema declared.

No examples provided.

logout ~110

End the Kite API session, delete the stored token and close any open login link (managed auth mode). Two steps: the first call (no confirmation_token) only describes what would happen and returns a confirmation_token; call again with it to do it. Every client using this token is signed out until the next login. It does not log the person out of the Kite web or mobile apps.

NameTypeReqDescription
confirmation_token––from the first call; omit it to see what would happen and get one

No output schema declared.

No examples provided.

modify_alert ~507

Modify an alert. Kite replaces the whole alert, so send its complete new definition: call get_alert first and change only what you mean to change. The fields are those of create_alert, with the same rules (for an ato alert that includes the whole basket `orders`). DRY RUN BY DEFAULT, confirmed like create_alert. Safety: an ato alert's new basket is checked like place_order. A modification takes no new slot of the daily order count, but the full value of the new basket counts toward the day's value cap. The dry run shows the stored alert. Kite's docs do not say whether a basket sent here replaces the stored basket or adds to it, so the dry run warns when the alert already has one. Returns the updated alert when sent.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
lhs_attributestring–what to monitor; LastTradedPrice is the only attribute Kite documents
lhs_exchangestringyesexchange of the monitored instrument: NSE, BSE, NFO, CDS, BCD, MCX, or INDICES for indices
lhs_tradingsymbolstringyestradingsymbol of the monitored instrument: INFY, 'NIFTY 50'
namestringyesa label for the alert
operatorstringyescomparison of the monitored value with the right-hand side
orders––the basket of orders: required for type=ato (up to 20), not allowed for simple
rhs_attribute––only for rhs_type=instrument; defaults to LastTradedPrice
rhs_constant––the number to compare with (INR for prices); only for rhs_type=constant
rhs_exchange––only for rhs_type=instrument
rhs_tradingsymbol––only for rhs_type=instrument
rhs_typestringyesconstant: compare with rhs_constant. instrument: compare with another instrument (rhs_*)
typestringyessimple: only notify. ato: also place the basket `orders` by itself when the condition is true
uuidstringyesthe alert's uuid (see get_alerts)

No output schema declared.

No examples provided.

modify_gtt_order ~394

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.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
exchangestringyesexchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX
last_pricenumberyesthe 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
ordersarrayyesthe order(s) to place: one for single, two for two-leg
tradingsymbolstringyestradingsymbol, e.g. INFY
trigger_idintegeryesthe GTT's trigger_id (see get_gtts)
trigger_valuesarrayyestrigger prices in INR, on the tick size: ONE value for single; TWO for two-leg, the lower first (trigger_values[i] fires orders[i])
typestringyessingle: one trigger, one order. two-leg: OCO, two triggers, two orders

No output schema declared.

No examples provided.

modify_order ~235

Modify an open or pending order: quantity, price, order_type, trigger_price, validity, disclosed_quantity (cover orders: price / trigger_price only). DRY RUN BY DEFAULT, confirmed like place_order. The new value is checked against the per-order cap and any increase against the daily cap. Kite allows 25 modifications per order.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
disclosed_quantity–––
dry_runboolean–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
market_protection––MARKET / SL-M: -1 or (0, 100]
order_idstringyes–
order_type–––
parent_order_id––co second leg: the parent
price–––
quantity–––
trigger_price–––
validity–––
varietystring–the order's variety (it is part of the URL)

No output schema declared.

No examples provided.

place_gtt_order ~558

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.

NameTypeReqDescription
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
dry_runboolean–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
exchangestringyesexchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX
last_pricenumberyesthe 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
ordersarrayyesthe order(s) to place: one for single, two for two-leg
tradingsymbolstringyestradingsymbol, e.g. INFY
trigger_valuesarrayyestrigger prices in INR, on the tick size: ONE value for single; TWO for two-leg, the lower first (trigger_values[i] fires orders[i])
typestringyessingle: one trigger, one order. two-leg: OCO, two triggers, two orders

No output schema declared.

No examples provided.

place_order ~529

Place an order. DRY RUN BY DEFAULT: with dry_run=true (the default) nothing is sent; the answer shows the exact request, the estimated value, Kite's margin calculation, every safety check and, when live trading is enabled and the checks pass, a confirmation_token. To send it, repeat the identical call with dry_run=false and that token. Live sends are checked against the server's caps and allow-lists and written to the audit log. Placing an order only registers it with Kite's OMS; check get_order_history for its fate. Live API orders must come from the static IP registered in the Kite developer console (SEBI rule, since April 2026).

NameTypeReqDescription
auction_number––auction only (get_auctions)
autoslice––split a quantity above the exchange freeze limit into up to 10 orders
confirmation_token––the confirmation_token returned by a dry run of this exact call (single use)
disclosed_quantity––quantity shown in the market
dry_runboolean–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
exchangestringyesNSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX
iceberg_legs––iceberg only: number of legs
iceberg_quantity––iceberg only: quantity per leg
market_protection––MARKET / SL-M only: -1 automatic, or a % above 0 and up to 100
order_typestringyesMARKET, LIMIT, SL (stop-limit), SL-M (stop-market)
price––limit price (LIMIT, SL)
productstringyesCNC delivery, MIS intraday, NRML F&O carry, MTF margin
quantityintegeryesunits (NFO/BFO: a multiple of the lot size)
tag––alphanumeric label, max 20 chars
tradingsymbolstringyese.g. INFY, NIFTY25NOVFUT
transaction_typestringyesBUY or SELL
trigger_price––trigger (SL, SL-M; stop-loss for co)
validity––DAY (default), IOC, or TTL
validity_ttl––minutes, for validity=TTL
varietystring–regular, amo (after market), co (cover), iceberg, auction

No output schema declared.

No examples provided.

refresh_instruments ~127

Download Kite's instrument list and mutual fund list into the local cache (a few MB). The cache refreshes itself on first use after 08:30 IST each day, so this is only needed after a failed refresh or when a brand-new contract is missing. Returns the same as get_instruments_status plus `refreshed` (the lists replaced). A list that fails to download keeps its old copy, and the error is shown under last_error.

NameTypeReqDescription
forceboolean–download both lists again even if today's are cached (default: only stale ones)

No output schema declared.

No examples provided.

search_instruments ~376

Find instruments in Kite's daily instrument list (cached locally; see get_instruments_status). Returns a list, best match first (exact tradingsymbol, then prefix, then substring; NSE before NFO before BSE), each with key (EXCHANGE:TRADINGSYMBOL, the name every other tool takes), instrument_token, exchange_token, tradingsymbol, name, exchange, segment, instrument_type, expiry, strike, lot_size (orders on NFO / BFO must be a multiple of it), tick_size (INR; limit prices must be a multiple of it) and last_price (from the daily dump, NOT live: use get_ltp). A full list (`limit` entries) may have more behind it: add filters. Examples: query="NIFTY", instrument_type="FUT", exchange="NFO" for index futures; query="RELIANCE", expiry="2026-11" for that month's contracts.

NameTypeReqDescription
exchange––NSE, BSE, NFO, BFO, CDS, BCD or MCX
expiry––derivatives only: "YYYY-MM-DD", or "YYYY-MM" for every expiry in that month
instrument_type––EQ (also indices), FUT, CE or PE
limitinteger–most results to return
querystring–part of the tradingsymbol or company name, case-insensitive; every word must match, in any order (e.g. "infy", "nifty bank", "reliance"). May be empty when a filter is given
segment––e.g. NSE, BSE, INDICES, NFO-FUT, NFO-OPT, BFO-OPT, CDS-FUT, MCX-FUT

No output schema declared.

No examples provided.

search_mf_instruments ~243

Find mutual fund schemes on Zerodha Coin in Kite's daily mutual fund list (cached locally). Returns a list, best match first, each with tradingsymbol (the scheme's ISIN, which the MF tools take), amc, name, purchase_allowed, redemption_allowed, minimum_purchase_amount and purchase_amount_multiplier (INR), minimum_additional_purchase_amount, minimum_redemption_quantity and redemption_quantity_multiplier (units), dividend_type (growth / payout), scheme_type, plan (direct / regular), settlement_type, last_price (the latest NAV, INR) and last_price_date.

NameTypeReqDescription
amc––part of the fund house code, e.g. "AXIS" (codes look like AXISMUTUALFUND_MF)
limitinteger–most results to return
plan––direct or regular
querystring–part of the fund name or its ISIN, case-insensitive; every word must match (e.g. "axis bluechip", "INF846K01DP8"). May be empty when a filter is given
scheme_type––equity, debt, elss ...

No output schema declared.

No examples provided.

session_status ~238

Whether this server is logged in to Kite, and what to do if it is not. Call this first: Kite sessions end every day at 06:00 IST. Returns `logged_in`, the token's `expires_at` and `minutes_left`, `auth_mode` (managed: this server does the daily login; external: another program keeps the token file and this server only reads it), `login_managed_here`, the token file path, `minutes_to_token_reset` (to the next 06:00 IST), and a one-line `safety` summary (trading mode, read-only). The token itself is never shown. verify=true also makes one live call to Kite and adds `verify` with the user id or Kite's error. Use it when a token that looks valid might have been ended elsewhere (logging in again with the same API key, or a master logout on the Kite web, ends the earlier token).

NameTypeReqDescription
verifyboolean–also ask Kite once (GET /user/profile) whether it still accepts the token, and report the account's user id or Kite's error

No output schema declared.

No examples provided.

ticker_get_ticks ~244

The latest tick received for each subscribed instrument, from the server's cache (nothing is requested from Kite). Each tick has instrument (when known), instrument_token, mode, last_price and, for quote and full, last_traded_quantity, average_traded_price, volume_traded, total_buy_quantity, total_sell_quantity, ohlc {open, high, low, close} and change (% from the previous close); full adds oi, oi_day_high, oi_day_low, last_trade_time, exchange_timestamp and depth {buy, sell} (5 levels of {quantity, price, orders}). Prices are in rupees, times in IST. Every tick also has received_at and age_s (seconds since it arrived): ticks stop outside market hours or when the connection is down, so check age_s, or pass max_age_s to be told which instruments are stale. Instruments subscribed but without a tick yet are listed under no_tick_yet.

NameTypeReqDescription
instruments––which instruments (names and/or tokens); default: every subscribed instrument
max_age_s––leave out ticks older than this many seconds; they are listed under stale

No output schema declared.

No examples provided.

ticker_order_updates ~312

Order updates and broker messages received by this server: the WebSocket stream (live updates for orders placed anywhere on the account: web, mobile or API) and, when KITE_MCP_POSTBACK_PATH is set, Kite postbacks sent to the HTTP endpoint. Each item has seq, received_at, source ("ticker" or "postback"), type ("order"; "error" or "message" for Kite's own text) and data. For orders, data has order_id, status (COMPLETE, REJECTED, CANCELLED, UPDATE...), status_message, exchange, tradingsymbol, transaction_type, order_type, product, variety, quantity, filled_quantity, pending_quantity, price, trigger_price, average_price and timestamps. Only the last 500 items are kept, in memory, and items arrive only while the WebSocket is open (ticker_subscribe, even with an empty list, opens it) or the postback endpoint is receiving. Without since: the latest items, oldest first. With since: the first items after it, so you can page forward (more=true means there are further ones). These are notifications, not the book of record: a postback is authenticated only by a checksum over order_id and order_timestamp, so confirm what matters with get_order_history.

NameTypeReqDescription
limitinteger–at most this many items
since––ISO 8601 time (IST if no offset): only items received after it, oldest first

No output schema declared.

No examples provided.

ticker_status ~121

The state of the WebSocket ticker: state (idle, connecting, connected, retrying, waiting_for_login, blocked, failed), connected, connected_since, last_message_at (any frame, heartbeats included), last_tick_at, reconnects, subscriptions by mode, how many ticks and order updates are cached, packets_skipped (frames this server could not parse), last_error, and blocked (why the ticker stopped retrying: Kite refused the token, for example because the app has no paid WebSocket plan). Nothing in it is secret.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

Install

How do I install the Kite Connect MCP server?

Kite Connect MCP runs locally as a PyPI package, launched with uvx kite-connect-mcp serve. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · kite-connect-mcp

# add to Claude Code
claude mcp add techfreakworm-kite-connect-mcp -- uvx kite-connect-mcp serve
Common questions

What is the Kite Connect MCP server?

Kite Connect MCP is listed in the public MCP registry as io.github.techfreakworm/kite-connect-mcp. Zerodha Kite Connect v3 for AI agents: orders (dry-run by default), GTT, alerts, portfolio, quotes. This page covers its PyPI package (kite-connect-mcp).

Is the Kite Connect MCP server safe to use?

Kite Connect MCP scores 65 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Kite Connect MCP server expose?

Kite Connect MCP exposes 53 tools: session_status, login, complete_login, logout, get_profile, and 48 more. Their descriptions and schemas cost roughly 10,725 tokens of context every time the server is loaded.

Is the Kite Connect MCP server still maintained?

Kite Connect MCP is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the Kite Connect MCP server under?

Kite Connect MCP declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

What did VerifyMCP test on the Kite Connect MCP server?

VerifyMCP ran 15 checks on Kite Connect MCP, covering Known CVEs, Install scripts, Dependency health, Source repository and 11 more. One item could not be completed, a gap on our side rather than a finding about Kite Connect MCP: Malware scan. Endpoint Security and Transport & Reachability do not apply to a PyPI package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.