Single tool 'search_jobs' has a well-structured schema with proper types, enums, and constraints. Description is clear and actionable (158 chars). All 11 parameters have descriptions and type definitions. However, output schema is not documented, the tool returns a complex nested object (results array with platform, jobs, total, error fields; summary array; params; fetched_at) but LLMs cannot see this structure in advance. No error handling guidance (e.g., what to do if a scraper fails, how to interpret the 'error' field in results). Parameter descriptions lack dependency hints (e.g., salary_min/max only apply when salary_type is set). No mention of rate limits, timeout behavior, or platform-specific limitations (e.g., 'Not all platforms expose application count' is noted but not actionable).

• Document the complete output schema in the tool description or as a separate schema field. Example: 'Returns {results: [{platform: string, jobs: [{id, title, company, location, salary, url, ...}], total: number, error?: string}], summary: [{platform, count, total, error}], fetched_at: ISO8601}'. This lets LLMs plan extraction and chaining.
• Add error classification and recovery guidance. E.g., 'If a platform returns an error, try the other platform. If both fail, ask the user to refine the search (e.g., larger radius, fewer filters).'
• Document parameter dependencies explicitly. Add to salary_min/max descriptions: 'Only applies when salary_type is set. Ignored if salary_type is omitted.' Add to employment_type: 'If omitted, all employment types are returned.'
• Clarify pagination behavior. Add to description: 'Results are paginated per platform. If page exceeds available results, that platform returns an empty jobs array. Use the total field to determine if more pages exist.'
• Specify which platforms expose application count and which do not. E.g., 'LinkedIn exposes application count; Seek does not. Filter max_applications applies only to LinkedIn results.'