Single tool 'process_locations_batch' has a descriptive name but suffers from critical definition gaps. Description is 287 chars (within baseline 194 avg), but the input schema is visible and reasonably detailed with 10 parameters. However, parameter descriptions are generic or missing context about interdependencies (e.g., 'addresses' vs 'source_file' mutual exclusivity not stated). The 'ctx' parameter is an MCP Context object, unusual for a tool parameter and suggests incomplete abstraction. No output schema is documented. The tool combines multiple concerns (batch processing, file I/O, vision analysis, spreadsheet generation) violating single-responsibility. Error handling is absent from the visible code snippet.

• Document the complete output schema: return type (object/array), field names, types, and whether results are paginated. Example: {results: [{address, status, image_url, analysis, error}], total_processed, failed_count}.
• Add explicit parameter constraints in descriptions: 'Provide EITHER addresses (array) OR source_file (path), not both. If source_file, address_column is required.'
• Split into three focused tools: (1) load_addresses_from_file(source_file, address_column, filter_query) → returns address list; (2) analyze_addresses_batch(addresses, analysis_prompt, analysis_schema, dry_run, timeout) → returns analysis results; (3) export_results(results, output_dir, format) → saves to file.
• Remove 'ctx' parameter from tool signature. Use server-side context injection via FastMCP's Context object internally, not as a user-facing parameter.
• Add error handling guidance: 'Returns per-address error details. If vision API fails, returns {status: "error", error: "Vision API unavailable"}. Retry with dry_run=true to check metadata only.'

Inferred effective spec: <=2025-11-25.

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