Two well-named tools with clear, detailed descriptions (194 - 250 chars each). Input schemas are complete with type definitions and parameter descriptions. However, output schemas are entirely undocumented, LLMs cannot predict response structure or plan downstream calls. Error handling is minimal (generic HTTP error thrown). No input validation guidance for format constraints (e.g., postcode format, date ranges). Tool composition is sound: search_transactions and lookup_postcode are distinct, single-purpose tools. Naming follows verb_noun convention (search_, lookup_). Parameter descriptions include examples and constraints, but lack formal enum/pattern declarations in schema.

• Document output schema for both tools. Example: 'Returns {result: {items: [{pricePaid: number, transactionDate: string, address: string, propertyType: string, estateType: string, newBuild: boolean}], page: number, itemsPerPage: number, startIndex: number}}'.
• Add JSON Schema format and pattern constraints: postcode pattern '^[A-Z]{1,2}\d[A-Z\d]? ?\d[A-Z]{2}$', date format 'date' (YYYY-MM-DD), minPrice/maxPrice minimum 0.
• Wrap fetch() in try-catch with actionable error messages. Example: 'Invalid postcode format. Must be UPPERCASE with a space (e.g., SW1A 1AA). Got: {value}'. Return structured error with recovery hint.
• Add per-parameter validation examples in descriptions. E.g., 'minPrice: Minimum price in whole GBP (e.g., 250000). Must be >= 0 and <= maxPrice if both provided.'
• Document pagination behavior: 'Results are paginated. If itemsPerPage < total, call again with page+1. Max pageSize is 500. Omit page/pageSize to use defaults (page 0, size 25).'