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 context. Neither tool documents output schema structure. No error recovery guidance. Descriptions are present but generic (baseline: 194 chars avg; these are ~80-100 chars). Parameters lack type constraints (enums, ranges). No validation rules visible in tool definitions.

• Add explicit enum constraints for 'action' parameter in both tools. If valid actions are known at registration time (e.g., from contract.actions), declare them as z.enum() so LLMs see valid options.
• Document output schema for each tool. Example: 'Returns {task_id: string, status: string, task: {id, status, result_url, created_at, updated_at}}' so LLMs know what fields to expect.
• Expand tool descriptions to 100-200 characters with WHEN/WHY context. Example for get_task: 'Poll the status and results of a previously created video generation task. Call this after creating a task to check if it has completed and retrieve output URLs.'
• Add recovery guidance to error scenarios. Example: 'If task not found, verify the task_id matches the ID returned when you created the task. Task IDs are unique per RunAPI account.'
• Clarify parameter defaults in descriptions. For get_task: 'If only one async endpoint exists, action defaults to that endpoint. If multiple endpoints exist, you must specify which one the task was created on.'