The Carrot MCP server demonstrates solid definition quality with clear, action-oriented naming and comprehensive descriptions. All 7 tools follow verb_noun patterns (get_*, issue_*, redeem_*), making intent immediately obvious. Descriptions are well-crafted (150-200 chars each), explicitly stating what the tool does, when to use it, and consequences (e.g., 'requires a transaction signature', 'includes 0.05% fee'). All parameters have descriptions and types. However, output schemas are not documented in the provided source, and error handling guidance is sparse. Tool composition is excellent, each tool has one clear responsibility, and the issue/redeem tool pairs provide good complementary coverage. No tools combine multiple concerns (e.g., no 'issue_and_send' tools). Security-critical wallet parameters are properly documented as user-provided inputs. The main gap is absence of explicit output schema definitions and error recovery guidance.

• Add explicit output schema definitions for each tool. Example for get_crt_apy: 'Returns {apy: number (0-100), timestamp: ISO8601, source: string}'. For write operations: 'Returns {transactionSignature: string, estimatedGasFee: number, status: "pending"|"confirmed", walletBalance: {creatTokenAmount: number, usdcAmount: number}}'.
• Expand error handling documentation. For each write tool, add: 'On error: insufficient balance returns code 4001 (user fixable, fund wallet); invalid wallet returns code 4002 (user fixable, verify address); network error returns code 5001 (retryable); transaction rejection returns code 4003 (user must re-approve).'
• Add format constraints to walletStr parameter: 'Solana wallet address in base58 format (32-44 characters, valid Solana mainnet/devnet address). Must be associated with an active on-chain account.' Or provide a separate resolve_wallet_address tool.
• For redeem_all_crt and issue_all_crt, add confirmation step: 'Implements multi-round-trip pattern: first call returns estimated outcome (amount to redeem, fees, final USDC/CRT received); agent must confirm; second call executes transaction.' This prevents accidental full-balance burns.
• Document the fee impact in uiAmount parameter descriptions. E.g., for redeem_crt: 'The uiAmount of CRT to redeem. Note: 0.05% redemption fee applies to the underlying stablecoin amount received.' This prevents agents from expecting 1:1 returns.
• Add parameter constraints: uiAmount should specify minimum (e.g., > 0) and maximum (e.g., <= wallet balance). Current schema shows type:number with no range, LLMs may try negative or absurdly large amounts.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry