Two well-defined tools with complete input schemas, clear descriptions, and proper parameter documentation. Both tools follow verb_noun naming (brightdata_unlock, brightdata_serp) and include actionable descriptions (194 - 250 chars, within baseline 34 - 392). All required and optional parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. No error handling guidance or recovery patterns. No tool annotations (readOnlyHint, idempotentHint). Both tools correctly declare READ_ONLY risk but lack structured error classification.

• Document output schemas for both tools. Specify response fields (status, body, headers for unlock; rank, title, link, description for serp), types, and pagination structure (total_count, next_cursor if applicable).
• Move _apiKey to server-side environment variable injection. Remove from tool parameters. Update descriptions to reference server configuration instead of user-provided tokens.
• Add error handling guidance: 'If you receive HTTP 401, the API token is invalid or expired. If 429, rate limit reached, wait before retrying. If timeout (>25s), the target site is blocking, try a different country or zone.'
• Add tool annotations: both tools are read-only and idempotent (same input → same output). Declare via schema metadata or description: 'This tool is read-only and safe to retry.'
• Document result limits and pagination: 'brightdata_unlock truncates responses to 20,000 characters. For large pages, use format=json to receive metadata. brightdata_serp returns up to 100 results; use start parameter for pagination (0, 10, 20, ...).' Include total_count in response.