# Kite Connect MCP (pypi · kite-connect-mcp) Zerodha Kite Connect v3 for AI agents: orders (dry-run by default), GTT, alerts, portfolio, quotes - Trust score: 65/100 (medium) - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-05 ## Components - pypi · `kite-connect-mcp`: 65/100 (this document), [markdown](https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp.md), [page](https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp) ## Channel facts - Registry: `pypi` - Package: `kite-connect-mcp` - Version: `0.1.1` - Transport: `stdio` ## Trust breakdown 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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-11-05. - **Supply Chain Security**: 50/100 - Malware scan not yet available for this package. - No known CVEs affecting this package version or its production dependencies. - Runs hatchling.build at install time, a recognised build step with no custom scripting around it. - 1 of 29 dependencies flagged as unhealthy. - **Provenance & Transparency**: 100/100 - Source repository is publicly reachable at the declared URL. - Cryptographically verified build provenance (signed, bound to techfreakworm/kite-connect-mcp). - Clear OSI-approved license (MIT). - Actively maintained (last published 1 days ago). - Publishes a security disclosure policy (SECURITY.md). - **Schema Quality & AI Usability**: 62/100 - AI-judged instruction clarity (good). - 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. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 7/100 - Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 96/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 89% of tool parameters carry a description. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation. - An AI judge read all 54 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a current MCP spec version (2026-07-28). ## 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. ### Claude ```bash claude mcp add techfreakworm-kite-connect-mcp -- uvx kite-connect-mcp serve ``` ### Cursor ```json { "mcpServers": { "techfreakworm-kite-connect-mcp": { "command": "uvx", "args": [ "kite-connect-mcp", "serve" ] } } } ``` ### VS Code ```json { "servers": { "techfreakworm-kite-connect-mcp": { "command": "uvx", "args": [ "kite-connect-mcp", "serve" ] } } } ``` ### Codex ```bash codex mcp add techfreakworm-kite-connect-mcp -- uvx kite-connect-mcp serve ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "techfreakworm-kite-connect-mcp": { "type": "local", "command": [ "uvx", "kite-connect-mcp", "serve" ], "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add techfreakworm-kite-connect-mcp --command uvx --arg kite-connect-mcp --arg serve ``` ### Hermes ```yaml mcp_servers: techfreakworm-kite-connect-mcp: command: "uvx" args: ["kite-connect-mcp", "serve"] ``` ### Netclaw ```json { "McpServers": { "techfreakworm-kite-connect-mcp": { "Transport": "stdio", "Command": "uvx", "Arguments": [ "kite-connect-mcp", "serve" ] } } } ``` ### Vellum ```bash assistant mcp add techfreakworm-kite-connect-mcp -t stdio -c uvx -a kite-connect-mcp serve ``` ### Other ```json { "mcpServers": { "techfreakworm-kite-connect-mcp": { "command": "uvx", "args": [ "kite-connect-mcp", "serve" ] } } } ``` ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-11-05 (score 65, +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. ### 2026-11-04 (score 64, 0) - [functional improvement] Stability: unverified → 0.03 - [functional] Package version: 0.1.0 → 0.1.1 ### 2026-11-03 (score 64) First indexed and scored. ## MCP tools (53) ### `session_status` (~238 tokens) Session status 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). Input parameters: - `verify` (boolean): also ask Kite once (GET /user/profile) whether it still accepts the token, and report the account's user id or Kite's error ### `login` (~200 tokens) Log in to Kite 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. Input parameters: - `force` (boolean): issue a new link even though a valid token exists (the new login ends the old token) ### `complete_login` (~149 tokens) Complete the Kite login by hand 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. Input parameters: - `request_token` (string, required): the 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) ### `logout` (~110 tokens) Log out of Kite 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. Input parameters: - `confirmation_token`: from the first call; omit it to see what would happen and get one ### `get_profile` (~57 tokens) User profile 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`). ### `get_margins` (~88 tokens) Funds and margins 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. Input parameters: - `segment`: equity or commodity; omit for both ### `get_orders` (~124 tokens) Today's orders 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. Input parameters: - `limit` (integer) - `offset` (integer) - `status` (string): open = still working (OPEN, TRIGGER PENDING, AMO...), or a final state - `tradingsymbol`: only orders for this tradingsymbol ### `get_order_history` (~53 tokens) Order history Every state an order went through (put order req received, validation pending, open, complete, rejected...), oldest first, with the status_message of each step. Input parameters: - `order_id` (string, required): the order_id ### `get_trades` (~58 tokens) Today's trades The day's executed trades (fills), newest first: trade_id, order_id, exchange, tradingsymbol, product, average_price, quantity, transaction_type, fill_timestamp. Input parameters: - `limit` (integer) - `offset` (integer) ### `get_order_trades` (~32 tokens) Trades of an order The fills that one order produced. Input parameters: - `order_id` (string, required): the order_id (see get_orders) ### `place_order` (~529 tokens) Place an order (dry run by default) 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). Input parameters: - `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_run` (boolean): 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` (string, required): NSE, 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_type` (string, required): MARKET, LIMIT, SL (stop-limit), SL-M (stop-market) - `price`: limit price (LIMIT, SL) - `product` (string, required): CNC delivery, MIS intraday, NRML F&O carry, MTF margin - `quantity` (integer, required): units (NFO/BFO: a multiple of the lot size) - `tag`: alphanumeric label, max 20 chars - `tradingsymbol` (string, required): e.g. INFY, NIFTY25NOVFUT - `transaction_type` (string, required): BUY or SELL - `trigger_price`: trigger (SL, SL-M; stop-loss for co) - `validity`: DAY (default), IOC, or TTL - `validity_ttl`: minutes, for validity=TTL - `variety` (string): regular, amo (after market), co (cover), iceberg, auction ### `modify_order` (~235 tokens) Modify an open order (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `disclosed_quantity` - `dry_run` (boolean): 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_id` (string, required) - `order_type` - `parent_order_id`: co second leg: the parent - `price` - `quantity` - `trigger_price` - `validity` - `variety` (string): the order's variety (it is part of the URL) ### `cancel_order` (~153 tokens) Cancel an open order (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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_id` (string, required) - `parent_order_id`: co second leg: the parent - `variety` (string): the order's variety (it is part of the URL) ### `get_gtts` (~145 tokens) GTT order book 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. Input parameters: - `limit` (integer) - `offset` (integer) - `status`: only GTTs in this state; omit for all (active, triggered, disabled, expired, ...) ### `get_gtt` (~64 tokens) One GTT 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. Input parameters: - `trigger_id` (integer, required): the GTT's trigger_id (see get_gtts) ### `place_gtt_order` (~558 tokens) Place a GTT (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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` (string, required): exchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX - `last_price` (number, required): 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 - `orders` (array, required): the order(s) to place: one for single, two for two-leg - `tradingsymbol` (string, required): tradingsymbol, e.g. INFY - `trigger_values` (array, required): 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]) - `type` (string, required): single: one trigger, one order. two-leg: OCO, two triggers, two orders ### `modify_gtt_order` (~394 tokens) Modify a GTT (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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` (string, required): exchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX - `last_price` (number, required): 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 - `orders` (array, required): the order(s) to place: one for single, two for two-leg - `tradingsymbol` (string, required): tradingsymbol, e.g. INFY - `trigger_id` (integer, required): the GTT's trigger_id (see get_gtts) - `trigger_values` (array, required): 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]) - `type` (string, required): single: one trigger, one order. two-leg: OCO, two triggers, two orders ### `delete_gtt_order` (~179 tokens) Delete a GTT (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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` (integer, required): the GTT's trigger_id (see get_gtts) ### `get_alerts` (~154 tokens) Alerts 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. Input parameters: - `limit` (integer) - `offset` (integer) - `status`: only alerts in this state (enabled, disabled, deleted); omit for the default list ### `get_alert` (~50 tokens) One alert One alert by its uuid: type, name, status, condition, alert_count and, for an ato alert, its basket. Input parameters: - `uuid` (string, required): the alert's uuid (see get_alerts) ### `get_alert_history` (~97 tokens) When an alert triggered 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). Input parameters: - `limit` (integer) - `offset` (integer) - `uuid` (string, required): the alert's uuid (see get_alerts) ### `create_alert` (~654 tokens) Create an alert (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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_attribute` (string): what to monitor; LastTradedPrice is the only attribute Kite documents - `lhs_exchange` (string, required): exchange of the monitored instrument: NSE, BSE, NFO, CDS, BCD, MCX, or INDICES for indices - `lhs_tradingsymbol` (string, required): tradingsymbol of the monitored instrument: INFY, 'NIFTY 50' - `name` (string, required): a label for the alert - `operator` (string, required): comparison 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_type` (string, required): constant: compare with rhs_constant. instrument: compare with another instrument (rhs_*) - `type` (string, required): simple: only notify. ato: also place the basket `orders` by itself when the condition is true ### `modify_alert` (~507 tokens) Modify an alert (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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_attribute` (string): what to monitor; LastTradedPrice is the only attribute Kite documents - `lhs_exchange` (string, required): exchange of the monitored instrument: NSE, BSE, NFO, CDS, BCD, MCX, or INDICES for indices - `lhs_tradingsymbol` (string, required): tradingsymbol of the monitored instrument: INFY, 'NIFTY 50' - `name` (string, required): a label for the alert - `operator` (string, required): comparison 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_type` (string, required): constant: compare with rhs_constant. instrument: compare with another instrument (rhs_*) - `type` (string, required): simple: only notify. ato: also place the basket `orders` by itself when the condition is true - `uuid` (string, required): the alert's uuid (see get_alerts) ### `delete_alerts` (~176 tokens) Delete alerts (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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 - `uuids` (array, required): uuids of the alerts to delete (see get_alerts), up to 50 ### `get_holdings` (~207 tokens) Holdings 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. Input parameters: - `limit` (integer) - `offset` (integer) - `tradingsymbol`: only holdings of this tradingsymbol, e.g. INFY ### `get_positions` (~197 tokens) Positions 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. Input parameters: - `kind` (string): net: the actual current positions. day: today's buying and selling. both (default) ### `get_auctions` (~74 tokens) Auctions of your holdings 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. ### `convert_position` (~420 tokens) Convert a position's product (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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` (string, required): exchange of the position: NSE, BSE, NFO, BFO, CDS, BCD, MCX - `new_product` (string, required): the margin product to convert to - `old_product` (string, required): the position's current margin product - `position_type` (string, required): overnight: carried over from a previous day. day: opened today - `quantity` (integer, required): quantity to convert (MCX/CDS/BCD: lots) - `tradingsymbol` (string, required): e.g. INFY, NIFTY25NOVFUT - `transaction_type` (string, required): the position's side: BUY for a long position, SELL for a short one ### `authorise_holdings` (~315 tokens) Authorise holdings for sale (dry run by default) 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. Input parameters: - `confirmation_token`: the confirmation_token returned by a dry run of this exact call (single use) - `dry_run` (boolean): 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 ### `get_quotes` (~232 tokens) Full market quotes 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. Input parameters: - `instruments` (array, required): 1 to 500 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") ### `get_ohlc` (~156 tokens) OHLC quotes 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. Input parameters: - `instruments` (array, required): 1 to 1000 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") ### `get_ltp` (~123 tokens) Last traded prices 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. Input parameters: - `instruments` (array, required): 1 to 1000 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") ### `get_historical_data` (~543 tokens) Historical candles 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`. Input parameters: - `continuous` (boolean): futures only, interval day: stitch the expired contracts of a future together - `from_date` (string, required): start (IST): "YYYY-MM-DD" (from 00:00:00) or "YYYY-MM-DD HH:MM:SS" - `instrument` (required): EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") or a numeric instrument_token (e.g. 408065) - `interval` (string, required): candle size: minute, 3minute ... 60minute, or day - `limit`: keep only the newest N candles (default and maximum 2000) - `oi` (boolean): add the open interest column (futures and options) - `to_date` (string, required): end (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 ### `search_instruments` (~376 tokens) Search instruments 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. Input parameters: - `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 - `limit` (integer): most results to return - `query` (string): 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 ### `get_instrument` (~142 tokens) Instrument details 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. Input parameters: - `instrument` (required): EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") or a numeric instrument_token (e.g. 408065) ### `get_instruments_status` (~89 tokens) Instrument list status 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. ### `refresh_instruments` (~127 tokens) Refresh the instrument list 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. Input parameters: - `force` (boolean): download both lists again even if today's are cached (default: only stale ones) ### `search_mf_instruments` (~243 tokens) Search mutual fund schemes 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. Input parameters: - `amc`: part of the fund house code, e.g. "AXIS" (codes look like AXISMUTUALFUND_MF) - `limit` (integer): most results to return - `plan`: direct or regular - `query` (string): 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 ... ### `get_order_margins` (~183 tokens) Margin required for orders 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. Input parameters: - `mode`: compact: only the totals; omit for the full breakdown - `orders` (array, required): 1 to 50 orders ### `get_basket_margins` (~202 tokens) Margin required for a basket of orders 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. Input parameters: - `consider_positions` (boolean): true (default): net the basket against your open positions; false: price it alone - `mode`: compact: only the totals; omit for the full breakdown - `orders` (array, required): 1 to 50 orders ### `get_order_charges` (~169 tokens) Charges for orders (virtual contract note) 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. Input parameters: - `orders` (array, required): 1 to 50 orders ### `get_mf_holdings` (~126 tokens) Mutual fund holdings 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. Input parameters: - `limit` (integer): items per page - `offset` (integer): items to skip ### `get_mf_orders` (~207 tokens) Mutual fund orders 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. Input parameters: - `limit` (integer): items per page - `offset` (integer): 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) ### `get_mf_sips` (~159 tokens) Mutual fund SIPs 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. Input parameters: - `limit` (integer): items per page - `offset` (integer): items to skip - `sip_id`: one SIP; omit to list them all ### `ticker_subscribe` (~329 tokens) Stream live ticks Start streaming live market data for instruments over Kite's WebSocket. The server opens one connection in the background on the first call (it needs the paid Kite Connect plan and a current login), reconnects and resubscribes by itself, and keeps the latest tick of every subscribed instrument for ticker_get_ticks. Modes: ltp (last price), quote (default: last price, last quantity, average price, volume, buy/sell quantity, OHLC, change %), full (quote plus open interest, last trade time, exchange timestamp and 5 levels of bid/offer depth). Indices have no volume or depth. Subscribing an instrument again with another mode switches its mode. At most KITE_MCP_TICKER_MAX_SUBSCRIPTIONS instruments (default 1000; Kite allows 3000) can be subscribed. An empty instruments list only opens the connection, which is how to receive order updates (ticker_order_updates) without market data. This changes only the server's own streaming state; it places no orders. Input parameters: - `instruments` (array, required): EXCHANGE:TRADINGSYMBOL names (NSE:INFY, NSE:NIFTY 50, NFO:NIFTY25NOVFUT) and/or numeric instrument tokens (408065). Names are looked up in the instrument list; if that cannot be loaded, use tokens. - `mode` (string): ltp = last price only; quote = price, volume, OHLC, buy/sell quantity; full = quote plus open interest and 5-level market depth ### `ticker_unsubscribe` (~115 tokens) Stop streaming instruments Stop streaming instruments and drop their cached ticks. Instruments that were not subscribed are listed under not_subscribed. The WebSocket connection stays open (order updates keep arriving); ticker_stop closes it. Input parameters: - `instruments` (array, required): EXCHANGE:TRADINGSYMBOL names (NSE:INFY, NSE:NIFTY 50, NFO:NIFTY25NOVFUT) and/or numeric instrument tokens (408065). Names are looked up in the instrument list; if that cannot be loaded, use tokens. ### `ticker_get_ticks` (~244 tokens) Latest cached ticks 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. Input parameters: - `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 ### `ticker_status` (~121 tokens) WebSocket ticker status 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. ### `ticker_order_updates` (~312 tokens) Order updates and broker messages 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. Input parameters: - `limit` (integer): at most this many items - `since`: ISO 8601 time (IST if no offset): only items received after it, oldest first ### `ticker_stop` (~64 tokens) Stop the WebSocket ticker Close the WebSocket connection and forget all subscriptions and cached ticks (order updates already received stay available). Calling ticker_subscribe later starts afresh, which is also how to retry after Kite refused the connection with the current token. Safe to call when nothing is running. ### `get_safety_status` (~79 tokens) Safety settings and today's usage 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. ### `get_audit_log` (~99 tokens) Audit log of write attempts 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. Input parameters: - `date`: IST date YYYY-MM-DD; omit for today - `limit` (integer): newest N events - `tool`: only events of this tool, e.g. place_order ### `engage_kill_switch` (~68 tokens) Engage the kill switch 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. Input parameters: - `reason` (string, required): why writes are being stopped ## Diagnostics Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp#diagnostics ## Score history - 2026-11-05: 65 - 2026-11-04: 64 - 2026-11-03: 64 ## 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. ## Links - PyPI project: https://pypi.org/project/kite-connect-mcp/ - Socket report: https://socket.dev/pypi/package/kite-connect-mcp - Repository: https://github.com/techfreakworm/kite-connect-mcp - Changelog RSS feed: https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp/changelog.json - Trust report (JSON): https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp.json - HTML version of this page: https://verifymcp.io/servers/techfreakworm-kite-connect-mcp/kite-connect-mcp