Amap All-in-One Maps

Problem

When building apps or agents that need map features, teams often repeat the same setup work: requesting an Amap key, converting free-form addresses into coordinates, and wiring together POI search, route planning, weather, and IP location calls. Parameter formats are inconsistent: coordinate-based tools expect lng,lat, while address-based routing may also need city names, which makes manual integration error-prone.

How It Works

Amap All-in-One Maps exposes a set of map APIs through an Amap proxy, so it can be used without a key. It splits common map capabilities into explicit tools:

• Location search: poi_search, poi_around, poi_detail, and input_tips for keyword search, nearby search, POI details, and input suggestions.
• Route planning: driving_route, transit_route, walking_route, and cycling_route, with *_by_address variants that automatically convert addresses to coordinates.
• Geocoding: geocode converts addresses to coordinates, and regeocode converts coordinates back to detailed addresses.
• Other capabilities: weather for city weather, ip_location for IP-based location, and district for administrative region information.

These tools can be chained by use case. For ambiguous place lookup, use input_tips -> poi_search -> poi_detail. For an IP-based nearby search, use ip_location -> poi_around -> route planning. For address-to-route flows, either call geocode first or use the address-based route tools directly.

Boundaries and Caveats

The skill returns structured map data; it does not provide real-time traffic conditions, turn-by-turn navigation audio, or map tile rendering. Walking routes are limited to 100km, cycling routes to 500km, and longer requests will error. Transit routes require a city name; if address parsing fails, add a more complete address or supply the city parameter. Search endpoints return 20 results by default and can be paginated with offset and page.