Skip to main content
Glama
kite-connect-mcp

kite-connect-mcp

Search instruments

search_instruments
Read-onlyIdempotent

Find Kite instruments in the cached daily list by symbol or name to get the key, token, lot size, tick size, and expiry for quotes and orders. Filter by exchange, segment, type, or expiry.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_instruments"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNomost results to return
queryNopart 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
expiryNoderivatives only: "YYYY-MM-DD", or "YYYY-MM" for every expiry in that month
segmentNoe.g. NSE, BSE, INDICES, NFO-FUT, NFO-OPT, BFO-OPT, CDS-FUT, MCX-FUT
exchangeNoNSE, BSE, NFO, BFO, CDS, BCD or MCX
instrument_typeNoEQ (also indices), FUT, CE or PE

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent profile, and the description adds real behavioral context: results are ranked (exact tradingsymbol, then prefix, then substring; NSE before NFO before BSE) and last_price comes from the daily dump, not live. It also discloses downstream constraints the agent cannot see elsewhere, namely that NFO/BFO order quantities must be multiples of lot_size and limit prices multiples of tick_size.

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 the core verb and resource, then ranked ordering, then field semantics, then examples; nothing is padding. It is dense and parenthetical-heavy, which costs some readability, but every clause carries information an agent would otherwise have to guess.

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?

With six optional parameters and no output schema, the description carries the full burden and meets it by enumerating return fields and their caveats, explaining ranking and truncation, and giving worked filter combinations. Nothing essential for a correct first call is missing.

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 description coverage is 100%, so the baseline is 3, but the description adds usable meaning: it clarifies that hitting `limit` means truncation and that filters should be tightened, and shows how expiry interacts with query in practice. Its explanation of the returned `key` format (EXCHANGE:TRADINGSYMBOL, accepted by every other tool) is outside the input schema but directly informs how results are reused as parameters elsewhere.

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?

States a specific verb and resource ('Find instruments in Kite's daily instrument list') and immediately scopes it with provenance ('cached locally') plus a sibling pointer to get_instruments_status. It also enumerates the returned fields, so an agent can tell this apart from get_instrument and search_mf_instruments without opening a schema.

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 explicit routing for two cases: check get_instruments_status for cache freshness and use get_ltp for live prices rather than trusting last_price. It also supplies concrete query recipes (index futures via query+instrument_type+exchange, month contracts via expiry). It stops short of naming get_instrument or search_mf_instruments as alternatives for exact-symbol or mutual-fund lookup, so the sibling map is not fully closed.

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