Single tool with adequate naming and description, but critical gaps in schema documentation and parameter validation. The tool name 'extract_receipt' follows verb_noun convention and is clear. Description (156 chars) explains what the tool does and includes a validation note, meeting baseline expectations. However, the input schema is severely underdocumented: the 'source' parameter lacks type specification in the visible schema definition, and no output schema is documented. The tool returns a dict but callers have no visibility into the structure, field names, or types they should expect. Error handling is absent, no guidance on what happens if the source is invalid, the image cannot be processed, or extraction fails. This forces LLMs to guess at recovery strategies.

• Document the complete output schema with field names, types, and descriptions. Example: {receipt: {vendor: string, date: string (ISO 8601), category: string, total: number, items: [{description: string, quantity: number, unit_price: number}]}, confidence: number (0-1), notes: string[]}
• Add explicit constraints to the 'source' parameter: type (string), format (e.g., 'file path, URL, or opaque image ID'), length limits, and examples of valid values.
• Add error handling guidance to the tool description: 'Returns an error if source is invalid, image cannot be read, or extraction confidence is below 0.5. Callers should validate the confidence score before persisting data.'
• Replace the reference to agent1_extract with inline validation rules: 'Confidence threshold: 0.7+. Category must be in [meal, transport, accommodation, office_supplies, other]. Line items must sum to stated total.'
• Add a 'confidence_threshold' optional parameter (default 0.7) so callers can control acceptance criteria without post-processing.