Three tools with complete schemas and descriptions, but quality is uneven. call_method has a verbose, example-heavy description that violates best practices (includes sample addresses like 'EQBInPs62kcCSGDwnCTx0FLzgNpu_t6sTca-mOXInYPBISzT' which LLMs will reuse literally). list_modules and list_methods lack output schema documentation. Parameters are typed (good) but descriptions are generic. No error handling guidance, no idempotent/destructive hints. Naming is verb-first (good), but call_method is vague, does not clearly distinguish what 'calling a method' entails vs. discovery tools.

• Remove example addresses from call_method description. Replace 'e.g., EQBInPs62kcCSGDwnCTx0FLzgNpu_t6sTca-mOXInYPBISzT' with a format constraint: 'Address format: 36-character base64url string or 0x-prefixed hex (48 chars).'
• Document output schemas for all tools. For list_modules, specify: returns {modules: [{name: string, description: string}]}. For list_methods, specify: returns {methods: [{name: string, params: object}]}.
• Add error recovery hints to call_method description: 'If module not found, call list_modules() first. If API key invalid, check TON_API_KEY environment variable.'
• Rename call_method to execute_ton_api_method or query_ton_api to clarify it executes methods, not just lists them. Reduces ambiguity vs. discovery tools.
• Add readOnlyHint and idempotentHint annotations to all three tools in the schema to signal they are safe to retry and do not modify state.