Portfolio Tracker has three tools with basic schemas and descriptions present, but they suffer from significant gaps in parameter documentation, output schema specification, and error handling guidance. Tool names follow verb-noun convention (fetch, analyze, get), which is correct. However, parameter descriptions are minimal, output structures are not formally documented, and there is no guidance on error recovery or tool chaining. The server implements caching and DeFi analysis logic but exposes none of this to the LLM as structured output. Descriptions are adequate but generic, averaging ~80 chars, above the 34-char floor but well below the 194-char baseline for production tools. None of the tools include enum constraints, format specifications, or pagination hints despite dealing with transaction lists. This is representative of a community-grade server: functional but not production-ready.

• Document output schemas for each tool. For fetchWalletActivity, specify: returns array of {signature, type, timestamp, value, success, programId, token}. For analyzeWallet, return {walletAddress, patterns: {patternType, confidence, description}, defiPositions: [{protocol, type, value, apy, timestamp}], riskProfile, recommendations: [string]}. For getTransactionDetails, return {signature, timestamp, status, fee, instructions: [{...}]}.
• Add pagination support to fetchWalletActivity: add 'before' (cursor, optional) and 'limit' (1-100, default 20) parameters. Return {transactions: [...], cursor_next: string|null} to enable iteration over large transaction histories.
• Enhance parameter descriptions with format and constraint hints. 'address' → 'Solana wallet address (base58 string, 44 chars, e.g. 1A1z...). Invalid addresses will return an error, use search_wallets if you have only a name.' 'limit' → 'Maximum transactions to fetch (1 - 100, default 20). Results beyond limit require pagination.'
• Add enum constraint for 'limit' default or explicit validation range in description. Current numeric default of 20 is fine but needs bounds: min: 1, max: 100.
• Implement error classification in tool responses: retryable errors (network timeout, rate limit) with 'try again' guidance; user-fixable errors (invalid address) with 'valid format is...' and example correction; fatal errors with alternatives ('Wallet not found. Did you mean: ...').
• Add idempotency guidance. fetchWalletActivity and getTransactionDetails appear read-only (Risk: READ_ONLY declared), confirm they are safe to call multiple times with the same input.