18 tools with consistent verb-noun naming (get_, view_, call_, send_, deploy_, transfer_, add_, delete_, stake_, unstake_). All tools have descriptions (avg ~80 chars, baseline 194). Input schemas present for all tools with type declarations. However, descriptions are terse and lack context on WHEN to use each tool, prerequisites, or recovery guidance. Parameter descriptions are minimal (avg ~50 chars, baseline 72). No output schemas documented. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Missing tool annotations (readOnlyHint, destructiveHint). Composition is reasonable (single responsibility per tool), but no pagination support for list-like operations (get_validators, get_access_keys). Risk classification present (READ_ONLY vs WRITE) but not surfaced to LLM.

• Document output schemas for all tools. Specify field names, types, and formats (e.g., balance returned as formatted NEAR string, not yocto). Include example responses in tool descriptions or a separate schema reference.
• Expand descriptions to 100 - 200 chars. Add WHEN to use (vs similar tools), prerequisites, and what the tool returns. E.g., 'Call view_contract_state to inspect contract storage; use call_contract_function to execute read-only methods that compute results.'
• Add error handling guidance to WRITE tools. Document common failures (insufficient balance, invalid account, permission denied) and recovery steps. E.g., 'If transfer fails with insufficient balance, call get_account_balance first.'
• Implement tool annotations via MCP. Mark WRITE tools with destructiveHint=true, READ_ONLY tools with readOnlyHint=true, and idempotent operations with idempotentHint=true. This enables LLMs to reason about side effects.
• Add pagination to get_validators and get_access_keys. Accept limit (1 - 100, default 20) and offset/cursor parameters. Return total_count and next_cursor in responses to enable multi-page iteration.