Loading ToolBench
MCP server for Zerodha trading platform integration, providing access to holdings, positions, orders, and trade history via OAuth authentication
This server exhibits significant definition quality gaps. While all 6 tools are explicitly defined with input schemas and descriptions, the descriptions are extremely brief (averaging ~60 chars, well below the 194-char baseline), most lack detailed parameter documentation, output schemas are not formally documented, and there is minimal guidance for error recovery or composition. Tool naming is reasonable but inconsistent, 'sayHello' and 'getLoginUrl' use camelCase while most follow get_* verb patterns. Parameter descriptions are sparse or missing entirely (e.g., 'callback' accepts 'requestToken' with only basic documentation). No tool declares output structure, error classifications, or recovery paths. Security concerns exist: credentials are logged in plaintext in generateSession(). The server targets a specialized financial API (Zerodha) but provides no domain-specific value descriptions or prerequisites. Per-tool analysis reveals most tools score 40-50, with only 'getLoginUrl' reaching 55.
Handle the callback from Zerodha after login. This method processes the request token received from Zerodha.
Generate session and get access token using the request token obtained after login
Get holdings - list of equity holdings
Get the Zerodha login URL. This is the first step in the OAuth flow.
Get positions - list of current day positions
A warm, friendly greeting from your new Workers MCP server.
Output schemas not documented. Tools return objects but no formal schema is declared for LLM to understand response structure (e.g., getHoldings, getPositions, generateSession return data without documented fields). LLMs cannot infer pagination, field types, or chaining IDs.
Parameter descriptions are minimal or absent. 'requestToken' in callback and generateSession lacks detail on format, length, or origin. 'name' in sayHello has minimal context. This violates the baseline that 100% of A+ tools document every parameter.
Credentials logged in plaintext. generateSession() calls console.log() with ZERODHA_API_KEY, requestToken, and partial API_SECRET. Agent traces will contain live credentials. Violates secret-injection pattern, credentials must never appear in logs or tool output.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error classification or recovery guidance. Tools throw generic errors (e.g., 'Access token not available') without telling the LLM what to do next. Should state: 'Call getLoginUrl() first to authenticate' or 'Retryable, wait 5s then retry'. LLMs need explicit recovery paths.
Tool descriptions too brief. Average description length ~60 chars (well below 194-char baseline). 'Get holdings - list of equity holdings' is redundant and lacks context on when to call it, what prerequisites exist, or what users would do with the data. Descriptions should be 50-200 chars and LLM-optimized.
Inconsistent naming convention. 'sayHello' uses camelCase; others use verb_noun or getX pattern. Inconsistency increases LLM confusion when selecting tools. Should standardize to snake_case (say_hello, get_login_url, get_holdings, get_positions).
No pagination support declared. getHoldings and getPositions may return large lists but no limit, offset, or page parameters are visible. Tools must accept page/offset and limit, and return total count or next_cursor.
Missing input validation and actionable error messages. If generateSession fails, the error is re-thrown without context. Should validate requestToken format, provide clear errors like 'Invalid request token format: expected 32-char alphanumeric, got "xyz"', and guide the LLM to re-authenticate via getLoginUrl.