Three tools with complete input schemas and descriptions. Naming follows verb_noun convention (search_ads, get_ad_detail, get_user_ratings). Descriptions are adequate (50-100 chars) but lack actionable context for LLM selection. All parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (only domain validation shown). No guidance on when to use each tool vs alternatives. Parameter relationships (e.g., latitude/longitude required only when sort='distance') are documented but could be clearer.

• Document output schemas for all three tools. Example: 'Returns {ads: [{id, title, price, location, date, seller_id}], total_count, next_offset}'. This enables LLMs to chain calls and extract required fields.
• Expand tool descriptions to 100-150 chars with WHEN/WHY context. E.g., 'Search for ads by keyword, category, price range, or location. Use this to find multiple listings; use get_ad_detail for full seller info and contact details.'
• Add explicit validation and error messages for all parameters. Show code that validates section against SECTIONS enum, sort against SORT_TYPES, and offset/limit constraints. Return actionable errors like 'Invalid section: got "XY", must be one of: AU, DE, DU, ...'
• Document conditional parameter logic in schema. For search_ads, mark latitude/longitude as required only when sort='distance', or add a note: 'If sort=distance, latitude and longitude are required.'
• Add per-tool examples in descriptions showing typical use cases. E.g., 'search_ads: Find all cars under 10,000 CZK in Prague. get_ad_detail: Get seller contact info and full description for a specific listing. get_user_ratings: Check seller reputation before contacting.'