Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling. get_task has optional parameters with minimal guidance on defaults and dependencies. check_pricing lacks clarity on what 'model' and 'action' mean in practice. Neither tool documents output structure or error recovery paths. Descriptions are present but generic (avg ~80 chars, below the 194-char baseline for A+ tools). No parameter descriptions visible in the schema definitions, only inline in code comments. Error handling returns jsonText() with generic error fields, offering no recovery guidance to LLMs.

• Add parameter descriptions to both tools. For get_task.action, clarify: 'The asynchronous endpoint where the task was created (e.g., qwen_2_generate). Required if multiple endpoints exist; defaults to the only endpoint if one is available.' For check_pricing.model, explain: 'RunAPI model slug (e.g., qwen-2-vl-72b). Defaults to the primary model for this line.'
• Document output schemas explicitly. E.g., get_task returns {task_id, status: 'pending'|'completed'|'failed', task: {result_url?, error_message?}}. check_pricing returns {model, pricing: {input_cost_per_1k, output_cost_per_1k}, pricing_url}.
• Enhance error messages with recovery guidance. Instead of {error: 'Task not found'}, return {error: 'Task not found', hint: 'Verify the task_id is correct. If the task expired, create a new one with the appropriate endpoint tool.'}
• Rename or clarify the 'action' parameter to avoid confusion. Consider 'endpoint' for get_task and 'pricing_endpoint' for check_pricing to make the distinction explicit.
• Expand tool descriptions to include prerequisites and use cases. E.g., 'Call this after creating an async task to poll its status. Returns the latest result payload once the task completes. Typical polling interval: 1-5 seconds.'