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
Last scanned (11 hours ago)
Scores higher than 62% of PyPI servers
Category Finance and Payments
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
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 →
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.
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 →
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 →
authorise_holdings Authorise holdings for sale (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
No output schema declared.
No examples provided.
cancel_order Cancel an open order (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| parent_order_id | – | – | co second leg: the parent |
| variety | string | – | the order's variety (it is part of the URL) |
No output schema declared.
No examples provided.
complete_login Complete the Kite login by hand ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| request_token | string | yes | 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) |
No output schema declared.
No examples provided.
convert_position Convert a position's product (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | exchange of the position: NSE, BSE, NFO, BFO, CDS, BCD, MCX |
| new_product | string | yes | the margin product to convert to |
| old_product | string | yes | the position's current margin product |
| position_type | string | yes | overnight: carried over from a previous day. day: opened today |
| quantity | integer | yes | quantity to convert (MCX/CDS/BCD: lots) |
| tradingsymbol | string | yes | e.g. INFY, NIFTY25NOVFUT |
| transaction_type | string | yes | the position's side: BUY for a long position, SELL for a short one |
No output schema declared.
No examples provided.
create_alert Create an alert (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | exchange of the monitored instrument: NSE, BSE, NFO, CDS, BCD, MCX, or INDICES for indices |
| lhs_tradingsymbol | string | yes | tradingsymbol of the monitored instrument: INFY, 'NIFTY 50' |
| name | string | yes | a label for the alert |
| operator | string | yes | 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 | yes | constant: compare with rhs_constant. instrument: compare with another instrument (rhs_*) |
| type | string | yes | simple: only notify. ato: also place the basket `orders` by itself when the condition is true |
No output schema declared.
No examples provided.
delete_alerts Delete alerts (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | uuids of the alerts to delete (see get_alerts), up to 50 |
No output schema declared.
No examples provided.
delete_gtt_order Delete a GTT (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | the GTT's trigger_id (see get_gtts) |
No output schema declared.
No examples provided.
engage_kill_switch Engage the 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.
| Name | Type | Req | Description |
|---|---|---|---|
| reason | string | yes | why writes are being stopped |
No output schema declared.
No examples provided.
get_alert One alert ~50
One alert by its uuid: type, name, status, condition, alert_count and, for an ato alert, its basket.
| Name | Type | Req | Description |
|---|---|---|---|
| uuid | string | yes | the alert's uuid (see get_alerts) |
No output schema declared.
No examples provided.
get_alert_history When an alert triggered ~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).
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
| uuid | string | yes | the alert's uuid (see get_alerts) |
No output schema declared.
No examples provided.
get_alerts 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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
| status | – | – | only alerts in this state (enabled, disabled, deleted); omit for the default list |
No output schema declared.
No examples provided.
get_auctions Auctions of your holdings ~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 Audit log of write attempts ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| date | – | – | IST date YYYY-MM-DD; omit for today |
| limit | integer | – | newest N events |
| tool | – | – | only events of this tool, e.g. place_order |
No output schema declared.
No examples provided.
get_basket_margins Margin required for a basket of orders ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 1 to 50 orders |
No output schema declared.
No examples provided.
get_gtt One 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.
| Name | Type | Req | Description |
|---|---|---|---|
| trigger_id | integer | yes | the GTT's trigger_id (see get_gtts) |
No output schema declared.
No examples provided.
get_gtts GTT order book ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
| status | – | – | only GTTs in this state; omit for all (active, triggered, disabled, expired, ...) |
No output schema declared.
No examples provided.
get_historical_data Historical candles ~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`.
| Name | Type | Req | Description |
|---|---|---|---|
| continuous | boolean | – | futures only, interval day: stitch the expired contracts of a future together |
| from_date | string | yes | start (IST): "YYYY-MM-DD" (from 00:00:00) or "YYYY-MM-DD HH:MM:SS" |
| instrument | – | yes | EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") or a numeric instrument_token (e.g. 408065) |
| interval | string | yes | 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 | yes | 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 |
No output schema declared.
No examples provided.
get_holdings 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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
| tradingsymbol | – | – | only holdings of this tradingsymbol, e.g. INFY |
No output schema declared.
No examples provided.
get_instrument Instrument details ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| instrument | – | yes | EXCHANGE: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 Instrument list 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 Last traded prices ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| instruments | array | yes | 1 to 1000 instruments, each EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") |
No output schema declared.
No examples provided.
get_margins Funds and 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.
| Name | Type | Req | Description |
|---|---|---|---|
| segment | – | – | equity or commodity; omit for both |
No output schema declared.
No examples provided.
get_mf_holdings Mutual fund 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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | items per page |
| offset | integer | – | items to skip |
No output schema declared.
No examples provided.
get_mf_orders Mutual fund 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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) |
No output schema declared.
No examples provided.
get_mf_sips Mutual fund 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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | items per page |
| offset | integer | – | items to skip |
| sip_id | – | – | one SIP; omit to list them all |
No output schema declared.
No examples provided.
get_ohlc OHLC quotes ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| instruments | array | yes | 1 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 Charges for orders (virtual contract note) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| orders | array | yes | 1 to 50 orders |
No output schema declared.
No examples provided.
get_order_history 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.
| Name | Type | Req | Description |
|---|---|---|---|
| order_id | string | yes | the order_id |
No output schema declared.
No examples provided.
get_order_margins Margin required for orders ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| mode | – | – | compact: only the totals; omit for the full breakdown |
| orders | array | yes | 1 to 50 orders |
No output schema declared.
No examples provided.
get_order_trades Trades of an order ~32
The fills that one order produced.
| Name | Type | Req | Description |
|---|---|---|---|
| order_id | string | yes | the order_id (see get_orders) |
No output schema declared.
No examples provided.
get_orders Today's 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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
| status | string | – | 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 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.
| Name | Type | Req | Description |
|---|---|---|---|
| kind | string | – | net: the actual current positions. day: today's buying and selling. both (default) |
No output schema declared.
No examples provided.
get_profile User 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 Full market 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.
| Name | Type | Req | Description |
|---|---|---|---|
| instruments | array | yes | 1 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 Safety settings and today's usage ~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 Today's trades ~58
The day's executed trades (fills), newest first: trade_id, order_id, exchange, tradingsymbol, product, average_price, quantity, transaction_type, fill_timestamp.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
No output schema declared.
No examples provided.
login Log in to Kite ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | 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 Log out of Kite ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 Modify an alert (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | exchange of the monitored instrument: NSE, BSE, NFO, CDS, BCD, MCX, or INDICES for indices |
| lhs_tradingsymbol | string | yes | tradingsymbol of the monitored instrument: INFY, 'NIFTY 50' |
| name | string | yes | a label for the alert |
| operator | string | yes | 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 | yes | constant: compare with rhs_constant. instrument: compare with another instrument (rhs_*) |
| type | string | yes | simple: only notify. ato: also place the basket `orders` by itself when the condition is true |
| uuid | string | yes | the alert's uuid (see get_alerts) |
No output schema declared.
No examples provided.
modify_gtt_order Modify a GTT (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | exchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX |
| last_price | number | yes | 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 | yes | the order(s) to place: one for single, two for two-leg |
| tradingsymbol | string | yes | tradingsymbol, e.g. INFY |
| trigger_id | integer | yes | the GTT's trigger_id (see get_gtts) |
| trigger_values | array | yes | 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 | yes | single: one trigger, one order. two-leg: OCO, two triggers, two orders |
No output schema declared.
No examples provided.
modify_order Modify an open order (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | – |
| 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) |
No output schema declared.
No examples provided.
place_gtt_order Place a GTT (dry run by default) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | exchange of the instrument: NSE, BSE (equity), NFO, BFO (F&O), CDS, BCD, MCX |
| last_price | number | yes | 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 | yes | the order(s) to place: one for single, two for two-leg |
| tradingsymbol | string | yes | tradingsymbol, e.g. INFY |
| trigger_values | array | yes | 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 | yes | single: one trigger, one order. two-leg: OCO, two triggers, two orders |
No output schema declared.
No examples provided.
place_order Place an order (dry run by default) ~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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 | yes | MARKET, LIMIT, SL (stop-limit), SL-M (stop-market) |
| price | – | – | limit price (LIMIT, SL) |
| product | string | yes | CNC delivery, MIS intraday, NRML F&O carry, MTF margin |
| quantity | integer | yes | units (NFO/BFO: a multiple of the lot size) |
| tag | – | – | alphanumeric label, max 20 chars |
| tradingsymbol | string | yes | e.g. INFY, NIFTY25NOVFUT |
| transaction_type | string | yes | 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 |
No output schema declared.
No examples provided.
refresh_instruments Refresh the instrument list ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | download both lists again even if today's are cached (default: only stale ones) |
No output schema declared.
No examples provided.
search_instruments 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
No output schema declared.
No examples provided.
search_mf_instruments Search mutual fund schemes ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 ... |
No output schema declared.
No examples provided.
session_status 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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
No output schema declared.
No examples provided.
ticker_get_ticks Latest cached 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 Order updates and broker messages ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | 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 WebSocket 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.
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
claude mcp add techfreakworm-kite-connect-mcp -- uvx kite-connect-mcp serve
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.