The CCXT MCP server defines 20 tools with explicit schemas and descriptions, but suffers from inconsistent quality across tools and missing output documentation. All tool names follow verb_noun conventions (good). All parameters have Zod schema definitions with type information. However, many descriptions are generic or lack context about when to use specific tools vs. alternatives. Output schemas are completely undocumented, no return type specifications visible. Error handling is present but inconsistent across tools (some tools check for capability support, others rely on try-catch). Tool descriptions average ~60-80 characters, which is below the 194-char production baseline. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present despite having 19 READ_ONLY and 1 REVERSIBLE and 1 DESTRUCTIVE tools. The server does not document parameter relationships (e.g., when 'symbol' is required vs. optional across different tools). Security model is sound (no API keys in parameters, they're loaded server-side from config), but no explicit permission gates are visible.

• Document output schema for each tool. Add a 'Returns' section in each tool description and/or include a JSON schema example of what the response structure looks like (e.g., balance returns {free, used, total, ...}, fetchTrades returns [{id, timestamp, symbol, side, price, amount, cost, ...}]).
• Add tool annotations to each tool definition. Set readOnlyHint=true for all 19 read-only tools (list*, fetch*, analyze*, calculate*), idempotentHint=true for tools like fetchBalance and fetchTicker (idempotent), and destructiveHint=true for createOrder and cancelOrder. This enables LLMs to reason about retry safety.
• Standardize error handling. Wrap all tools in consistent try-catch blocks. Return structured error responses with a clear message, error code, and remediation guidance (e.g., 'Invalid account: account_name not found. Available accounts: [...]'). Avoid raw exception messages.
• Enhance parameter descriptions with constraints and examples. For 'limit', specify 'Limit the number of results returned. Valid range: 1-1000, default: 50'. For 'period' and 'interval' enums, explain the interaction: 'period filters the trade history window; interval controls aggregation granularity'.
• Add pagination guidance. Document the max limit enforced by each exchange (CCXT varies by exchange), recommend default limits (20-50 for balance/trade queries), and explain how to handle large result sets. If CCXT supports cursor-based pagination, document it.
• Implement optional dry-run mode for createOrder. Add a 'dryRun' boolean parameter (default false) so agents can preview order impacts before executing. Return 'would_create_order' response on dry-run.