BAS MCP server has 37 tools with significant quality gaps. Most tools have descriptions (good), but schemas are inconsistent and often lack proper type definitions. Many parameters are missing descriptions or have vague ones. Tool naming is inconsistent (bas_wait_element_visible vs bas_check_element_exists use different conventions). No output schemas documented. Error handling is absent, tools return raw results with no recovery guidance. Parameter descriptions often reference BAS-specific concepts without explaining them to LLMs. Critical issue: bas_wait_element_visible has 10 parameters with overlapping/unclear purposes (Check vs Check2, Speed/Gravity/Deviation duplicated in bas_no_fail_for_next_waiter). No pagination support despite tools like bas_get_logs potentially returning large results.

• Split bas_wait_element_visible into separate tools: wait_element_and_click (with Click, Speed, Gravity, Deviation) and wait_element_and_type (with TypeData, TypeInterval). Eliminate Check/Check2 ambiguity.
• Document output schemas for all tools. For bas_get_logs, specify: {logs: [{timestamp, level, message}], total_count, next_cursor}. For bas_get_project, specify action structure with id, type, params, children.
• Add pagination to bas_get_logs and bas_get_browser_html: add limit (default 50, max 500) and offset/cursor parameters. Return total_count and has_more flag.
• Rewrite descriptions for bas_resource_string_operations, bas_if_condition, bas_cycle_parameters to explain purpose in plain English, not BAS jargon. E.g., 'Execute conditional logic: if expression is true, run nested actions; else skip or run alternative branch.'
• Add error handling: return {success: bool, error: {code, message, recovery_hint}} for all tools. E.g., 'Element not found. Try increasing timeout with bas_set_timeout_for_next_waiter or verify selector with bas_get_browser_html.'