Loading ToolBench
MCP server implementation for Zerodha's Kite Connect trading API, providing tools for portfolio management, market data, order placement, and trading operations
This server has 19 tools with mixed quality. Naming follows verb_noun convention well (get_*, place_, modify_, cancel_). However, descriptions are highly inconsistent, some are trivial (get_margins: 'Get margins', 11 chars), while others are adequate (place_order: full parameter breakdown). Many parameters lack descriptions entirely. Schema definitions are present but incomplete: input types and basic structure exist, but output schemas are not documented. The code shows proper tool registration via mark3labs/mcp-go, but the MCP layer lacks structured error handling, tool annotations (readOnlyHint/destructiveHint), and output schema documentation. HTTP transport is supported, but the server does not implement current spec features like per-request _meta logLevel, structured error recovery guidance, or Multi Round-Trip Requests. Overall, this is a functional but mediocre integration that lacks polish.
Cancel an existing order
Get all active GTT orders. Supports pagination for large datasets.
Get historical price data for an instrument
Get holdings for the current user. Supports pagination for large datasets.
Get latest trading prices for a list of instruments
Get margins
Get all mutual fund holdings. Supports pagination for large datasets.
Trivial descriptions for multiple tools (get_margins: 'Get margins', 11 chars). These provide no context for LLM tool selection and violate the 10 - 1024 character guideline with descriptions under 20 characters.
Output schemas are not documented. Tools return results from Kite API (holdings, positions, trades, orders, etc.) but the MCP server does not expose what fields are returned, their types, or required for downstream chaining. LLMs cannot infer response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Destructive operations (place_order, modify_order, cancel_order, place_gtt_order) are not marked with destructiveHint. LLMs cannot tell whether a tool is safe to retry.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Get order history for a specific order
Get trades for a specific order
Get all orders. Supports pagination for large datasets.
Get current positions. Supports pagination for large datasets.
Retrieve the user's profile information, including user ID, name, email, and account details like products orders, and exchanges available to the user. Use this to get basic user details.
Get market data quotes for a list of instruments
Get trading history. Supports pagination for large datasets.
Login to Kite API. This tool helps you log in to the Kite API. If you are starting off a new conversation call this tool before hand. Call this if you get a session error. Returns a link that the user should click to authorize access, present as markdown if your client supports so that they can click it easily when rendered.
Modify an existing order
Place a GTT (Good Till Triggered) order
Place an order
Search instruments. Supports pagination for large result sets.
Error responses lack recovery guidance. Tool handlers return generic error messages ('Failed to get order trades') without actionable steps. LLMs cannot self-correct or determine if errors are retryable.
Parameter descriptions missing for many tools. Enum fields (variety, exchange, transaction_type, product, order_type, validity, etc.) have descriptions in place_order/modify_order, but simple lookup tools (get_order_trades, get_order_history, get_quotes, get_ltp) lack parameter context beyond field name.
Pagination not consistently exposed. get_holdings, get_positions, get_trades, get_orders, get_gtts, get_mf_holdings support pagination (from, limit params), but output schema does not document total_count, next_cursor, or pagination metadata, forcing LLMs to infer pagination behavior.
No confirmation pattern for irreversible operations. place_order, cancel_order, and place_gtt_order can permanently affect user accounts but lack dry-run or confirmation step. Agents cannot preview consequences before executing.
Login tool description is verbose but unclear about OAuth/session flow. Description mentions 'a link that the user should click to authorize access' but does not explain how the session is stored, refreshed, or whether subsequent tool calls inherit this session state.