Three tools with complete input schemas and descriptions, but significant quality gaps. Tool names follow verb_noun pattern (solve_*), which is good. Descriptions are present (80-120 chars) but lack actionable context for LLM selection, they state WHAT but not WHEN or WHY to use each tool. Parameters are typed and mostly described, but lack constraints (enums, ranges, format hints). No output schemas documented. Error handling is absent, no guidance on retryability, failure modes, or recovery paths. The tools appear to be wrappers around a captcha-solving service with human-in-the-loop dispatch, but this critical architectural detail is buried in descriptions rather than surfaced clearly.

• Document output schemas for all three tools. E.g. solve_recaptcha_v2 returns {token: string, challenge?: string, timestamp: number}. This enables LLMs to chain results into downstream tools.
• Expand descriptions to 150-200 chars with WHEN/WHY context. E.g. 'Solve reCAPTCHA v2 (checkbox or invisible). Use this when the target site loads api.js with a sitekey. Returns g-recaptcha-response token for form submission.'
• Add enum constraints for apiDomain (google.com | recaptcha.net) and document valid userAgent patterns. Replace free-form 'cookies' with structured {name, value} array or document the exact format expected.
• Implement error classification: document which failures are retryable (timeout, network), which require user intervention (human solver declined), and which are fatal (invalid sitekey). Provide recovery guidance for each.
• For GeeTest v4 initParameters, replace 'object' type with explicit schema: {captcha_id: {type: string, description: 'Required GeeTest captcha ID'}, ...}. Or link to GeeTest v4 API docs.