This server has 19 tools with basic input schemas and descriptions, but significant quality gaps prevent a higher score. All tools have descriptions (good), but most descriptions are generic and under 100 chars, lacking the LLM-optimized detail needed to disambiguate similar tools. Parameter descriptions are present but minimal. Output schemas are undocumented, the server provides no visibility into what fields are returned, forcing LLMs to reason about response structure. Critical security issue: tools like sendPayment, createAsset, deployContract, callContract, and mintNFT accept private keys as parameters, violating secret-injection patterns. The server is STDIO-only, capping protocol readiness at 50. Tool naming follows verb_noun conventions (good), but descriptions lack actionable context about when to use each tool vs. similar ones. No error handling guidance is visible. Composition is generally sound, each tool has a single concern, but chaining IDs are not documented in response schemas.

• URGENT: Move private key handling to server-side secret injection. Accept mnemonic phrases or key references (e.g., 'test_account', 'named_key_xyz') instead of raw base64 keys. Store actual keys in environment variables or a vault and resolve references server-side.
• Document output schemas for all tools in the server codebase. Specify the structure returned by each tool (e.g., getAccountInfo returns {address, amount, minBalance, ...}). Include this in tool metadata or a separate schema registry.
• Expand descriptions to 80-150 characters and add selection guidance. Example: 'Get current network status (last round, supply, chain info). Call this first to verify network connectivity before making transactions.'
• Add min/max bounds to numeric parameters. Example: searchTransactions limit parameter (1 - 1000), createAsset decimals (0 - 19), amount in ALGO (0 - 1e15).
• Document mutually exclusive parameters. Example: getAssetBalance description: 'Provide EITHER assetId (for custom assets) OR symbol (for 40+ popular assets). Do not pass both.'
• Document magic values and context-dependent behavior. Example: sendPayment 'from' parameter can be an address OR the literal string "test" to use the configured test account.
• Add tool annotations for write operations: mark sendPayment, createAsset, deployContract, callContract, mintNFT with destructiveHint=true and idempotentHint=false to signal they modify state and are not idempotent.
• Implement dry-run or confirmation-request pattern for irreversible operations. Example: sendPayment accepts optional dry_run=true to validate without executing, or returns an input_required result asking user to confirm.