kite-connect-mcp

Historical candles

get_historical_data

Read-onlyIdempotent

Fetch OHLCV candles for one instrument between two IST dates with configurable intervals, optional open interest, and automatic range splitting for historical market analysis.

Instructions

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.

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": {
      "instrument": "<instrument>",
      "interval": "<interval>",
      "from_date": "<from_date>",
      "to_date": "<to_date>"
    },
    "name": "get_historical_data"
  }
}

Input Schema

Name	Required	Description
`oi`	No	add the open interest column (futures and options)
`limit`	No	keep only the newest N candles (default and maximum 2000)
`to_date`	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
`interval`	Yes	candle size: minute, 3minute ... 60minute, or day
`from_date`	Yes	start (IST): "YYYY-MM-DD" (from 00:00:00) or "YYYY-MM-DD HH:MM:SS"
`continuous`	No	futures only, interval day: stitch the expired contracts of a future together
`instrument`	Yes	EXCHANGE:TRADINGSYMBOL (e.g. "NSE:INFY", "NSE:NIFTY 50", "NFO:NIFTY25NOVFUT") or a numeric instrument_token (e.g. 408065)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say read-only/idempotent; the description adds the operational traits that matter: per-interval Kite range caps, automatic request splitting (newest first), stop-at-limit behavior, the `truncated`/`note` signal, the paid-plan requirement and a 3 requests-per-second rate limit. It also warns about response size (~25 tokens per candle, ~50k for 2000) — none of which the annotations convey.

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

Conciseness4/5

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

Front-loaded with purpose and return shape, then limits, then cost — a sensible information hierarchy with no filler. It is dense and somewhat long, but every sentence carries operational content.

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?

No output schema exists, yet the description fully specifies the return envelope, the meaning of `columns`, `date` semantics (candle start, day candles at 00:00), and the `truncated`/`note` paging contract. Pagination, rate limits and cost are all covered, which is everything an agent needs for a 7-parameter historical-data tool.

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 baseline is 3; the description still adds value by tying parameters together — continuous=true requires interval=day, oi=true is zero or null for plain equities, and limit always keeps the newest candles and interacts with truncation. The date-format and instrument examples are duplicated from the schema.

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?

Opens with a specific verb+resource+scope: 'OHLCV candles for one instrument between two IST times, oldest first, in INR'. Ordering, timezone and currency are stated up front, so an agent knows exactly what comes back and how it differs from a snapshot-style quote or OHLC tool.

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?

Gives concrete escalation guidance: when 'truncated' is true, call again with to_date just before the first candle returned, and 'ask for the range you need, or set limit' to control cost. It never names the sibling snapshot tools (get_ohlc, get_quotes) as alternatives, so the when-not-to-use side is left implicit.

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