Server has 9 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search_engine, scrape_as_markdown, list_datasets). Descriptions are present and substantive (100-250 chars typical). However, output schemas are not documented in the source code, LLMs cannot predict return structure. Parameter descriptions are good but lack explicit constraints (enums, ranges, patterns). Error handling is minimal, no recovery guidance or categorization. Batch tools (search_engine_batch, scrape_batch) are well-designed for composition. Async/polling pattern (scrape_async_trigger + scrape_poll) is sound but lacks progress reporting.

• Document output schemas for all tools. Example: search_engine returns {results: [{title: string, url: string, snippet: string, position: int}], total_results: int}. Use JSON Schema in tool definition or docstring.
• Formalize parameter constraints as enums and patterns. Change 'engine' description to include enum: ['google', 'bing', 'yandex']. Add pattern for 'country': '^[A-Z]{2}$'. Add minimum/maximum for 'max_workers': {minimum: 1, maximum: 10}.
• Add error handling guidance to tool descriptions. Example: 'Returns 401 if API key invalid (check BRIGHTDATA_API_KEY env var). Returns 429 if rate limited (retry after 60s). Returns 400 if URL malformed (validate URL format before calling).'
• Enhance async polling with progress. scrape_poll should return {status: 'pending'|'completed'|'failed', progress_percent: 0-100, estimated_seconds_remaining: int, partial_results?: object}. Agents can then decide to wait or cancel.
• Add rate-limit and timeout guidance. Document max concurrent requests, credit consumption per call, and timeout behavior. Example: 'Each search costs 1 credit. Batch calls limited to 10 parallel requests. Timeout: 30s per request.'

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry