Two tools with schemas present but significant quality gaps. request_user_input has a vague, instruction-heavy description (165 chars) that reads like a prompt rather than a tool spec, and its single boolean parameter lacks actionable guidance. query_gas_stations has better structure with 9 parameters and output schema, but the description is procedural ('Only call this AFTER...') rather than declarative. Parameter descriptions are present but generic (e.g., 'User's confirmed longitude' doesn't explain validation, range, or format). No error handling guidance, no recovery paths, and no indication of what happens on failure. Output schema is documented but verbose (includes raw API fields like 'IsAvailable' that could be stripped). Tool names are verb-noun but descriptions don't explain WHEN or WHY to use each tool relative to the other.

• Rewrite request_user_input description as: 'Validate that the user is in Quebec and collect required search parameters (location, radius, gas type, vehicle specs) before querying gas stations. Returns guidance on what information to request from the user.' Remove procedural language.
• Add 4 parameters to request_user_input (or split into separate tool): location (postal code or intersection), searchRadiusKm, targetGasType, vehicleSpecs. Currently the tool accepts only a boolean but tells the LLM to ask for 4 pieces of info, this is backwards.
• Add numeric bounds to query_gas_stations parameters: radiusKm (1 - 100), fuelConsumption (1 - 30), fillUpVolume (5 - 100), limit (1 - 50). Document these in descriptions.
• Add error handling to query_gas_stations response: when 0 results, return 'No stations found within {radiusKm}km. Try increasing radius or changing gas type.' This guides the LLM's next action.
• Strip output schema: remove IsAvailable, Brand (optional), and raw GasType strings. Return only: name, address, distance, price (for selected gas type), and trueCost. Reduce token overhead and focus on user-relevant data.