Loading ToolBench
The Kite MCP server has 11 tools with complete schemas and descriptions. Naming is verb-based and clear (get_*, place_*, cancel_). Most descriptions are present and actionable. However, there are consistent gaps in parameter descriptions and output schema documentation. Parameter descriptions are sparse or missing for several tools, and critical output structures are not documented. Error handling exists but lacks recovery guidance. Security is properly handled (no credentials exposed as parameters). The server is domain-focused on financial trading, which reduces complexity but narrows applicability.
Cancel an existing order
Get current authentication status
Get long-term stock holdings
Get list of tradable instruments for an exchange
Get Last Traded Price for instruments
Get account margins and available funds
Get list of orders for the day
Get current trading positions
Parameter descriptions are minimal or missing context. Tools like get_ltp and get_quote accept 'instruments' parameter but lack guidance on format (should users pass 'NSE:INFY' or just 'INFY'? What if they have only a company name?). Pattern requires descriptions to guide LLM selection and proper invocation.
Output schemas are not documented. Tools return JSON but LLMs have no schema reference for what fields to expect (e.g., does get_profile return user_id, name, email, account_type, or all of these?). This forces agents to guess field names or make extra calls. Pattern requires documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Get user profile information from Kite
Get detailed market quote for instruments
Place a new trading order
Error handling lacks recovery guidance. Server returns McpError with message text (e.g., 'Not authenticated with Kite API. Please run authentication first.') but does not structure error types or suggest next steps programmatically. Pattern requires categorization: retryable vs user-fixable vs fatal.
place_order lacks validation guidance. No mention of conditional requirements (price required for LIMIT orders, trigger_price for SL/SL-M). LLMs cannot infer these dependencies; the tool should document them explicitly in parameter descriptions.
No pagination or result-limiting documented. Tools like get_instruments, get_orders, get_positions may return large lists. No mention of limit, offset, or pagination in schemas. Pattern requires pagination support and documented limits.
No confirmation or dry-run support for irreversible operations. place_order and cancel_order are destructive (real money impact) but lack a confirmation_request pattern or preview mode. Pattern requires destructive operations to support review before execution.