AMap MCP integration for AI agents.

Connect AI agents to AMap through 15 structured actions, including district search, geocode, and get place detail. Review authentication, inputs, workflows…

ACTION CONTRACTS
15
AUTHENTICATION
API key
SOURCE STATUS
Provider-backed

CATALOG SOURCE REVIEWED AUGUST 23, 2026 / ACTION NAMES AND SCHEMAS DERIVED FROM WORKING MACHINES PROVIDER SOURCE

CAPABILITY PROFILE

What the AMap integration exposes

The AMap Agent App exposes 15 provider-backed actions for location work. Its current contract lets an authorized agent search administrative districts, convert an address to coordinates, and get place details by id. These operations are called through Working Machines as typed capabilities rather than through browser navigation or copied UI steps.

A connection uses API key. Before execution, the agent can inspect the selected action, its required fields, declared scopes, and expected output contract. Provider credentials remain inside the Working Machines runtime; the calling agent receives the capability and its structured result, not the underlying secret.

For reliable operation, start with the narrowest action that satisfies the task, resolve stable provider identifiers before changing state, and validate the returned object or status after execution. Availability still depends on the connected AMap account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.

VERIFIED ACTION SAMPLE

Real AMap capabilities.

Showing 12 of 15 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.

district_searchREAD

Search administrative districts.

INPUTS: keywords / subDistrict / extensions / page / offset

geocodeREVIEW

Convert an address to coordinates.

INPUTS: address / city

get_place_detailREAD

Get place details by id.

INPUTS: id / showFields

input_tipsREVIEW

Get input tips by keywords.

INPUTS: keywords / type / location / city / cityLimit

ip_locateREVIEW

Locate by IP address.

INPUTS: ip

reverse_geocodeREVIEW

Convert coordinates to an address.

INPUTS: location / radius / extensions / roadLevel

route_bicyclingREVIEW

Plan a bicycling route.

INPUTS: origin / destination / alternativeRoute / showFields

route_drivingREVIEW

Plan a driving route.

INPUTS: origin / destination / waypoints / strategy / plate

route_electrobikeREVIEW

Plan an electric bike route.

INPUTS: origin / destination / showFields

route_transitREVIEW

Plan a transit route.

INPUTS: origin / destination / originCity / destinationCity / strategy

route_walkingREVIEW

Plan a walking route.

INPUTS: origin / destination / showFields

search_placesREAD

Search places by keyword.

INPUTS: keywords / region / cityLimit / types / pageNum

INPUT CONTRACTS

Know what the action needs before it runs.

district_search

keywordsREQUIRED
The district search keywords.
subDistrictOPTIONAL
The subdistrict depth.
extensionsOPTIONAL
The requested response detail level.
pageOPTIONAL
The page number to fetch.
offsetOPTIONAL
The result offset.

geocode

addressREQUIRED
The address to geocode.
cityOPTIONAL
The city used to narrow the geocode lookup.

get_place_detail

idREQUIRED
The place identifier.
showFieldsOPTIONAL
The requested output fields.

input_tips

keywordsREQUIRED
The keywords used to search tips.
typeOPTIONAL
The optional category filter.
locationOPTIONAL
The optional location bias.
cityOPTIONAL
The optional city filter.
cityLimitOPTIONAL
Whether to limit results to the specified city.

PROVIDER-SPECIFIC WORKFLOWS

Jobs this Agent App can support

Inspect District Search

Search administrative districts. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.

district_search

Verify with Get Place Detail

Get place details by id. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.

get_place_detail

SAFETY BOUNDARY

Operate AMap with explicit limits

  • Authorize AMap with API key and grant only the provider access required by the selected actions.
  • The current action names appear read-oriented, but returned AMap data may still be sensitive and should be minimized before it enters model context.
  • Do not infer permission from catalog visibility. Workspace policy, connection identity, and upstream authorization still govern execution.
  • No provider scope string is declared on the sampled actions. Verify the connected account's actual permissions in AMap rather than assuming unrestricted access.
  • After a call, inspect the structured result and execution record before reporting that the AMap task completed successfully.

CONNECTION MODEL

API key

AMap API key sent as the key query parameter. Create it in the AMap Open Platform console: https://lbs.amap.com/api/webservice/guide/create-project/get-key .

Working Machines stores provider credentials behind the execution boundary. An agent can use an authorized connection identity, but catalog discovery alone does not reveal OAuth tokens, API keys, or provider secrets.

READ SIGNALS
5
WRITE SIGNALS
0
HIGH IMPACT
0
REVIEW SIGNALS
10

EVIDENCE AND AVAILABILITY

Provider reference

Action names, input fields, authentication types, and counts on this page are generated from the Working Machines provider catalog. Provider behavior, quotas, object semantics, account eligibility, and regional availability remain governed by AMap.

Official AMap website

ONE CONNECTION. REAL WORK.

Give your agent software it can use.

Connect through MCP or explore the Agent App catalog and choose only the capabilities your workflow needs.

EXPLORE AGENT APPS