Single tool 'get_routes' has a complete input schema with proper types and descriptions for all 7 parameters (query, sw_lat, sw_lon, ne_lat, ne_lon, page, max_results). Tool name follows verb_noun pattern. However, the output description is severely deficient: it lists field names in a prose block rather than documenting a structured schema. The docstring conflates input documentation with output documentation, making it unclear what the actual response structure is. No error handling guidance, no pagination metadata (total_count, next_cursor), and the tool returns a formatted string rather than structured JSON. The description lacks WHEN to use this tool and prerequisites. Output schema is completely undocumented, LLMs cannot plan downstream calls without knowing the response structure.

• Refactor output to return structured JSON: {"routes": [{"title", "url", "distance_km", "slope", "author", "location", "trailrank", ...}], "total_count": int, "page": int, "has_more": bool}. Document this schema in the tool description.
• Rewrite tool description as: 'Search Wikiloc for hiking routes within a geographic bounding box. Returns structured list of trails with distance, elevation, difficulty, and ratings. Use this to discover routes in a region; chain with get_route_details() for full trail info. Requires valid lat/lon bounds (SW corner, NE corner).'
• Add pagination metadata to response: return total_count and has_more flag so LLM knows when to call with page=2. Cap results at max_results (default 5) to avoid N+1 HTTP overhead.
• Add error handling: catch Wikiloc API failures and return {"error": "Wikiloc API unavailable", "suggestion": "Try again in 30 seconds or refine your search bounds"}. Return empty list with explanation if no routes found, not a bare string.
• Document the N+1 request cost in the description: 'Note: fetches detailed stats for each route, making 1 + N HTTP calls. Expect 2-10 second latency for max_results=5.'