Suna has 6 tools with basic schemas and descriptions, but significant gaps prevent higher scores. All tools have descriptions (10-80 chars, mostly short), and input schemas are present with type definitions. However, descriptions are often too brief to guide LLM selection (e.g., 'Move cursor to specified position' lacks context on when to use it vs. click). Parameter descriptions are minimal or missing context. No output schemas documented. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. Tool composition shows some issues: move_to and click could be unified; expand_message is vague about when to use it. No evidence of idempotency guarantees, rate limiting, or permission gates. Naming is generally clear (verb_noun pattern), but some tools like execute_data_provider_call are overly generic.

• Add output schemas for all tools. Document the structure of responses (e.g., move_to returns {success: bool, x: number, y: number}, click returns {success: bool, timestamp: string}).
• Expand tool descriptions to 50-200 chars. Include WHEN to use the tool, WHAT it does, and WHAT it returns. Example: 'Move the mouse cursor to (x, y) coordinates. Use before click() if you need to position the cursor without clicking. Returns success status and final coordinates.'
• Add error handling guidance. Document which errors are retryable (network timeout, service unavailable) vs. user-fixable (invalid coordinates, service not found) vs. fatal (permission denied).
• Constrain the 'payload' parameter in execute_data_provider_call. Either enumerate valid fields per service_name, or require a schema parameter that specifies the expected structure.
• Consider unifying move_to and click into a single 'click_at(x, y, button, num_clicks)' tool with optional coordinates. If coordinates are omitted, click at current position; if provided, move and click in one call.