MCP server for trading on the Ostium platform with support for opening/closing positions, updating take profit/stop loss levels, modifying trades, fetching market data, and managing wallet balances on Arbitrum network
Ostium MCP has comprehensive tool coverage (18 tools) with proper schema definitions and descriptions. Most tools follow naming conventions well (verb_noun pattern). However, there are significant gaps in error handling guidance, output schema documentation, and some parameter descriptions lack specificity. The server mixes trading-specific complexity with good structure, but descriptions could better guide LLM selection and recovery flows.
Close an existing trading position partially or completely by specifying the trading pair, position index, and closure percentage (in basis points). Allows flexible position management with partial closures (e.g., 50% closure) or full position closure (100%).
Retrieve real-time price data for all available trading assets on the Ostium platform, including current bid/ask prices, price changes, volume data, and market timestamps. Essential for market overview and price discovery.
Retrieve detailed real-time price information for a specific asset pair, including current price, bid/ask spread, 24h change, volume, and last update timestamp. Ideal for focused market analysis and trade execution planning.
Retrieve ETH and USDC balances for the current user's wallet address on Arbitrum network. Returns both native ETH balance and USDC token balance with proper decimal formatting.
Retrieve a comprehensive list of all orders across the entire Ostium platform, providing system-wide order book visibility and market activity overview.
Missing output schema documentation. Tools like get_pairs, get_all_orders, fetch_wallet_balances, and fetch_asset_prices have no visible output schema definitions. LLMs cannot plan downstream calls without knowing return structure.
No error handling guidance in any tool descriptions. Descriptions state WHAT the tool does but never indicate what could go wrong or how the LLM should recover (e.g., 'if trade_id not found', 'if wallet balance insufficient').
Destructive/irreversible operations lack confirmation or dry-run pattern. withdraw and close_trade are destructive but have no built-in safeguard or confirmation step. Agents can permanently delete positions or send funds without a chance to verify.
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 | 55 | - | v1 |
Retrieve all pending limit and stop orders for a specific wallet address, showing order details like trigger prices, order sizes, expiration times, and order status.
Retrieve all currently active trading positions for user's wallet address, including position details like collateral, leverage, current P&L, take profit/stop loss levels, and position size.
Retrieve detailed information for a specific order using its unique identifier, including order status, execution details, timestamps, and associated trade information.
Retrieve detailed information for a specific trading pair including current prices, spread, trading fees, minimum trade sizes, leverage limits, and market statistics. Useful for market analysis and trade planning.
Retrieve a comprehensive list of all available trading pairs on the Ostium platform, including asset symbols, pair IDs, and trading status information. Essential for discovering which markets are available for trading.
Retrieve recent trading history for a specific wallet address with configurable number of orders to fetch. Shows executed trades, timestamps, profits/losses, and trade outcomes for performance analysis.
Retrieve comprehensive details for a specific trade using its unique identifier, including entry/exit prices, profit/loss calculations, trade duration, and execution history.
Provide a hello prompt
Modify the collateral amount of an existing trading position by specifying the trading pair, position index, and amount to add or remove. Allows position scaling by increasing collateral to boost position size or reducing collateral to take partial profits.
Open a new trading position on any supported trading pair (e.g., BTC/USD, ETH/USD) with customizable parameters: USDC collateral amount, leverage multiplier, take profit and stop loss levels, trade direction (long/short), order type (market for immediate execution, limit for specific price, or stop for trigger price), and slippage tolerance. Supports both immediate market orders and pending orders with specific execution prices.
Update the stop loss level for an existing trading position by specifying the trading pair, position index, and new stop loss price. Essential for risk management, allowing traders to adjust loss-limiting levels to protect profits or limit further losses.
Update the take profit level for an existing trading position by specifying the trading pair, position index, and new take profit price. Essential for profit management, allowing traders to adjust target price levels to secure gains at desired price points.
Withdraw USDC or ETH tokens from the trading account to a specified Arbitrum/Ethereum address
Parameter descriptions in trading tools lack format/constraint specificity. 'collateral', 'leverage', 'openPrice', 'tp', 'sl' accept strings but do not state format (numeric string? decimals? range bounds?). LLMs cannot validate without explicit constraints.
Pagination parameters missing from result-returning tools. get_all_orders, get_open_trades, get_limit_orders, get_recent_history have no limit, offset, or page parameters. Large result sets will blow context window; no way to fetch incrementally.
withdraw description is vague (60 chars, under 20-char threshold for scoring penalty). Does not state confirmation, gas fees, or minimum withdrawal amounts. 'Withdraw USDC or ETH tokens from the trading account to a specified Arbitrum/Ethereum address' lacks actionable context for agent selection.
No permission/authorization declarations. Tools like withdraw, open_trade, close_trade do not declare required scopes (e.g., 'write:trades', 'transfer:funds'). Agents cannot assess privilege boundaries; audit trails lack context.
Tool naming mixes underscores and clarity inconsistently. Most follow verb_noun (get_pairs, update_tp), but 'fetch_wallet_balances' and 'fetch_asset_prices' use 'fetch' instead of 'get', creating ambiguity when list_* or search_* variants might also exist. Consider standardizing to get_* for consistency.