amap-location-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Most tools are distinct, but 'amap_get_directions' and 'amap_plan_route' both plan routes with similar outputs, creating ambiguity. Additionally, 'amap_build_location_context' overlaps with multiple individual tools.
Naming Consistency5/5
All tools follow a consistent 'amap_verb_noun' pattern with underscores, e.g., 'amap_search_nearby', 'amap_convert_coordinates'. No mixing of styles.
Tool Count5/5
8 tools is well-scoped for a location service, covering essential functionalities without unnecessary redundancy.
Completeness4/5
Covers core features: geocoding, reverse geocoding, POI search, route planning, coordinate conversion, IP location. Minor gaps like missing batch operations, but overall sufficient for the domain.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that it combines multiple APIs (place parsing, reverse geocode, nearby POI) and outputs 'traceable location facts', but does not detail what that entails beyond the existing annotation profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a semicolon, efficiently conveying purpose and a key constraint. It is front-loaded and avoids verbosity, though a slightly more structured presentation could enhance readability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (combining multiple operations with 8 parameters, low schema coverage, and requirement to integrate with sibling tools), the description is incomplete. It does not explain when each sub-operation activates (e.g., query triggers place parsing, location triggers reverse geocode), nor the role of other parameters. The presence of an output schema partially compensates, but the description lacks sufficient context for reliable agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description only addresses the constraint that 'query or location at least one'. Other parameters like city, radius, nearby_limit, nearby_keywords, coordinate_source, and coordinate_system are left unexplained. The schema provides structure but the description adds little semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool combines place parsing, reverse geocoding, and nearby POI to generate traceable location facts for AI. It clearly distinguishes from sibling tools (e.g., amap_resolve_location, amap_reverse_geocode, amap_search_nearby) by being a composite function. The constraint 'query or location at least one' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key constraint (query or location required) but does not explicitly guide when to use this composite tool versus the individual sibling tools. No clear when-to-use or when-not-to-use guidance is given, only implicit differentiation through the tool's blended nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description adds no additional behavioral traits beyond confirming it returns route details, which is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with key actions and outputs. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and nested objects, the description is minimal. It does not explain how to use optional parameters like 'strategy', 'coordinate_system', or 'city'. However, an output schema exists, so return structure is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, meaning some parameters have descriptions but others don't. The description does not add meaning beyond what the schema provides; it only generically mentions 'real coordinates'. It could compensate for the gap but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it plans routes using real start/end coordinates for walking, driving, or transit, and returns distance, time, and steps. This is specific and actionable, though it does not explicitly differentiate from the sibling 'amap_get_directions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for planning real routes with coordinates, but lacks explicit guidance on when to use it versus similar tools like 'amap_get_directions'. No when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond noting 'real' POIs and distance return. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded with the core purpose, but it could be slightly more descriptive without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters including nested objects and an output schema, the description covers the main aspects but omits details like pagination (limit, radius constraints) and output structure, though the output schema partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, and the description only lists parameter names (center, radius, keywords, types) without adding usage details or constraints beyond what the schema already provides for coordinate_source and coordinate_system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (search), resource (real POIs), method (by center, radius, keywords, or type codes), and outcome (return distance), distinguishing it from sibling tools like reverse_geocode or get_directions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for nearby POI searches but lacks explicit guidance on when to choose this tool over alternatives (e.g., amap_resolve_location for exact addresses) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: it parses real coordinates, compares multiple modes, and returns fallback results when a mode fails. This surpasses annotation-only insight, though it does not detail rate limits or cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's primary role ('主要入口') and efficiently covers input, process, output, and error handling. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 2 required), comprehensive schema descriptions, and existence of an output schema, the description adequately covers input, processing steps, and output (distance, time, steps, recommendation). It also addresses error resilience. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing good per-parameter documentation. The description adds high-level context (e.g., parsing coordinates, mode comparison) but does not significantly enhance individual parameter semantics beyond what the schema already supplies. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the main entry for querying directions between an origin and destination, comparing walking, driving, and transit, and returning distance, time, key steps, and a recommendation. This distinguishes it from siblings like amap_plan_route by emphasizing multi-mode comparison and recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly positions this as the primary directions tool ('主要入口') but does not explicitly specify when to use this vs alternatives, nor does it provide exclusions or prerequisites. Usage guidance is implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which cover safety and idempotency. The description adds the 40-point batch limit and specifies the conversion output target (GCJ-02) and source-to-API mapping (e.g., WGS84->gps), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core purpose and key constraint (limit of 40). Every word adds value; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description, annotations, and output schema (present) together cover all necessary information: input types, conversion destination, limit, safety, and idempotency. No gaps for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters described). The description adds meaning by stating the batch limit (matching maxItems) and clarifying the 'from' enum values (e.g., 'WGS84 对应高德 API 的 gps'), which goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts WGS84/GPS, Baidu, or Mapbar coordinates to Gaode's GCJ-02, with a limit of 40 points. It provides a specific verb and resource, distinguishing it from sibling tools that handle directions, geocoding, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use (coordinate conversion to GCJ-02) but does not provide explicit guidance on when not to use or mention alternatives. Since no sibling tool does conversion, the context is sufficient but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a safe, read-only, idempotent tool. The description adds crucial context about handling both GCJ-02 and WGS84 inputs, output always in GCJ-02, and a special condition for marking device location, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose and key behavioral notes without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested objects) and the presence of an output schema, the description fully covers the core functionality, coordinate handling, and source marking, making it sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% schema coverage, the description adds value by explaining the output coordinate system and the device_gps condition for coordinate_source, but does not cover radius, location, or include_nearby_pois meaning beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (转换) and resource (坐标 to 结构化地址及附近 POI), and the mention of coordinate systems distinguishes it from sibling tools like amap_convert_coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when coordinates need to be converted to address/POI, but does not explicitly state when to use this tool versus siblings, nor does it provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds useful context about coarse granularity and explicit non-substitution of IP, enhancing understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the core function and precision level; the second sentence clarifies a key behavioral constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description does not need to elaborate on return values. It fully covers the tool's behavior, constraints, and purpose, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the ip parameter. However, the description adds meaning by specifying '公网 IPv4' and the guarantee of not using server IP, thus providing semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs coarse IP localization to province/city level for explicit public IPv4 addresses. It also distinguishes itself from siblings by noting it does not substitute the MCP server's IP, making its purpose unique among similar location tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use (for explicit IPv4) and what it avoids (not using server IP). While it doesn't list alternative tools, the context of siblings and the clear constraints imply appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it resolves to real POI/GCJ-02 coordinates, sorts candidates based on city and optional current location, and explicitly states it does not pretend to be device GPS. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense Chinese sentence that covers purpose, behavior, and a constraint without any wasted words. It is front-loaded with the core action and proceeds to additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description need not explain return format. It covers purpose, sorting behavior, and the important constraint about not impersonating GPS. However, it does not explicitly mention that multiple candidates are returned or that the coordinates are GCJ-02, though these are implied. Overall, it is sufficiently complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The description adds significant context for the 'current_location' parameter (used for distance sorting, not as device location). It does not detail other parameters beyond what the schema provides, but the high coverage mitigates the need for more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resolve' and the resource 'location name/address to Amap real POI/GCJ-02 coordinates'. It also specifies key behaviors: combining city and optional current location for sorting, and explicitly says it does not impersonate device GPS. This distinguishes it from sibling tools like amap_reverse_geocode and amap_locate_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning city and optional current location for sorting, and includes a caveat that it does not impersonate device GPS. However, it does not explicitly contrast with sibling tools such as amap_search_nearby or amap_build_location_context to guide when to use them instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![amap-location-mcp MCP server](https://glama.ai/mcp/servers/188zjl/amap-location-mcp/badges/card.svg)](https://glama.ai/mcp/servers/188zjl/amap-location-mcp)

Score Badge

Copy to your README.md:

[![amap-location-mcp MCP server](https://glama.ai/mcp/servers/188zjl/amap-location-mcp/badges/score.svg)](https://glama.ai/mcp/servers/188zjl/amap-location-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/188zjl/amap-location-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server