kite-connect-mcp

Stream live ticks

ticker_subscribe

Idempotent

Stream live market data for instruments over Kite's WebSocket and retain each subscribed instrument's current tick for retrieval, with ltp, quote, or full modes.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "instruments": "<instruments>"
    },
    "name": "ticker_subscribe"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No	ltp = last price only; quote = price, volume, OHLC, buy/sell quantity; full = quote plus open interest and 5-level market depth	quote
`instruments`	Yes	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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations, it discloses important operational behavior: the server opens one background connection on first call, requires a paid Kite Connect plan and current login, reconnects and resubscribes automatically, and keeps latest ticks available for ticker_get_ticks. It also clarifies mode switching, index limitations, subscription caps, and that it only changes server streaming state without placing orders.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, followed by lifecycle details, mode semantics, limits, and the empty-list special case. The paragraphs are organized and every sentence contributes operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stateful streaming subscription tool, the description covers prerequisites, background connection behavior, automatic reconnection, supported modes, subscription limits, and the special empty-instruments path. It is complete enough that an agent can invoke it correctly without needing an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines mode and instruments. The description still adds useful semantics: subscribing again with a different mode switches that instrument's mode, an empty list only opens the connection for order updates, and the KITE_MCP_TICKER_MAX_SUBSCRIPTIONS limit differs from Kite's 3000 cap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: start streaming live market data over Kite's WebSocket. It distinguishes itself from snapshot quote tools by emphasizing streaming and explicitly names ticker_get_ticks as the consumer of the latest ticks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly says when to use this tool for market data streaming and when to pass an empty instruments list for order updates via ticker_order_updates. It does not explicitly compare against one-off alternatives such as get_quotes or get_ltp, but the streaming use case is unambiguous.

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