Loading ToolBench
MCP server for Kraken Spot REST API integration, providing trading and market data tools
The Kraken Pro MCP server provides 17 trading and market data tools with explicit input schemas and descriptions. All tools are visible and explicitly registered via @mcp.tool decorator. Naming follows verb_noun conventions (add_order, cancel_order, open_orders, etc.). However, there are significant quality gaps: (1) Parameter descriptions lack detail on format/constraints. For example, 'pair' parameter accepts string but no hint that it expects format like 'XBTUSD'. (2) Output schemas are not documented, callers must infer return structure from implementation. (3) Error handling is present but minimal, errors are raised as KrakenError but recovery guidance is absent. (4) Tool descriptions are concise (50-150 chars) but lack dependency hints or when-to-use guidance. (5) The validate parameter in add_order has good documentation ('validate=True will not execute') but most other parameters lack similar clarity. (6) No tool annotations (readOnlyHint, destructiveHint) despite clear risk categories being assigned. Average parameter count is reasonable (2-5 per tool). Schema definitions are present in function signatures but parameter constraints (enums, ranges, patterns) are minimally documented in descriptions.
Place a new Kraken Spot order (REST AddOrder). NOTE: `validate=True` (default) will *not* execute the order; it only validates. Set `validate=False` to actually place the order.
Atomic amend in-place (keeps identifiers & queue priority where possible). You MUST provide one identifier (order_id or cl_ord_id) and at least one amendable field (order_qty, limit_price, trigger_price, display_qty).
Asset metadata. Example assets: 'XBT,ETH,USDT' aclass (optional): 'currency' (default) or other classes per Kraken.
Get your account balance / asset holdings.
Dead man's switch: set countdown to cancel ALL your orders after `timeout_seconds`. Pass 0 to disable the switch.
Cancel a particular open order (or set of orders). You can pass a Kraken order txid OR a userref (to cancel all with that userref).
Output schemas not documented. Tools return dict objects but callers cannot see what fields to expect, forcing LLMs to infer structure from context.
Parameter descriptions lack format/constraint details. 'pair' parameter accepts string but does not specify expected format (e.g., 'XBTUSD', 'ETHUSD'). 'interval' in ohlc has valid values (1, 5, 15, 30, 60, 240, 1440, 10080, 21600) but they are mentioned in description text, not formalized as enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Fetch closed orders (cancelled, expired, filled, etc.). Optionally filter by userref, trades, or time range.
OHLC candles. interval (minutes): 1, 5, 15, 30, 60, 240, 1440, 10080, 21600 since: optional Unix timestamp (seconds) or last id from a previous call.
Fetch open orders. Optionally filter by userref and include `trades` detail.
L2 order book (aggregated per price level). count: optional max levels per side.
Recent trades. Use the returned 'last' field as your next 'since' parameter.
Kraken server time (UTC).
Spread (best bid/ask) per timestamp for a pair. since: optional Unix timestamp (seconds) or last ID from a previous call.
Current system status / trading mode.
Level-1 ticker stats. Leave `pairs` None to get ALL. Example: 'XBTUSD,ETHUSD'
Tradable pairs & metadata. Example pairs: 'XBTUSD,ETHUSD'. info (optional): 'info', 'leverage', 'fees', 'margin', etc.
Fetch your trade history. Optionally filter by trades type and time range.
No tool annotations despite clear risk categories. Tools marked as WRITE, DESTRUCTIVE, and READ_ONLY in metadata but MCP tool definitions lack readOnlyHint, destructiveHint, or idempotentHint annotations.
Minimal error recovery guidance. KrakenError exceptions are raised with Kraken API error messages but do not guide the LLM on what to do next (retry, ask user, look up missing resource, etc.).
Short descriptions on read-only tools lack context. 'Kraken server time (UTC).' and 'Current system status / trading mode.' are under 50 chars and do not explain when to call these tools or what insight they enable.
Credential injection via environment variables is correct, but no explicit note in docstrings that API keys are required. If KRAKEN_API_KEY or KRAKEN_API_SECRET are missing, _require_keys() raises an error during private_post, not at tool invocation.
No pagination support visible in list tools. 'open_orders', 'closed_orders', 'trades_history', and other list-like tools do not accept limit/offset/page parameters, risking large responses that exhaust context.
Parameter validation is minimal. For example, 'volume' in add_order defaults to 0.0, which is invalid for actual orders. No runtime check prevents the agent from submitting orders with 0 volume.