20 tools with consistent naming (verb_noun pattern: get_, list_, search_) and basic descriptions. All tools are READ_ONLY, reducing complexity. However, descriptions are uniformly terse (10-80 chars, well below the 194-char baseline for A+ tools), lacking context on WHEN to use each tool or dependencies between them. Input schemas use Zod with type declarations and descriptions, but many tools lack parameters entirely (no pagination, no filtering beyond required IDs). Output schemas are undocumented, LLMs cannot predict response structure. Error handling is generic (catch-all errorResult) with no recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only.

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this to retrieve current account positions before placing an order'), dependencies (e.g., 'Requires accountNumber from stonex_list_accounts'), and a hint at response structure (e.g., 'Returns array of positions with symbol, quantity, and market value').
• Document output schemas for all tools. Use JSON Schema or a structured format to specify response fields, types, and nesting. E.g., stonex_get_summary should document: { accounts: [{ accountNumber, cash, marketValue, pnl }], total: { ... } }.
• Add pagination to tools returning lists. Implement page/offset + limit parameters and return total_count or next_cursor. Cap default results at 20-50 items and document the limit in the description.
• Enhance error handling. Categorize errors (retryable, user-fixable, fatal) and provide recovery hints. E.g., 'Account not found. Available accounts: [list]. Try stonex_list_accounts() to see all accounts.'
• Add tool annotations. Mark all tools with readOnlyHint=true and idempotentHint=true to signal safety to LLMs and reduce reasoning overhead.